Hystrix熔断机制原理剖析

Posted 2020-11-28 littlewhiterabbit

一、前言
在分布式系统架构中多个系统之间通常是通过远程RPC调用进行通信，也就是 A 系统调用 B 系统服务，B 系统调用 C 系统的服务。当尾部应用 C 发生故障而系统 B 没有服务降级时候可能会导致 B，甚至系统 A 瘫痪，这种现象被称为雪崩现象。所以在系统设计时候要使用一定的降级策略，来保证当服务提供方服务不可用时候，服务调用方可以切换到降级后的策略进行执行。

二、Hystrix 中基于自反馈调节熔断状态的算法原理
我们可以把熔断器想象为一个保险丝，在电路系统中，一般在所有的家电系统连接外部供电的线路中间都会加一个保险丝，当外部电压过高，达到保险丝的熔点时候，保险丝就会被熔断，从而可以切断家电系统与外部电路的联通，进而保障家电系统不会因为电压过高而损坏。

Hystrix提供的熔断器就有类似功能，当在一定时间段内服务调用方调用服务提供方的服务的次数达到设定的阈值，并且出错的次数也达到设置的出错阈值，就会进行服务降级，让服务调用方之间执行本地设置的降级策略，而不再发起远程调用。但是Hystrix提供的熔断器具有自我反馈，自我恢复的功能，Hystrix会根据调用接口的情况，让熔断器在closed,open,half-open三种状态之间自动切换。

open状态说明打开熔断，也就是服务调用方执行本地降级策略，不进行远程调用。
closed状态说明关闭了熔断，这时候服务调用方直接发起远程调用。
half-open状态，则是一个中间状态，当熔断器处于这种状态时候，直接发起远程调用。

三种状态的转换：
- closed->open:正常情况下熔断器为closed状态，当访问同一个接口次数超过设定阈值并且错误比例超过设置错误阈值时候，就会打开熔断机制，这时候熔断器状态从closed->open。

open->half-open:当服务接口对应的熔断器状态为open状态时候，所有服务调用方调用该服务方法时候都是执行本地降级方法，那么什么时候才会恢复到远程调用那？Hystrix提供了一种测试策略，也就是设置了一个时间窗口，从熔断器状态变为open状态开始的一个时间窗口内，调用该服务接口时候都委托服务降级方法进行执行。如果时间超过了时间窗口，则把熔断状态从open->half-open,这时候服务调用方调用服务接口时候，就可以发起远程调用而不再使用本地降级接口，如果发起远程调用还是失败，则重新设置熔断器状态为open状态，从新记录时间窗口开始时间。

half-open->closed: 当熔断器状态为half-open,这时候服务调用方调用服务接口时候，就可以发起远程调用而不再使用本地降级接口，如果发起远程调用成功，则重新设置熔断器状态为closed状态。

那么有一个问题，用来判断熔断器从closed->open转换的数据是哪里来的那？其实这个是HystrixCommandMetrics对象来做的，该对象用来存在HystrixCommand的一些指标数据，比如接口调用次数，调用接口失败的次数等等，后面我们会讲解。

图中流程的说明:

1. 将远程服务调用逻辑封装进一个HystrixCommand。
2. 对于每次服务调用可以使用同步或异步机制，对应执行execute()或queue()。
3. 判断熔断器(circuit-breaker)是否打开或者半打开状态，如果打开跳到步骤8，进行回退策略，如果关闭进入步骤4。
4. 判断线程池/队列/信号量（使用了舱壁隔离模式）是否跑满，如果跑满进入回退步骤8，否则继续后续步骤5。
5. run方法中执行了实际的服务调用。 
   a. 服务调用发生超时时，进入步骤8。
6. 判断run方法中的代码是否执行成功。 
   a. 执行成功返回结果。 
   b. 执行中出现错误则进入步骤8。
7. 所有的运行状态(成功，失败，拒绝，超时)上报给熔断器，用于统计从而影响熔断器状态。
8. 进入getFallback()回退逻辑。 
   a. 没有实现getFallback()回退逻辑的调用将直接抛出异常。 
   b. 回退逻辑调用成功直接返回。 
   c. 回退逻辑调用失败抛出异常。
9. 返回执行成功结果。

注意：熔断是否开启熔断器主要由依赖调用的错误比率决定的，依赖调用的错误比率=请求失败数/请求总数。Hystrix中断路器打开的默认请求错误比率为50%（这里暂时称为请求错误率），还有一个参数，用于设置在一个滚动窗口中，打开断路器的最少请求数（这里暂时称为滚动窗口最小请求数），这里举个具体的例子：如果滚动窗口最小请求数为默认20，在一个窗口内（默认10秒，统计滚动窗口的时间可以设置），收到19个请求，即使这19个请求都失败了，此时请求错误率高达95%，但是断路器也不会打开。对于被熔断的请求，并不是永久被切断，而是被暂停一段时间（默认是5000ms）之后，允许部分请求通过，若请求都是健康的（ResponseTime<250ms）则对请求健康恢复（取消熔断），如果不是健康的，则继续熔断。（这里很容易出现一种错觉：多个请求失败但是没有触发熔断。这是因为在一个滚动窗口内的失败请求数没有达到打开断路器的最少请求数）

 

三、总结
系统设计时候要使用一定的降级策略，来保证当服务提供方服务不可用时候，服务调用方可以切换到降级后的策略进行执行，Hystrix作为熔断器组件使用范围还是很广泛的.
学过分布式、微服务知识的朋友们对熔断机制都不会陌生的，即使没有系统化的学习过理论知识，在实际项目开发中也使用过，熔断机制其实就是一种补救措施，不至于一个节点服务宕机了，整个服务系统全部完蛋，从业务层面上看，增强了用户体验，运营角度看，不至于太难看。如果玩过dubbo的话，那对熔断机制了解的更详细了！