hystrix原理篇

hystrix 流程

1、工作流程

1.1 工作流程图

1.2工作流程说明：
红圈 ：Hystrix 命令执行失败，执行回退逻辑。也就是大家经常在文章中看到的“服务降级”。
绿圈 ：四种情况会触发失败回退逻辑( fallback )。
第一种 ：short-circuit ，处理链路处于熔断的回退逻辑，在 「3. #handleShortCircuitViaFallback()」 详细解析。
第二种 ：semaphore-rejection ，处理信号量获得失败的回退逻辑，在 「4. #handleShortCircuitViaFallback()」 详细解析。
第三种 ：thread-pool-rejection ，处理线程池提交任务拒绝的回退逻辑，在 「5. #handleThreadPoolRejectionViaFallback()」 详细解析。
第四种 ：execution-timeout ，处理命令执行超时的回退逻辑，在 「6. #handleTimeoutViaFallback()」 详细解析。
第五种 ：execution-failure ，处理命令执行异常的回退逻辑，在 「7. #handleFailureViaFallback()」 详细解析。
第六种 ：bad-request ，TODO 【2014】【HystrixBadRequestException】，和 hystrix-javanica 子项目相关。

另外，#handleXXXX() 方法，整体代码比较类似，最终都是调用 #getFallbackOrThrowException() 方法，获得【回退逻辑 Observable】或者【异常 Observable】，在 「8. #getFallbackOrThrowException(…)」 详细解析。

1.3 简图一说明：

1.4 简图二说明：

2、短路原理

2.1 短路原理图：

2.2 短路原理图说明：

• 假设请求量达到一定的阈值(HystrixCommandProperties.circuitBreakerRequestVolumeThreshold())
• 假设错误百分比超过阈值错误百分比
  (HystrixCommandProperties.circuitBreakerErrorThresholdPercentage())
• 满足1、2后，打开断路器。
• 当短路其打开，短路所有进过该短路器的请求。
• 一段时间后(HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds())， 允许一个请求通过（此时短路器为半开状态）,如果该请求成功，短路其设置为打开，否则将短路器设置为关闭，从1开始再进行判断。

3、 Hystrix执行步骤与原理

• 构建一个HystrixCommand或者HystrixObservableCommand
• 调用command的执行方法
• 检查是否开启缓存
• 检查是否开启了短路器
  检查这个command对应的依赖服务是否开启了短路器 如果断路器被打开了，那么hystrix就不会执行这个command，而是直接去执行fallback降级机制
• 检查线程池/队列/semaphore是否已经满了
  如果command对应的线程池/队列/semaphore已经满了，那么也不会执行command，而是直接去调用fallback降级机制
• 执行command
• 短路健康检查
  • Hystrix会将每一个依赖服务的调用成功，失败，拒绝，超时，等事件，都会发送给circuit breaker断路器
  • 短路器就会对调用成功/失败/拒绝/超时等事件的次数进行统计
  • 短路器会根据这些统计次数来决定，是否要进行短路，如果打开了短路器，那么在一段时间内就会直接短路，然后如果在之后第一次检查发现调用成功了，就关闭断路器
• 调用fallback降级机制
  • 在以下几种情况中，hystrix会调用fallback降级机制：run()或construct()抛出一个异常，短路器打开，线程池/队列/semaphore满了，command执行超时了

4、断路器工作原理

4.1 断路器执行步骤

• 如果经过短路器的流量超过了一定的阈值，HystrixCommandProperties.circuitBreakerRequestVolumeThreshold()

举个例子，可能看起来是这样子的，要求在10s内，经过短路器的流量必须达到20个；
在10s内，经过短路器的流量才10个，那么根本不会去判断要不要短路

• 如果断路器统计到的异常调用的占比超过了一定的阈值，HystrixCommandProperties.circuitBreakerErrorThresholdPercentage()
  如果达到了上面的要求，比如说在10s内，经过短路器的流量（只要执行一个command，这个请求就一定会经过短路器），达到了30个；同时其中异常的访问数量，占到了一定的比例，比如说60%的请求都是异常（报错，timeout，reject），会开启短路
• 断路器从close状态转换到open状态
• 断路器打开的时候，所有经过该断路器的请求全部被短路，不调用后端服务，直接走fallback降级
• 经过了一段时间之后，HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds()，会half-open，让一条请求经过短路器，看能不能正常调用。如果调用成功了，那么就自动恢复，转到close状态

5、hytrix支持线程池隔离和信号量隔离

图示：

表格对比说明：

隔离方式	是否支持超时	是否支持熔断	隔离原理	是否是异步调用	资源消耗
线程池隔离	支持，可直接返回	支持，当线程池到达maxSize后，再请求会触发fallback接口进行熔断	每个服务单独用线程池	可以是异步，也可以是同步。看调用的方法	大，大量线程的上下文切换，容易造成机器负载高
信号量隔离	支持， 不是立即返回	支持，当信号量达到maxConcurrentRequests后。再请求会触发fallback	通过信号量的计数器	同步调用，不支持异步	小，只是个计数器

在1.4.0之后的版本，信号量也就支持了超时时间，此时参数统一修改成了withExecutionTimeoutInMilliseconds
注意信号量超时详解看该文章： https://toutiao.io/posts/ztgdr2/preview

5.1、信号量的隔离：
每次调用线程，当前请求通过计数信号量进行限制，当信号大于了最大请求数（maxConcurrentRequests）时，进行限制，调用fallback接口快速返回。

最重要的是，信号量的调用是同步的，也就是说，每次调用都得阻塞调用方的线程，直到结果返回。这样就导致了无法对访问做超时（只能依靠调用协议超时，无法主动释放）

5.2、信号量隔离的描述建议：

• 隔离的细粒度太高，数百个实例需要隔离，此时用线程池做隔离开销过大
• 通常这种都是非网络调用的情况下

5.3、线程池隔离：

• 通过每次都开启一个单独线程运行，它的隔离是通过线程池，即每个隔离粒度都是个线程池，互相不干扰
• 线程池隔离方式，等于多了一层的保护措施，可以通过hytrix直接设置超时，超时后直接返回。
  下面通过图理解：
  

x、注意事项

单次执行出现报错、超时、超时最大请求异常会执行fallback逻辑， 但是断路器不一定打开。
断路器打开逻辑：
1.整个链路达到一定的阈值，默认情况下，10秒内产生超过20次请求，则符合第一个条件
2.满足第一个条件的情况下，如果请求的错误百分比大于阈值，则会打开断路器，默认50%

比如说在10s内，经过短路器的流量（你，只要执行一个command，这个请求就一定会经过短路器），达到了20个；同时其中异常的访问数量，占到了一定的比例，比如说60%的请求都是异常（报错，timeout，reject），会开启短路

信号量隔离：
比如，服务A的信号量大小为 10，那么就是说它同时只允许有 10
每次请求， 先获取信号量， 获取失败执行fallback 机制，
获取到信号量的线程继续发起访问， 访问完成归还信号量。

参考地址：
https://github.com/Netflix/Hystrix/wiki/How-it-Works
https://juejin.im/post/5d5687e9e51d456205410399
https://www.comsince.cn/wiki/2018-12-14-distribute-histrix/
https://cnblogs.com/duanxz/p/7521009.html
https://my.oschina.net/u/867417/blog/2120713
http://liuxiang.github.io/2018/03/30/Hystrix(%E7%86%94%E6%96%AD%E5%99%A8)%20%E4%BD%93%E9%AA%8C/