SpringCloud之Hystrix服务降级（七）

Hystrix设计原则

　　1.防止单个服务的故障，耗尽整个系统服务的容器（比如tomcat）的线程资源，避免分布式环境里大量级联失败。通过第三方客户端访问（通常是通过网络）依赖服务出现失败、拒绝、超时或短路时执行回退逻辑

2.用快速失败代替排队(每个依赖服务维护一个小的线程池或信号量，当线程池满或信号量满，会立即拒绝服务而不会排队等待)和优雅的服务降级；当依赖服务失效后又恢复正常，快速恢复

3.提供接近实时的监控和警报，从而能够快速发现故障和修复。监控信息包括请求成功，失败（客户端抛出的异常），超时和线程拒绝。如果访问依赖服务的错误百分比超过阈值,断路器会跳闸，此时服务会在一段时间内停止对特定服务的所有请求

4.将所有请求外部系统（或请求依赖服务）封装到HystrixCommand或HystrixObservableCommand对象中，然后这些请求在一个独立的线程中执行。使用隔离技术来限制任何一个依赖的失败对系统的影响。每个依赖服务维护一个小的线程池（或信号量），当线程池满或信号量满，会立即拒绝服务而不会排队等待

Hystrix特性

　　1.请求熔断： 当Hystrix Command请求后端服务失败数量超过一定比例(默认50%), 断路器会切换到开路状态(Open). 这时所有请求会直接失败而不会发送到后端服务. 断路器保持在开路状态一段时间后(默认5秒), 自动切换到半开路状态(HALF-OPEN).

　　　 这时会判断下一次请求的返回情况, 如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN). Hystrix的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力.

　　2.服务降级：Fallback相当于是降级操作. 对于查询操作, 我们可以实现一个fallback方法, 当请求后端服务出现异常的时候, 可以使用fallback方法返回的值. fallback方法的返回值一般是设置的默认值或者来自缓存.告知后面的请求服务不可用了，不要再来了。

　　3.依赖隔离(采用舱壁模式，Docker就是舱壁模式的一种)：在Hystrix中, 主要通过线程池来实现资源隔离. 通常在使用的时候我们会根据调用的远程服务划分出多个线程池.比如说，一个服务调用两外两个服务，你如果调用两个服务都用一个线程池，那么如果一个服务卡在哪里，资源没被释放

　　　后面的请求又来了，导致后面的请求都卡在哪里等待，导致你依赖的A服务把你卡在哪里，耗尽了资源，也导致了你另外一个B服务也不可用了。这时如果依赖隔离，某一个服务调用A B两个服务，如果这时我有100个线程可用，我给A服务分配50个，给B服务分配50个，这样就算A服务挂了，

　　　我的B服务依然可以用。

　　4.请求缓存：比如一个请求过来请求我userId=1的数据，你后面的请求也过来请求同样的数据，这时我不会继续走原来的那条请求链路了，而是把第一次请求缓存过了，把第一次的请求结果返回给后面的请求。

　　5.请求合并：我依赖于某一个服务，我要调用N次，比如说查数据库的时候，我发了N条请求发了N条SQL然后拿到一堆结果，这时候我们可以把多个请求合并成一个请求，发送一个查询多条数据的SQL的请求，这样我们只需查询一次数据库，提升了效率。

Hystrixl流程图如下：

Hystrix流程说明:

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

这里接着前面的Ribbon进行Hystrix集成。说白了你想对一个请求进行熔断，必然不能让客户直接去调用那个请求，你必然要要对别人的请求进行包装一层和拦截，才能做点手脚，比如进行熔断，所以说要在Ribbon上动手脚。因为它是请求发起的地方。

我们刚开始请求一个服务，为了负载均衡进行了拦截一次，现在我们要进行熔断，所以必须跟Ribbon集成一次，再进行请求拦截来熔断。

具体配置参照上面一些，下面为一些不同之处：

• order-service

  • application.yml

     server:
       port: 8781
     ​
     ​
     #指定注册中心地址
     eureka:
       client:
         serviceUrl:
           defaultZone: http://localhost:8761/eureka/
     ​
     #服务的名称
     spring:
       application:
         name: order-service
     ​
     ###配置请求超时时间
     hystrix:
       command:
         default:
           execution:
             isolation:
               thread:
                  timeoutInMilliseconds: 7000
     ribbon:
     ##指的是建立连接所用的时间，适用于网络状况正常的情况下，两端连接所用的时间。
       ReadTimeout: 2000
     ##指的是建立连接后从服务器读取到可用资源所用的时间。
       ConnectTimeout: 3000
     feign:
       hystrix:
         enabled: true
     ​
     #自定义负载均衡策略
     #product-service:
     #  ribbon:
     #    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

  • 新增一个回调类

   /**
    * @author WGR
    * @create 2019/10/19 -- 19:36
    */
   @Component
   public class ProductClientFallback implements ProductClient {
   ​
       @Override
       public String findById(int id) {
   ​
           System.out.println("feign 调用product-service findbyid 异常");
   ​
           return "123";
       }
   ​
   ​
   ​
   }
   ​

  • 修改注解

  @FeignClient(name = "product-service", fallback = ProductClientFallback.class)
  public interface ProductClient {
  ​
  ​
      @GetMapping("/api/v1/product/find")
      String findById(@RequestParam(value = "id") int id);
  ​
  ​
  }

  测试：

  控制台先会打印：feign 调用product-service findbyid 异常，说明是先调用了这个方法。