目录

•  Hystrix是什么
• Hystrix用来做什么
• Hystrix解决什么问题
• Hystrix设计原则
• Hystrix如何实现目标

Hystrix是什么

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

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

Hystrix用来做什么

    Hystrix可以做一些事情：

1. 通过第三方客户端库，为控制延迟和依赖之间调用失败提供保护。
2. 在复杂的分布式系统中阻止连锁故障
3. 快速故障恢复
4. 在可能的情况下，做到服务隔离和优雅降级
5. 尽可能的实时监控、报警、运维控制

Hystrix解决什么问题

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

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

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

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

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

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

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

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

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

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

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

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

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

Hystrix设计原则

1.  防止单个应用耗尽服务器（比如 tomcat）所有可用线程
2. 丢弃重负载、快速失败代替排队
3. 为任何情况失败提供保护
4. 使用隔离技术(如隔板、泳道和断路器模式)来限制任何一个依赖的影响
5. 通过接近实时的度量、监视和警报来优化快速发现故障
6. Hystrix在大部分方面依靠低延迟配置和动态配置优化恢复时间， 允许使用快速返回结果进行实时操作调整
7. 保护整个依赖客户端执行中的失败，不仅仅是 网络流量中

Hystrix如何实现目标

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

    当您使用Hystrix来包装每个基础依赖项时，图中所示的架构会发生变化，如下图所示。每个依赖项都是相互隔离的，当延迟发生时，它可能会被限制在资源中，并且在熔断器中覆盖，当任何类型的故障发生在依赖项中时，它决定了要做出什么响应