Hystrix熔断及工作流程

Hystrix 介绍

当微服务系统的一个服务出现故障时，故障会沿着服务的调用链路在系统中疯狂蔓延，最终导致整个微服务系统的瘫痪，这就是“雪崩效应”。为了防止此类事件的发生，微服务架构引入了“断路器”的一系列服务容错和保护机制。

"断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝)，向调用方返回一个符合预期的、可处理的备选响应（FallBack)，而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要地占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。

"断路器"思想：https://martinfowler.com/bliki/CircuitBreaker.html

Spring Cloud Hystrix 是基于 Netflix 公司的开源组件 Hystrix 实现的，它提供了熔断器功能，能够有效地阻止分布式微服务系统中出现联动故障，以提高微服务系统的弹性。Spring Cloud Hystrix 具有服务降级、服务熔断、线程隔离、请求缓存、请求合并以及实时故障监控等强大功能。

Hystrix 服务熔断

Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。

熔断机制是为了应对雪崩效应而出现的一种微服务链路保护机制。

当微服务系统中的某个微服务不可用或响应时间太长时，为了保护系统的整体可用性，熔断器会暂时切断请求对该服务的调用，并快速返回一个友好的错误响应。这种熔断状态不是永久的，在经历了一定的时间后，熔断器会再次检测该微服务是否恢复正常，若服务恢复正常则恢复其调用链路。

在熔断机制中涉及了三种熔断状态：

• 熔断打开：请求不再进行调用当前服务，内部定时一般为MTTR(平均故障处理时间)，当打开时长达到所设的时长则进入半熔断状态；
• 熔断半开：部分请求根据规则调用当前服务，如果请求成功且符合规则则认为当前服务恢复正常，关闭熔断；
• 熔断关闭：熔断关闭不会对服务进行熔断；

Hystrix 实现服务熔断的步骤如下：

1. 当服务的调用出错率达到或超过 Hystix 规定的比率（默认为 50%）后，熔断器进入熔断开启状态。
2. 熔断器进入熔断开启状态后，Hystrix 会启动一个休眠时间窗，在这个时间窗内，该服务的降级逻辑会临时充当业务主逻辑，而原来的业务主逻辑不可用。
3. 当有请求再次调用该服务时，会直接调用降级逻辑快速地返回失败响应，以避免系统雪崩。
4. 当休眠时间窗到期后，Hystrix 会进入半熔断转态，允许部分请求对服务原来的主业务逻辑进行调用，并监控其调用成功率。
5. 如果调用成功率达到预期，则说明服务已恢复正常，Hystrix 进入熔断关闭状态，服务原来的主业务逻辑恢复；否则 Hystrix 重新进入熔断开启状态，休眠时间窗口重新计时，继续重复第 2 到第 5 步。

Hystrix工作流程

• https://github.com/Netflix/Hystrix/wiki/How-it-Works#Flow

1. 创建HystrixCommand或HystrixObserableCommand对象。
2. 命令执行:
   • 其中HystrixCommand实现了下面前两种执行方式:
     • execute：同步执行，从依赖的服务返回一个单一的结果对象或是在发生错误的时候抛出异常。
     • queue：异步执行，直接返回一个Future对象，其中包含了服务执行结束时要返回的单一结果对象。
   • HystrixObservableCommand实现了后两种执行方式：
     • obseve()：返回Observable对象，它代表了操作的多个结果，它是一个Hot Observable,不论“事件源”是否有“订阅者”，都会在创建后对事件进行发布，所以对于Hot Observable的每一个“订阅者”都有可能是从“事件源”的中途开始的，并可能只是看到了整个操作的局部过程。
     • toObservable()：同样会返回Observable对象，也代表了操作的多个结果，但它返回的是一个Cold Observable,没有“订间者”的时候并不会发布事件，而是进行等待，直到有“订阅者"之后才发布事件，所以对于Cold Observable 的订阅者，它可以保证从一开始看到整个操作的全部过程。
3. 判断当前命令的请求缓存功能是被启用的，并且该命令缓存命中，那么缓存的结果会立即以Observable对象的形式返回。
4. 检查断路器是否为打开状态。如果断路器是打开的，那么Hystrix不会执行命令，而是转接到fallback处理逻辑(第8步)；如果断路器是关闭的，检查是否有可用资源来执行命令(第5步)。
5. 判断线程池/请求队列信号量是否占满。如果命令依赖服务的专有线程地和请求队列，或者信号量已经被占满，那么Hystrix也不会执行命令，而是转接到fallback处理理辑(第8步) 。
6. Hystrix会根据我们编写的方法来决定采取什么样的方式去请求依赖服务:
   • HystrixCommand.run()：返回一个单一的结果，或者抛出异常。
   • HystrixObservableCommand.construct()：返回一个Observable对象来发射多个结果，或通过onError发送错误通知。
7. Hystrix会将“成功”、“失败”、“拒绝”、“超时” 等信息报告给断路器，而断路器会维护一组计数器来统计这些数据。断路器会使用这些统计数据来决定是否要将断路器打开，来对某个依赖服务的请求进行"熔断/短路"。
8. 当命令执行失败的时候，Hystrix会进入fallback尝试回退处理，我们通常也称波操作为“服务降级”。而能够引起服务降级处理的情况有下面几种：
   • 第4步∶当前命令处于“熔断/短路”状态，断路器是打开的时候。
   • 第5步∶当前命令的线程池、请求队列或者信号量被占满的时候。
   • 第6步∶HystrixObsevableCommand.construct()或HytrixCommand.run()抛出异常的时候。
9. 当Hystrix命令执行成功之后，它会将处理结果直接返回或是以Observable的形式返回给调用方。