Hystrix能解决的问题

Hystrix

问题产生

• 雪崩效应： 一种因为服务提供者的不可用导致服务调用者不可用，并将不可用情况逐渐放大的过程

• 形成过程：

  • 服务提供者不可用：
    • 硬件故障，硬件损坏，服务器宕机，网络硬件故障，造成不可用
    • 程序bug
    • 缓存击穿：大量请求同一个key此处key过期，导致loder到DB造成服务提供者过载导致不可用
    • 用户大量请求：
  • 重试加大流量：
    • 用户重试：用户不断刷新页面
    • 代码逻辑重试：服务调用端存在服务异常之后的重试逻辑
  • 服务调用者不可用：
    • 同步调用等待造成资源耗尽，服务调用者此时也不可用，造成服务雪崩

• 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中生产的事件。