Spring Cloud

Hystrix两种隔离模式分析

2018-07-06  本文已影响33人  Java及SpringBoot

1.hystrix 隔离模式目前有两种方式:信号量模式和线程池模式。

但信号量并不支持超时,当被调服务发生问题时,有少部分用户会长时间无法得到响应。

另外,使用线程池模式无法传递 Header,我估计是由于线程切换,参数传递过程中被去掉了。

587aed6cdd284d3995246e5eaf890c35-image.png

目前 hystrix 熔断器支持的隔离策略主要是信号量和线程池两种方式

信号量的使用示意图如下图所示,当 n 个并发请求去调用一个目标服务接口时,都要获取一个信号量才能真正去调用目标服务接口,但信号量有限,默认是 10 个,可以使用 maxConcurrentRequests 参数配置,如果并发请求数多于信号量个数,就有线程需要进入队列排队,但排队队列也有上限,默认是 5,如果排队队列也满,则必定有请求线程会走 fallback 流程,从而达到限流和防止雪崩的目的。

07122136uv5i.png

信号量模式从始至终都只有请求线程自身,是同步调用模式,不支持超时调用,不支持直接熔断,由于没有线程的切换,开销非常小。

线程池的使用示意图如下图所示,当 n 个请求线程并发对某个接口请求调用时,会先从 hystrix 管理的线程池里面获得一个线程,然后将参数传递给这个线程去执行真正调用。线程池的大小有限,默认是 10 个线程,可以使用 maxConcurrentRequests 参数配置,如果并发请求数多于线程池线程个数,就有线程需要进入队列排队,但排队队列也有上限,默认是 5,如果排队队列也满,则必定有请求线程会走 fallback 流程。

线程池模式可以支持异步调用,支持超时调用,支持直接熔断,存在线程切换,开销大。

把执行依赖代码的线程与请求线程(如:jetty线程)分离,请求线程可以自由控制离开的时间(异步过程)。

通过线程池大小可以控制并发量,当线程池饱和时可以提前拒绝服务,防止依赖问题扩散。

线上建议线程池不要设置过大,否则大量堵塞线程有可能会拖慢服务器。

07122201jfas.png

2.Hystrix如何解决依赖隔离

3.Hystrix流程结构解析

img
流程说明:
1:每次调用创建一个新的HystrixCommand,把依赖调用封装在run()方法中.
2:执行execute()/queue做同步或异步调用.
3:判断熔断器(circuit-breaker)是否打开,如果打开跳到步骤8,进行降级策略,如果关闭进入步骤.
4:判断线程池/队列/信号量是否跑满,如果跑满进入降级步骤8,否则继续后续步骤.
5:调用HystrixCommand的run方法.运行依赖逻辑
5a:依赖逻辑调用超时,进入步骤8.
6:判断逻辑是否调用成功
6a:返回成功调用结果
6b:调用出错,进入步骤8.
7:计算熔断器状态,所有的运行状态(成功, 失败, 拒绝,超时)上报给熔断器,用于统计从而判断熔断器状态.
8:getFallback()降级逻辑.
  以下四种情况将触发getFallback调用:
 (1):run()方法抛出非HystrixBadRequestException异常。
 (2):run()方法调用超时
 (3):熔断器开启拦截调用
 (4):线程池/队列/信号量是否跑满
8a:没有实现getFallback的Command将直接抛出异常
8b:fallback降级逻辑调用成功直接返回
8c:降级逻辑调用失败抛出异常
9:返回执行成功结果

4.熔断器:Circuit Breaker

每个熔断器默认维护10个bucket,每秒一个bucket,每个bucket记录成功,失败,超时,拒绝的状态,

默认错误超过50%且10秒内超过20个请求进行中断拦截.

img
上一篇 下一篇

猜你喜欢

热点阅读