一、什么是Hystrix？
Hystrix从Netflix API团队于2011年开始的弹性工程工作演变而来。在分布式环境中，许多服务依赖项中的一些不可避免地会失败。Hystrix是一个库，可通过添加延迟容错和容错逻辑来帮助您控制这些分布式服务之间的交互。Hystrix通过隔离服务之间的访问点，阻止它们之间的级联故障以及提供后备选项来实现这一目标，所有这些都可以提高系统的整体弹性。
Hystrix功能：
- 通过第三方客户端库访问（通常通过网络）依赖关系，以防止和控制延迟和故障。
- 在复杂的分布式系统中停止级联故障。
- 快速失败并迅速恢复。
- 在可能的情况下，后退并优雅地降级。
- 实现近实时监控，警报和操作控制。
二、Hystrix解决了什么问题？
复杂分布式体系结构中的应用程序具有许多依赖关系，每个依赖关系在某些时候都将不可避免地失败。如果主机应用程序未与这些外部故障隔离，则可能会被它们取下。
例如，对于依赖于30个服务的应用程序，其中每个服务的正常运行时间为99.99％，您可以期待以下内容：
现实情况通常更糟。
即使所有依赖项都表现良好，如果您没有为整个系统设计弹性，那么即使0.01％停机时间对数十种服务中的每项服务的总体影响也相当于每月停机时间可能达到数小时。
当一切都很健康时，请求流可能如下所示：
当许多后端系统中的一个变得潜伏时，它可以阻止整个用户请求：
对于高流量流量，单个后端依赖性变为潜在可能导致所有资源在所有服务器上在几秒钟内变得饱和。
比故障更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，从而备份队列，线程和其他系统资源，从而导致整个系统出现更多级联故障。
三、Hystrix如何实现其目标？
Hystrix的工作原理是：
- 防止任何单个依赖项用尽所有容器（例如Tomcat）用户线程。
- 脱落负载并快速失败而不是排队。
- 在可行的情况下提供回退以保护用户免于失败。
- 使用隔离技术（例如隔板，泳道和断路器模式）来限制任何一个依赖项的影响。
- 通过近实时指标，监控和警报优化发现时间
- 通过Hystrix的大多数方面的配置更改的低延迟传播和对动态属性更改的支持来优化恢复时间，这允许您使用低延迟反馈循环进行实时操作修改。
- 防止整个依赖关系客户端执行中的故障，而不仅仅是网络流量。
Hystrix通过以下方式实现：
- 将对外部系统（或“依赖项”）的所有调用包含在通常在单独线程中执行的对象HystrixCommand或HystrixObservableCommand对象中（这是命令模式的示例）。
- 定时调用的时间超过您定义的阈值。有一个默认的，而是由“属性”的方式对大多数依赖你自定义设置这些超时，使它们成功率笔99.5略高。
- 为每个依赖服务维护一个小的线程池（或信号量）; 如果它变满，将立即拒绝发往该依赖项的请求而不是排队。
- 衡量成功，失败（客户端引发的异常），超时和线程拒绝。
- 如果服务的错误百分比超过阈值，则手动或自动地使断路器跳闸以停止对特定服务的所有请求一段时间。
- 当请求失败时执行callback逻辑，被拒绝，超时或短路。
- 近乎实时地监控指标和配置更改。
当您使用Hystrix来包装每个底层依赖项时，上图中显示的体系结构将更改为类似于下图。每个依赖服务彼此隔离，在发生延迟时可以饱和的资源受到限制，并且在callback逻辑中涵盖，该逻辑决定了在依赖项中发生任何类型的故障时要做出的响应：
四 、注意
Netflix 已经官方宣布不再维护 Hystrix，所以在生产环境，技术选型的时候需要综合考虑。