Hystrix断路器是如何工做的

前言

20181130，Hystrix已经再也不维护，这里是学习记录。12月1日才完成，没有完成11月的诺言，捐款记录以上动弹。 https://my.oschina.net/floor/tweet/19421296

Hystrix是什么

Hystrix是一个java类库，提供了服务容错保护

遇到的问题

• 请求响应时间过长，形成资源不能被及时释放。短时巨量请求形成资源耗尽，最终形成系统没法响应。
• 系统中一个服务服务出现故障，影响其余系统，形成系统级联故障。
• 请求不受约束或者未进行批处理，系统会逐渐变慢失去响应 注 (资源多是，线程，网络链接，内存等)

Hystrix解决方案

• 超时后取消与外部服务的链接;释放系统资源，并使系统响应 线程和网络使用受到线程池和信号量的限制。
• 当资源消耗到它们的约束时，以后的请求将失败，而不是排队
• 当发生故障时，能够在适当的时候使用fallback;
• 可使用批处理请求;更有效地利用本地及外来服务资源

工做流程

官方工做流程图一共9步以下，逻辑简单。

1. 建立对象HystrixCommand和HystrixObservableCommand对象
2. 命令执行
3. 缓存中是否有结果
4. 断路器是否打开
5. 信号量/线程池是否拒绝
6. HystrixObservableCommand.construct()或者HystrixCommand.run()
7. 计算断路器的健康度
8. fallback处理
9. 返回成功的响应

断路器原理

其原理说明以下：

1. 假设请求量达到必定的阈值(HystrixCommandProperties.circuitBreakerRequestVolumeThreshold())
2. 假设错误百分比超过阈值错误百分比 (HystrixCommandProperties.circuitBreakerErrorThresholdPercentage())
3. 知足其一，打开断路器。
4. 当短路其打开，短路全部进过该短路器的请求。
5. 一段时间后(HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds())， 容许一个请求经过（此时短路器为半开状态）,若是该请求成功，短路其设置为打开，不然将短路器设置为关闭，从1开始再进行判断。

依赖隔离

Hystrix使用“舱壁模式”。默认使用线程池。 为每个依赖服务建立一个独立的线程池，这样若是一个依赖服务出现故障，只对该依赖服务的调用产生影响，不会拖累其余服务。以下图所示：

• 线程池隔离优势

• 当服务从失效恢复正常后，线程池会被清理，立刻恢复健康的服务，而容器级别要满不少。

• 失败次数，延迟，超时，拒绝等指标，会快速反应出问题，结合Spring Cloud 能够实现动态刷新。

• 线程池内置了并发实现，为同步依赖服务构建异步访问。

请求合并

解决，通讯占用和链接消耗问题。在一个很短的时间窗口（默认10ms）内对多个请求进行合并以批处理的方式发送请求。 缺点：

• 形成单个响应的延迟，若是单个响应是5ms，默认时间窗口是10ms，这个请求的响应就变为了15ms
• 用户须要实现批量化服务和处理，增长了一些成本。 请求合并示意图以下：