什么是Hystrix

在分布式环境中，无法避免的一些依赖的服务会失败。Hystrix是一个类库通过添加延迟容错和失败容错的逻辑，帮助你控制和跟这些分布式服务交互。Hystrix通过隔离这些服务的接入点，阻止级联故障，和提供回滚选项，所有这些都能提高系统的整体弹性。

Hystrix的历史

Hystrix从Netflix Api团队于2011年开始的的弹性工程工作中发展而来。在2012年，Hystrix继续发展成熟，Netflix中的很多团队都采用了它。今天，Netflix每天都会通过Hystrix执行数百亿个线程隔离和数千亿个信号量隔离的调用。这导致了正常运行时间和弹性的显著改善。

下面的链接提供更多有关Hystrix有关的背景信息以及他试图解决的挑战：
让Netflix API 更加具有弹性
大容量，分布式系统中的容错
Netflix的性能和容错
面上服务架构中的应用程序弹性
Netflix中的应用程序弹性工程和弹性操作

Hystrix可以用来干什么

Hystrix被设计成可以做以下事情：

• 通过第三方客户端类库（通常是通过网络）依赖访问，可以防止和控制延迟和故障。
• 在复杂分布式系统中防止级联故障。
• 快速失败并迅速恢复。
• 可能的话回滚和平滑优雅的降级。
• 接近实时监控，预警，操作控制。

Hystrix解决了什么问题？

在复杂分布式架构中的应用程序还有着许多的依赖，每个依赖都可能在某个时刻出故障。如果主应用程序没有和这些外部故障隔离，那么主应用程序会有宕机的风险。
举个荔枝，某个应用需要依赖30个服务。每个服务的可硬都达到99.99%

99.9930 = 99.7% uptime
0.3% of 1 billion requests = 3,000,000 failures
2+ hours downtime/month even if all dependencies have excellent uptime.

现实可能更糟。
即使所有依赖都表现良好，如果没有为整个系统设计弹性，那么即使每种服务0.01%的宕机时间整体也相当于每个月停机数小时

当所有服务都是健康的情况下请求看起来是这样的

当无数后端服务中的一个系统有延迟会阻塞整个用户请求：

一个应用程序通过网络或者进入一个会导致网络请求的客户端库的点都是潜在的故障源。比故障更加糟糕的是，这些应用程序可能导致服务之间延迟增加，从而备份队列，线程，其他系统资源，从而导致整个系统出现更多的级联故障

当网络是通过三方客户端---“黑盒”（隐藏了具体实现细节，然后随时都会变化，网络和资源配置对每个客户端库都是不一样的，而且难以监控和改变）的情况下，这些问题会更加恶化。

更糟糕的是传递依赖性，执行潜在的昂贵的又容易出错的网络调用，而不是应用程序显示的调用。

网络连接故障会降级。服务或服务器故障会变慢。新的类库或服务发布改变行为或性能特性。客户端类库有bugs

所有这些代表了需要被隔离和管理的故障和延迟，因此单个的故障依赖不会导致整个系统的瘫痪。

Hystrix设计原则

Hystrix工作原理：

• 防止单个依赖项用尽容器（比如Tomcat）的用户线程
• 负载限制和快速失败替代排队
• 在可行的情况下提供回退在故障中保护用户数据
• 使用隔离技术（bulkhead，swimlane，circuit breaker 模式）限制某一个依赖的影响
• 优化故障的发现时间，通过接近实时的指标监控预警。
• 优化故障恢复时间，通过低延迟传播的配置更改，并在Hystrix大多数方面支持动态属性更改。允许你使用循环的低延迟反馈进行实时操作修改。
• 在整个依赖客户端执行中防止故障，不仅仅是在网络流量中

Hystrix如何实现其目标

• 将所有对外部系统（或“依赖”）的调用包装成HystrixCommand或HystrixObservableCommand对象中，该对象通常在单独的线程中执行（这是一个命令模式的示例）。
• 调用超时就是花费了你设定的阈值。他有一个默认值，但是大多数你可以通过属性设定超时时间。以便于稍微高于每个依赖项测量的99.5%百分位性能
• 为每个依赖项维护一个线程池（或信号量）；如果它变满了，将立即拒绝发往该依赖项的请求而不是排队。
• 衡量成功，失败（客户端引发的异常），超时和线程拒绝
• 如果错误率超过阈值手动或自动tripping断路器一段时间内停止对某一个服务的请求调用。
• 如果请求失败，或被拒绝，或超时，或短路执行回退

• 实时监控指标和配置变化
  当用Hystrix去包装每个底层的依赖项，之前那个架构图就类似于下面的架构图。每个依赖项相互隔离，当延迟发生的时候约束资源饱和，当各种故障在依赖项中发生的时候用回退逻辑覆盖决定用什么响应