解读Hystrix系列（一）：初探Hystrix

什么是Hystrix?

Hystrix是一个库，它通过添加延迟容忍和容错逻辑来帮助您控制这些分布式服务之间的交互。

Hystrix的设计目的如下:

• 为通过第三方客户端库访问的依赖项(通常通过网络)提供保护和控制延迟 和故障。
• 停止复杂分布式系统中的级联故障。
• 故障快速恢复。
• 在可能的情况下，后退并优雅地降级。
• 启用近实时监视、警报和操作控制。

Hystrix解决了什么问题?

复杂分布式体系结构中的应用程序有几十个依赖项，每个依赖项在某个时候都不可避免地会失败。如果主机应用程序没有从这些外部故障中隔离出来，那么它就有可能与这些外部故障一起宕机。
例如，对于一个依赖于30个服务的应用程序，其中每个服务都有99.99%的正常运行时间，您可以这样期望:99.9930 = 99.7%的正常运行时间(10亿个请求的0.3%)= 300万个故障(2小时以上停机/月)，即使所有依赖项都具有良好的正常运行时间。现实通常更糟,即使当所有依赖项都运行良好时，0.01%的停机时间对几十个服务中的每个服务的总体影响也相当于一个月潜在的停机时间,如果您不为整个系统服务设计弹性)。

当一切正常时，请求流可以是这样的:

soa-1-640.png

当许多后端系统之一成为潜在，它可以阻止整个用户请求:

soa-2-640.png

在高并发下，一个后端依赖项出现问题，可能会导致所有服务器上的所有资源在几秒钟内饱和。应用程序中通过网络或客户机库到达可能导致网络请求的每个点都是潜在故障的来源。比故障更糟的是，这些应用程序还可能导致服务之间的延迟增加，从而备份队列、线程和其他系统资源，从而导致系统中出现更多级联故障。

soa-3-640.png

当通过第三方客户机执行网络访问时，这些问题会变得更加严重，因为第三方客户机是一个黑盒子，其中隐藏了实现细节，并且可以随时更改，而且每个客户机库的网络或资源配置都不一样，而且常常难以监控和更改。更糟糕的是传递依赖关系，它在应用程序没有显式调用的情况下执行潜在的昂贵或容易出错的网络调用。网络连接失败或降级。服务和服务器失败或变慢。新的库或服务部署会更改行为或性能特征。客户端库有bug。所有这些都表示需要隔离和管理的故障和延迟，这样单个故障依赖项就不会导致整个应用程序或系统崩溃。

Hystrix的设计原则是什么?

Hystrix的工作原理是:
1.防止任何单个依赖项耗尽所有容器(例如Tomcat)的用户线程。减少负载，快速失败，而不是排队。
2.在可行的情况下提供回退以保护用户免受失败。
3.使用隔离技术(如隔板、泳道和断路器模式)来限制任何一个依赖项的影响。
4.通过近乎实时的指标优化发现时间，通过配置更改的低延迟传播和支持Hystrix的大多数方面的动态属性更改(允许您使用低延迟反馈循环进行实时操作修改)，监视和警报优化恢复时间。
5.防止整个依赖客户端执行中的失败，而不仅仅是网络流量中的失败。

Hystrix是如何实现其目标的?

Hystrix是这样做的:

• 将对外部系统(或“依赖项”)的所有调用封装在一个HystrixCommand或HystrixObservableCommand对象中，该对象通常在单独的线程中执行(这是命令模式的一个例子)。
• 超时调用所花费的时间超过您定义的阈值。有一个默认值，但是对于大多数依赖项，您可以通过“属性”自定义设置这些超时，以便它们比每个依赖项测量到的99.5%的性能稍微高一些。
• 为每个依赖项维护一个小线程池(或信号量);如果它满了，针对该依赖项的请求将立即被拒绝，而不是排队。
• 度量成功、失败(客户机抛出的异常)、超时和线程拒绝。
• 断开断路器，在一段时间内停止对特定服务的所有请求，如果服务的错误率超过阈值，则手动或自动停止。
• 当请求失败、被拒绝、超时或短路时执行回退逻辑。
• 几乎实时地监视度量和配置更改。

当您使用Hystrix来包装每个底层依赖项时，如上面的关系图所示的体系结构会发生类似下面的关系图的变化。每个依赖项彼此隔离，当延迟发生时受资源限制，资源可能会饱和，当依赖项中出现任何类型的故障时，由回退逻辑决定响应：

soa-4-isolation-640.png