Hystrix
问题产生
-
雪崩效应: 一种因为服务提供者的不可用导致服务调用者不可用,并将不可用情况逐渐放大的过程
-
形成过程:
- 服务提供者不可用:
- 硬件故障,硬件损坏,服务器宕机,网络硬件故障,造成不可用
- 程序bug
- 缓存击穿:大量请求同一个key此处key过期,导致loder到DB造成服务提供者过载导致不可用
- 用户大量请求:
- 重试加大流量:
- 用户重试:用户不断刷新页面
- 代码逻辑重试:服务调用端存在服务异常之后的重试逻辑
- 服务调用者不可用:
- 同步调用等待造成资源耗尽,服务调用者此时也不可用,造成服务雪崩
- 服务提供者不可用:
-
Hystrix工作原理
- 线程池隔离:Hystrix隔离方式采用线程/信号量的方式,通过隔离限制依赖的并发量和阻塞扩散
- 线程隔离: hystrix在每一个依赖调用分配了一个线程池,单线程池满了调用将会立即被拒绝,默认采用不排队,加速失败判定,线程数是可以被设定的。
- 原理: 用户请求将不直接依赖于服务本身,而是通过线程池中空闲线程来范文服务,如果线程池已满,择进行降级处理,用户请求不会被阻塞,至少可以有一个执行结果,例如友好的提示,而不是无休止的等待知道系统奔溃
- 信号隔离:类似信号量的一个使用,用于限制并发访问,反正阻塞扩散,与现场隔离最大不同在于执行依赖代码的线程依然是请求线程(改线程需要通过信号申请,如果客户端是可以信的且可以快速放回,可以使用信号隔离代替线程隔离,降低开销),信号量大小可以动态调整
- 线程池隔离:Hystrix隔离方式采用线程/信号量的方式,通过隔离限制依赖的并发量和阻塞扩散
-
熔断器:circuit Breaker
- 熔断器是位于线程池之前的组建,当用户请求某一个服务之后,hystrix会先经过熔断器,此时如果熔断器的状态是打开,说明已经熔断的,这时将直接进行降级处理,不会继续发送请求到线程池,熔断器相当于线程池之前的一层屏障,每个熔断器默认维护十个bucket,美妙创建一个bucket,每个bucket记录成功,失败,超时,拒绝次数,当新的bucket被创建,旧的bucket被抛弃,依照bucket的记录来决定是否打开或者关闭断路器。
- 熔断器状态机:
- closed:熔断器关闭状态,调用失败次数累计到了阀值,或者一定比例,择启动熔断机制。
- open:熔断打开状态,下游调用直接返回错误,不走网络,不进入线程池,进入这个状态之后,设计了一个时钟选型,默认时间达到一定时间(一般设置成平均故障处理事件也就是MTTR)会进入半熔断状态
- half-open:半熔断状态,允许定量的服务请求(也就是一部分请求尝试)如果调用都成功,或者一定比例成功,则认为恢复,关闭断路器,否则认为还没好,有回到熔断打开状态。
-
熔断流程:
- 将请求request封装成一个HystrixCommend,或者HystrixObservableCommand对象
- 执行execute(),queue()方法来做同步或者异步调用
- 如果Hystrix缓存中有数据,则读取缓存数据,之后返回
- 检查熔断器,circuit-breaker是否打开,如果打开,择直接执行getFallback方法降级处理
- 判断线程池,信号量,队列是否被占满,如果满直接执行getFallBack方法降级处理
- 执行HystrixObservableCommand.construct()或者HystrixCommand.run()
- 如果调用超时,执行getFallback方法
- 如果调用异常抛出HystrixBadRequestException,也直接执行getFallback方法
- 调用成功返回成功结果
- getFallBack降级逻辑,以下情况执行
- 断路器已经打开
- 线程池,队列,信号量满
- run方法执行抛出HystrixBadrequestException
- run方法超时
- 没有实现getFallBack方法直接抛出异常信息
- 降级逻辑失败,也直接抛异常
-
Hystrix执行方式:刚才说的HystricCommend中的run方法,Hystrix可以有不同的执行策略
- execute为代表的同步执行:一旦开始执行,当前线程就得阻塞一直等到命令返回结果
- queue座位代表的异步执行:命令执行开始返回一个future对象,不阻塞后面的逻辑,开发者更具自己需求获取结果
- 响应式执行,HystrixObservableCommand中使用的模式:命令会返回一个Observable对象,开发可以给Observable对象注册上Observable,通过Rxjava的方式响应式的处理命令执行过程中的不同阶段,比如HystrixCommand中的Observer方法去消费observable中生产的事件。