Hystrix能解决的问题

╰半橙微兮° 2022-01-07 03:43 270阅读 0赞

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