Hystrix原理与实战——Hystrix概况

Hystrix概况

背景

  在分布式环境中，我们不能绝对保证每个服务都不会发生失败，如果在一个分布式系统环境中，其中一台计算机服务发送了故障，这会对整个系统带来什么样的问题？莱斯利·兰波特（Leslie Lamport）曾经指出，分布式系统有这样的特点：一台你甚至不知道它存在的计算机，如果它出现了故障，有可能会导致你自己的计算机无法使用。
  如果在分布式系统中，失败没有进行恰当地处理，那么它们很容易传递到下游的依赖中，就像异常会在栈中传递一样。在分布式系统中，一个终端用户的请求可以轻易地向上游依赖发送数十个甚至上百个请求。一个出现故障的服务，即便是非必要的服务，都可能会导致整个系统的奔溃，让每个请求都失败。
  有意思的是，响应慢的服务要比失败的服务更加糟糕。如果用户的请求立即失败，并且给出友好的错误信息，这种情况是糟糕的。但是，如果用户根本没有得到任何的响应，而只能无限地等待下去，那么情况就更糟糕了。遇到这种情况，用户常见的反应就是尝试刷新网页。大多数时候，这其实并没有什么助益，只会启动另外一个请求，进一步加重系统的负担。一个慢服务会导致进一步的级联，从而让整个系统陷入停顿。使用慢服务的其他所有服务会突然变得非常缓慢，而且这种情况会递归级联，从而引发雪崩效应。Hystrix试图屏蔽这种破坏性的依赖关系并停止故障的级联。

什么是Hystrix?

Hystrix 是一个库，它通过添加延迟容错和容错逻辑来帮助我们控制这些分布式服务之间的交互。Hystrix 通过隔离服务之间的访问点、阻止它们之间的级联故障并提供回退选项，所有这些措施都提高了系统的整体恢复能力。

Hystrix的历史

Hystrix 由 Netflix API 团队于 2011 年开始的弹性工程工作（resilience engineering work）演变而来。2012年，Hystrix继续发展和成熟，Netflix的许多团队采用了它。如今，Netflix每天通过Hystrix执行数百亿次线程隔离调用和数千亿次信号隔离调用。这极大地提高了正常运行时间和弹性。

Hystrix 目前状态

Hystrix已不再处于积极的开发中，目前处于维护模式。Hystrix(版本1.5.18)足够稳定，可以满足我们现有应用程序的需求。与此同时，官方团队的重点已经转移到对应用程序的实时性能作出反应的更多自适应实现，而不是预先配置的设置(例如，通过自适应并发限制( adaptive concurrency limits))。对于一些Hystrix有意义的使用场景，我们可以在现有的项目中继续使用Hystrix，在新的项目中我们可以选择使用开放和活跃的项目比如 resilience4j。
Hystrix多年来为Netflix和社区提供了很好的服务，而向维护模式的过渡并不意味着Hystrix的概念和想法不再有价值。相反，Hystrix激发了许多伟大的想法和项目。

Hystrix 有什么用？

Hystrix的设计目的如下:

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

Hystrix解决了什么问题?

在复杂分布式架构中的应用程序往往有很多的依赖项，每个依赖项不可避免地会在某个时刻产生失败。如果主应用没有从这些外部依赖产生的故障中隔离开，那么它就会有随这些故障的发生而导致失败风险。
例如：一个应用程序依赖了30个服务，平均每个服务的uptime（上线时间）为99.99%，我们可以得到如下的结果：

$99.99^{30}$ = 99.7% uptime
10 亿次请求的 0.3% = 3,000,000 次失败
即使所有依赖项都具有出色的正常运行时间，每月也有 2 小时以上的停机时间。

现实情况通常更糟。
如果我们没有设计整个系统的弹性恢复策略，即使所有服务依赖都表现良好，数十个服务中每一个服务纵使有0.01%的停机时间，其累计的影响也相当于一个月内会出现潜在的数小时的停机。

---

当一切正常时，请求流可能如下所示：

其中一个服务异常，它会阻塞整个用户请求。

对于大量流量，单个后端依赖出现异常可能导致所有服务上的所有资源在几秒钟内变得饱和。

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

在50个请求/秒时，所有请求线程都会在短时间内阻塞

所以对于这些请求的失败以及延迟我们需要对其进行有效的隔离和管理，从而避免一个依赖的失败影响到整个系统的稳定。

Hystrix 背后的设计原则是什么？

• 防止任何单个依赖项耗尽所有容器（例如 Tomcat）用户线程。
• 减轻负载和快速失败而不是排队。
• 在可行的情况下提供备用方案以保护用户不受故障的影响。
• 使用隔离技术（例如隔板、泳道和断路器模式）来限制任何一种依赖性的影响。
• 通过近乎实时的指标、监控和警报来优化发现时间。
• 通过低延迟的传播，优化恢复时间，Hystrix在大多数方面可以改变配置并支持动态参数的改变。
• 防止整个依赖客户端执行中的故障，而不仅仅是网络流量。

Hystrix是如何实现目标的?

• 将所有对外部系统（或“依赖项”）的调用包装在 HystrixCommand 或 HystrixObservableCommand 对象中，该对象通常在单独的线程中执行（这是命令模式的一个示例）。
• 超时调用时间超过您定义的阈值。这里有一个默认值，但对于大多数依赖项，您可以通过“属性”的含义来自定义设置这些超时，以便它们略高于每个依赖项所测量的99.5%的性能。
• 为每个依赖项维护一个小的线程池（或信号量）；如果它已满，则发往该依赖项的请求将立即被拒绝而不是排队
• 度量成功、失败(由客户端抛出的异常)、超时和线程拒绝。
• 如果服务的错误百分比超过阈值，则手动或自动触发断路器以在一段时间内停止对特定服务的所有请求。
• 当请求失败、被拒绝、超时或短路时执行回退逻辑。
• 接近实时地监视指标和配置更改。

当使用 Hystrix 包装每个底层依赖项时，如上图所示的架构将更改为类似于下图。每个依赖彼此隔离，受限于资源当发生延迟时它可能会达到饱和，并包含在回退（fallback）逻辑中，该逻辑决定了在依赖项中发生任何类型的故障时做出的响应。