Spring cloud系列八 Hystrix的用处、解决的问题、工作流程图、断路器流程

1. 概述

本文对Hystrix进行介绍，本文内容如下：

• 什么是Hystrix
• Hystrix要解决的问题和产生的原因分析
• Hystrix设计原则
• Hystrix的处理流程图和详细流程说明
• 断路器工作流程

2. Hystrix

2.1. 什么是Hystrix

在分布式环境中，一个服务可能会依赖很多其他的服务，并且这些服务都不可避免地有失效的可能。Hystrix通过隔离服务之间的访问点，阻止它们之间的级联故障以及提供回退选项以提高系统的整体可靠性。

2.2. Hystrix要解决的问题和产生的原因分析

Hystrix要解决的问题和必要性
避免因为单点故障导致服务级联失败，从而使得整个系统崩溃。

官方中提供一个例子，如果一个应用依赖30个服务，每个服务99.99%的时间处于正常服务状态

>
正常工作时间：99.9930 = 99.7% uptime
失败次数：0.3% of 1亿个请求 = 3,000,000 失败
每个月至少有2个小时处于异常状态

即使只有0.01%的失败率，每个月仍然有几个小时服务不可用

Hystrix问题产生的原因分析

正常请求处理流程如下

如果后端的一个服务出现延迟，则会阻塞整个请求

对于高并发的系统，即使只有一个后端的服务出现延迟，它也会导致整个系统的资源在几秒内被全部消耗掉。更糟糕的是，这些服务有可能被其他服务依赖，由于每个服务都有队列、线程池、其他系统资源等，一旦某个服务失效或者延迟增高，会导致整个系统发生更多的级联故障，从而导致这个分布式系统都不可用

2.3. Hystrix设计原则

• 防止单个服务的故障，耗尽整个系统服务的容器（比如tomcat）的线程资源，避免分布式环境里大量级联失败。通过第三方客户端访问（通常是通过网络）依赖服务出现失败、拒绝、超时或短路时执行回退逻辑
• 用快速失败代替排队(每个依赖服务维护一个小的线程池或信号量，当线程池满或信号量满，会立即拒绝服务而不会排队等待)和优雅的服务降级；当依赖服务失效后又恢复正常，快速恢复
• 提供接近实时的监控和警报，从而能够快速发现故障和修复。监控信息包括请求成功，失败（客户端抛出的异常），超时和线程拒绝。如果访问依赖服务的错误百分比超过阈值,断路器会跳闸，此时服务会在一段时间内停止对特定服务的所有请求
• 将所有请求外部系统（或请求依赖服务）封装到HystrixCommand或HystrixObservableCommand对象中，然后这些请求在一个独立的线程中执行。使用隔离技术来限制任何一个依赖的失败对系统的影响。每个依赖服务维护一个小的线程池（或信号量），当线程池满或信号量满，会立即拒绝服务而不会排队等待

2.4. Hystrix处理后新的流程

当您使用Hystrix包装每个基础依赖关系时，新的图如下。每个依赖都是相互隔离的，当延迟发生时，会快速失败，执行回退逻辑，避免消耗掉所有资源

3. Hystrix的处理流程图和详细流程说明

Hystrix的处理流程
1. 构造HystrixCommand或HystrixObservableCommand对象
创建代码如下
HystrixCommand command = new HystrixCommand(arg1, arg2);
HystrixObservableCommand command = new HystrixObservableCommand(arg1, arg2);

2. 执行Command 命令

共有4种执行命令的方法，前2种只支持HystrixCommand ，后2种只支持HystrixObservableCommand

• execute(): 同步阻塞直至从依赖服务返回结果或抛出异常
• queue(): 异步模式，返回Future，Future封装返回的内容
• observe() : 直接订阅Observable ，此对象包含了从依赖服务返回的结果
• toObservable() : 返回Observable 对象，当你订阅他时，它会执行Hystrix命令并返回结果

HystrixCommand.execute(): 实际调用queue()的方法

public R execute() {   return queue().get();}

HystrixCommand.queue(): 实际调用toObservable()的方法

 public Future<R> queue() {final Future<R> delegate = toObservable().toBlocking().toFuture();....}

HystrixObservableCommand.observe():实际调用toObservable()的方法

public Observable<R> observe() {....    final Subscription sourceSubscription = toObservable().subscribe(subject);....

通过以上的代码，我们可以知道：第1种是同步阻塞性调用，第2种是异步非阻塞性调用，第3、4种是基于发布-订阅响应式的调用。虽然是4种调用方式，其实际最后都是基于toObservable方法来实现的

3. 判断结束是否有缓存
如果请求缓存功能开启，并且请求在缓存命中，那么返回一个Observable，此对象包含请求的结束

4. 判断短路器是否开启
在执行命令时，Hystrix 如果发现断路器跳闸，那么hystix会跳到步骤8去执行回退(fallback)逻辑。如果断路器没有跳闸，则继续执行步骤5

关于断路器打开和关闭的条件见本文的下方。

5. 判断线程池/队列/信号资源是否满了
如果命令关联的线程池和队列（或信号量）满了，则不会执行命令，会跳到步骤8去执行回退(fallback)逻辑

6. 执行HystrixObservableCommand.construct()或HystrixCommand.run()

执行HystrixCommand.run()或HystrixObservableCommand.construct()时，如果执行超时或者执行失败，则执行会跳到步骤8去执行回退(fallback)逻辑；如果正常结束，Hystrix 会记录一些日志和监控数据，并返回处理结果

7. Calculate Circuit Health
Hystrix向断路器报告成功、失败、拒绝和超时。断路器维护一组计数器来统计执行数据。

8. 获取 Fallback逻辑
当发生如下情况时，Hystrix会尝试执行回退(fallback)逻辑：

• 在执行时construct() or run() ，跑出异常 (发生在步骤6.)
• 断路器打开时，命令被断路 (发生在步骤4.)
• 当执行命令时，依赖的线程池、队列或信号量满(发生在步骤5.)
• 执行命令超时

编写回退(fallback)逻辑时，这个逻辑里最好没有网络调用，只从内存中获取或者只有静态的逻辑，这个逻辑保证不会执行失败。如果非要通过网络去获取Fallback,你需要在使用其他HystrixCommand或HystrixObservableCommand封装请求，并且这个请求必须有fallback逻辑且值没有网络调用，只有静态逻辑

9. Return the Successful Response
返回执行结束或者Observable

4. 断路器工作流程

下图显示HystrixCommand或HystrixObservableCommand如何与HystrixCircuitBreaker及其逻辑和决策流程交互，包括计数器在断路器中的行为。

断路器开启关闭的规则如下：

• 如果服务请求数量达到一定阈值（HystrixCommandProperties.circuitBreakerRequestVolumeThreshold）且如果服务请求失败的百分比超过阈值(HystrixCommandProperties.circuitBreakerErrorThresholdPercentage())…
• 然后断路器的状态从CLOSED改变为OPEN.
• 当断路器open时，它会短路所有经过此断路器的请求。
• 经过一段时间（HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds（）），接下来的第一个请求允许通过（此时断路器是处于HALF-OPEN状态）。 如果请求失败，断路器将在睡眠窗口持续时间内返回到OPEN状态。 如果请求成功，断路器状态将转换到CLOSED，又会转到逻辑1。

5. 其他

本文使用的图都来自Hystrix官网的wiki