java技术--SpringCloud:Hystrix概念解析(11)

1.服务故障的“雪崩”效应

（1）在微服务架构中，根据业务来拆分成一个个的服务
（2）服务间能相互调用(RPC),在SpringCloud用RestTemplate+Ribbon或Feign来调用
（3）为了保证其高可用，单个服务通常会集群部署
（4）由于网络原因或者自身的原因，服务并不能保证100%可用
   <1>如果单个服务出现问题，调用这个服务就会出现线程阻塞
   <2>此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪
   <3>服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果
（5）这就是服务故障的“雪崩”效应，为了解决这个问题，业界提出了断路器模型  
   <1>断路器模型主要从服务熔断、服务降级两方面解决服务故障的“雪崩”效应
（6）服务熔断
   <1>熔断机制是应对雪崩效应的一种微服务链路保护机制 
   <2>熔断亦称为过载保护
   <3>熔断机制的注解是@HystrixCommand
（7）服务降级
   <1>整体资源快不够用了，忍痛将某些服务先关掉，待度过难关，在开启回来
   <2>所谓降级，就是一般是从整体符合考虑
     2.1.当某个服务熔断之后，服务器将不再被调用
     2.2.此刻客户端可以自己准备一个本地的fallback回调，返回一个缺省值
     2.3.这样做，虽然服务水平下降，但好歹可用，比直接挂掉要强     

2.断路器简介

（1）Netflix创建了一个名为Hystrix的库，实现了断路器模式
   <1>Netflix开源了Hystrix组件，实现了断路器模式
   <2>SpringCloud对这一组件进行了整合
   <3>在微服务架构中，一个请求需要调用多个服务是非常常见的
（2）在微服务架构中，通常有多层服务调用
   <1>较底层的服务如果出现故障，会导致连锁故障
   <2>当对特定服务的调用不可用达到一个阀值（Hystric是5秒20次）断路器将会被打开
   <3>断路打开后，可避免连锁故障，fallback方法可以直接返回一个固定值
   <4>Hystrix能够保证不会导致整个服务失败，避免级联故障，以提高分布式系统的弹性

3.Hystrix工作原理

（1）Hystrix 是一个帮助解决分布式系统交互时超时处理和容错的类库
   <1>它同样拥有保护系统的能力,Netflix的众多开源项目之一
（2）隔离：
   <1> Hystrix隔离方式采用线程/信号的方式，通过隔离限制依赖的并发量和阻塞扩散
   <2> 线程隔离:Hystrix在用户请求和服务之间加入了线程池
     2.1.Hystrix为每个依赖调用分配一个小的线程池,若线程池已满调用将被立即拒绝
     2.2.默认不采用排队.加速失败判定时间，线程数是可以被设定的
     2.3. 线程隔离原理：
       2.3.1.用户的请求将不再直接访问服务，而是通过线程池中的空闲线程来访问服务
       2.3.2.如果线程池已满，则会进行降级处理，用户的请求不会被阻塞
       2.3.3.可以看到一个执行结果友好提示，而不是无休止的等待或者看到系统崩溃
   <3>信号隔离:
     3.1.信号隔离也可以用于限制并发访问，防止阻塞扩散
     3.2.与线程隔离最大不同在于执行依赖代码的线程依然是请求线程
      3.2.1.该线程需要通过信号申请
      3.2.2.若客户端是可信的且可快速返回，可以使用信号隔离替换线程隔离,降低开销 
      3.2.3.信号量的大小可以动态调整, 线程池大小不可以
（3）熔断：
   <1>如果某个目标服务调用慢或者有大量超时，此时，熔断该服务的调用
   <2>对于后续调用请求，不在继续调用目标服务，直接返回，快速释放资源
   <3>如果目标服务情况好转则恢复调用
   <4>熔断器:Circuit Breaker
     4.1.熔断器是位于线程池之前的组件
     4.2.用户请求某一服务之后，Hystrix会先经过熔断器
     4.3.如果熔断器的状态是打开（跳起），则说明已经熔断
       4.3.1.这时将直接进行降级处理，不会继续将请求发到线程池  
       4.3.2.熔断器相当于在线程池之前的一层屏障
       4.3.3.每个熔断器默认维护10个bucket
         4.3.3.1.每秒创建一个bucket
         4.3.3.2.每个blucket记录成功,失败,超时,拒绝的次数 
         4.3.3.3.当有新的bucket被创建时，最旧的bucket会被抛弃
   <5>熔断器的状态机:
     5.1.Closed：
        5.1.1.熔断器关闭状态，调用失败次数积累
        5.1.2.到了阈值（或一定比例）则启动熔断机制
     5.2.Open：
        5.2.1.熔断器打开状态，此时对下游的调用都内部直接返回错误，不走网络
        5.2.2.但设计了一个时钟选项
        5.2.3.默认的时钟达到了一定时间（一般设置成平均故障处理时间）
        5.2.4.到了这个时间，进入半熔断状态   
     5.3.Half-Open：
        5.3.1.半熔断状态，允许定量的服务请求
        5.3.2.如果调用都成功（或一定比例）则认为恢复了，关闭熔断器
        5.3.3.否则认为还没好，又回到熔断器打开状态          

4.Hystrix执行流程

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

5.Hystrix执行方式

（1）同步执行：
   <1>即一旦开始执行该命令
   <2>当前线程就得阻塞着直到该命令返回结果，然后才能继续执行下面的逻辑
（2）异步执行：
   <1>命令开始执行会返回一个Future<T>的对象，不阻塞后面的逻辑
   <2>开发者自己根据需要去获取结果
（3）响应式执行：
   <1>命令开始执行会返回一个Observable<T> 对象
   <2>开发者可以给Obeservable对象注册上Observer或者Action1对象
   <3>响应式地处理命令执行过程中的不同阶段
     3.1.当调用HystrixCommand的observe()方法
     3.2.或使用Observable的工厂方法（just(),from()）即为响应式执行
     3.3.这个功能的实现是基于Netflix的另一个开源项目RxJava来的   
       3.3.1.开源项目RxJava网址：https://github.com/Netflix/RxJava

6.参考文献

（1）https://www.cnblogs.com/yawen/p/6655352.html