阅读 200

Hystrix断路器是如何工作的

前言

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

Hystrix是什么

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

遇到的问题

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

Hystrix解决方案

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

工作流程

image

官方工作流程图一共9步如下,逻辑简单。

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

断路器原理

image

其原理说明如下:

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

依赖隔离

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

image

  • 线程池隔离优点

  • 当服务从失效恢复正常后,线程池会被清理,马上恢复健康的服务,而容器级别要满很多。

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

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

请求合并

解决,通信占用和连接消耗问题。在一个很短的时间窗口(默认10ms)内对多个请求进行合并以批处理的方式发送请求。 缺点:

  • 造成单个响应的延迟,如果单个响应是5ms,默认时间窗口是10ms,这个请求的响应就变为了15ms
  • 用户需要实现批量化服务和处理,增加了一些成本。 请求合并示意图如下:
    image
关注下面的标签,发现更多相似文章
评论