Hystrix是什么

在分布式环境下，难免出现许多服务之间调用失败的场景， Hystrix是一个通过添加延迟容忍和容错逻辑帮助您控制这些分布式服务之间交互的库。 Hystrix通过隔离服务之间的访问点来实现应用之间连锁故障（因下游服务失败，导致上游服务不可用），出现故障提供备选方案来提高应用整体的可用性。

举例：抢购活动中，由于库存服务超时或者崩掉，可以通过提示抢购失败，请稍后重试等预防抢购应用不可用

Hystrix用来做什么

Hystrix可以做一些事情：

复杂的分布式应用有许多依赖调用，在某一时刻它们之间必然会出现失败，这就是导致应用整体故障的风险。

例如，对于一个依赖于30个服务的应用程序，每个服务的正常运行时间为99.99%，下面是您可以预期的结果。

99.99 的30次方= 99.7% （意味着有0.3%的失败）

10亿*0.3% = 300万（10亿次请求会有300万次请求失败）

即使每个月在很好的正常运行的时间，也会有2个小时的停机。通常情况会被这个更糟糕。

当所有请求都很正常的情况下，请求流就会像下图一样：

当很多后端系统有一个不稳定时，就会阻塞整个请求，如下图：

在大量请求下，一个后端不理想的依赖都会成为阻塞整个应用请求的潜在风险

应用中任何一个通过网络或者客户端发出的请求都有可能成为网络请求失败的潜在风险，比请求失败更糟糕的是，应用调用依赖之间的延迟增加，更甚应用中的队列、线程池、其他系统资源造成的连锁故障

当通过第三方客户端进行网络访问，就是一个不清楚实现细节以及随时可能发生改变的黑盒执行，对于每个客户端，网络和资源配置都是不一样的，所以很难监控和更改。

更糟糕的是，依赖调用之间，在不被应用显示调用的情况下，执行昂贵和容易出错的网络调用

网络连接失败或者降级、服务与服务之间调用失败或者延迟，新库或服务部署改变方式或者性能特性

所有这些失败和延迟的情况都需要被隔离或者管理，这样就不会因为单个依赖的失败摧毁整个应用和系统。

在HystrixCommand或HystrixObservableCommand对象中封装所有对外部系统(或“依赖项”)的调用，该对象通常在单独的线程中执行(这是命令模式的示例)
Hystrix有一个默认值，如果调用时长超过这个默认值，认定为超时调用，大部分依赖可以通过配置自定义这个值，因此他们略高于依赖项的99.5%的性能
为每个依赖维护一个小的线程池(或信号量);如果它已满，将立即拒绝为该依赖指定的请求，而不是排队。
衡量成功、失败(客户抛出的异常)、超时和线程拒绝
触发断路器，在一段时间内停止所有对某个服务的请求，如果服务的错误百分比超过阈值，则手动或自动停止
当一个请求失败、被拒绝、超时或短路时，执行备选逻辑
近实时的监控度量和配置的变化