Hystrix容错组件

Hystrix简介

---

Hystrix,英文意思是豪猪，全身是刺，看起来就不好惹，是一种保护机制。它是容错组件，Hystrix也是Netflix公司的一款组件。

那么Hystix的作用是什么呢？具体要保护什么呢？Hystix是Netflix开源的一个延迟和容错库，用于隔离访问远程服务、第三方库，防止出现级联失败。

雪崩问题

---

微服务中，服务间调用关系错综复杂，一个请求，可能需要调用多个微服务接口才能实现，会形成非常复杂的调用链路：

如图，一次业务请求，需要调用A、P、H、I四个服务，这四个服务又可能调用其它服务。如果此时，某个服务出现异常：

例如微服务 I 发生异常，请求阻塞，用户不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞：

服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，形成雪崩效应。

这就好比，一个汽车生产线，生产不同的汽车，需要使用不同的零件，如果某个零件因为种种原因无法使用，那么就会造成整台车无法装配，陷入等待零件的状态，直到零件到位，才能继续组装。 此时如果有很多个车型都需要这个零件，那么整个工厂都将陷入等待的状态，导致所有生产都陷入瘫痪。一个零件的波及范围不断扩大。

Hystix解决雪崩问题的手段有两个：

• 线程隔离(线程池隔离、信号量隔离)

• 服务熔断

服务降级

---

引入依赖

首先在spring-consumer的pom.xml中引入Hystrix依赖：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>

在服务调用方入口启动类上面加上 @EnableHystrix或 @EnableCircuitBreaker 注解，表示激活熔断器的默认配置,@EnableHystrix注解是 @EnableCircuitBreaker 的语义化，它们的关系类似于 @Service和 @Component 。

开启Hystrix熔断

@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
public class SpringConsumerApplication {
    @Bean
    @LoadBalanced
    public RestTemplate getRestTemplate(RestTemplateBuilder builder){
        return builder.build();
    }

    public static void main(String[] args) {
        SpringApplication.run(SpringConsumerApplication.class, args);
    }
}

我们类上的注解越来越多，在微服务中，经常会引入上面的三个注解，于是Spring就提供了一个组合注解：@SpringCloudApplication

@SpringCloudApplication
public class SpringConsumerApplication {

    @Bean
    @LoadBalanced
    public RestTemplate getRestTemplate(RestTemplateBuilder builder){
        return builder.build();
    }

    public static void main(String[] args) {
        SpringApplication.run(SpringConsumerApplication.class, args);
    }
}

编写降级逻辑

我们改造spring-consumer，当目标服务的调用出现故障，我们希望快速失败，给用户一个友好提示。因此需要提前编写好失败时的降级处理逻辑，要使用HystixCommond来完成：

@RestController
public class ConsumerController {

    @Autowired
    private RestTemplate restTemplate;

    @RequestMapping(value = "/consumerLoadBalanced/{id}")
    @HystrixCommand(fallbackMethod = "consumerLoadBalancedFallbackMethod")
    public String consumerLoadBalanced(@PathVariable String id){
        String url = "http://spring-provider/provider/" + id;
        String consumer = restTemplate.getForObject(url, String.class);
        return "LoadBalanced restTemplate consumer " + consumer;
    }

    public String consumerLoadBalancedFallbackMethod(String id){
        return "系统繁忙，请稍后再试！";
    }
}

要注意，降级逻辑方法必须跟正常逻辑方法保证：相同的参数列表和返回值声明。失败逻辑中返回User对象没有太大意义，一般会返回友好提示。所以我们把queryById的方法改造为返回String，反正也是Json数据。这样失败逻辑中返回一个错误说明，会比较方便。

说明：

• @HystrixCommand(fallbackMethod = "queryByIdFallBack")：用来声明一个降级逻辑的方法，当然这个注解里面还有其它的属性，默认情况下，读取hystrix的配置，对满足降级条件的进行统一降级，当然我们可以单独配置某个降级的业务方法，如

 @HystrixCommand(
    fallbackMethod = "fallBackMethod",
    commandProperties = {
        @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1000"),
        @HystrixProperty(name = "...", value = "..."),
        @HystrixProperty(name = "...", value = "...")
    }
)

默认FallBack

我们刚才把fallback写在了某个业务方法上，如果有很多这样的业务方法访问不了服务器都需要降级时，那岂不是要写很多，所以我们可以把Fallback配置加在类上，实现默认fallback：

@RestController
@DefaultProperties(defaultFallback = "fallBackMethod") // 指定一个类的全局降级方法
public class ConsumerController {

    @Autowired
    private RestTemplate restTemplate;

    @GetMapping
    @HystrixCommand // 标记该方法需要降级
    public String consumerLoadBalanced(@PathVariable String id){
        String url = "http://spring-provider/provider/" + id;
        String consumer = restTemplate.getForObject(url, String.class);
        return "LoadBalanced restTemplate consumer " + consumer;
    }

    /**
     * 降级方法
     * 返回值要和被降级的方法的返回值一致
     * 降级方法不需要参数
     * @return
     */
    public String fallbackMethod(){
        return "全局默认，系统繁忙，请稍后再试！";
    }
}

说明：

• @DefaultProperties(defaultFallback = "defaultFallBack")：在类上指明统一的失败降级方法

• @HystrixCommand：在方法上直接使用该注解，使用默认的降级方法。

• defaultFallback：默认降级方法，不用任何参数，以匹配更多方法，但是返回值一定一致

Hystrix超时配置

Hystrix 的全局配置也称为默认配置，它们在配置文件中通过 hystrix.command.default.* 来进行配置（再次强调，Hystrix 是用于服务的调用方，所以这里的配置自然也是配置在服务的调用方这边）

在之前的案例中，请求在超过1秒后都会返回错误信息，这是因为Hystix的默认超时时长为1秒，我们可以通过配置修改这个值：

我们可以通过hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds来设置Hystrix超时时间。该配置没有提示。

hystrix:
  command:
    default:  #也可以把default 改成某个服务名，针对某个服务。
      execution:
        isolation:
          thread:   #其实是对每一次http请求，就开启一个线程，hystrix内部有一个线程池。
            timeoutInMilliseconds: 6000 # 设置hystrix的超时时间为6000ms 
          strategy: THREAD    ##默认是采用线程池隔离技术   可以省略
             注意：配合测试，要改造服务提供者，打开浏览器 F12 看看时间

无论我们的使用的是 RestTemplate 还是 OpenFeign，它们都会是使用到 Ribbon 的负载均衡（和超时重试）能力。而 Ribbon 也会监管请求超时问题。所以，理论上，Hystrix 的超时时长的判断标准应该大于 Ribbon 的超时重试的总耗时，否则，会出现 Ribbon 还在『努力』，但是 Hystrix 决定『放弃』的情况。当然，这样也不是不行，只是有些不科学。

要注意：也就是说，hystrix触发熔断与ribbon的重试在机制上没关系，ribbon该重试还是会重试，如果有重试，还会使得被调用系统做无用且重复的业务

除了合理的参数值设置之外，你还可以直接关闭掉 Hystrix 的超时判断，完全由 Ribbon 来评判、上报（给 Hystrix）超时与否。

改造服务提供者

改造服务提供者的UserController接口，随机休眠一段时间

    @RequestMapping(value = "/provider/{id}")
    public String provider(@PathVariable String id){
        try {
            Thread.sleep(8000);
        } catch (InterruptedException e) {
            return "exception:" + e.getMessage();
        }
        return "provider id = " + id + "port = " + port;
    }

当6s 不能正常请求服务提供者，其实先触发熔断，然后再降级

服务熔断

---

熔断原理

熔断器，也叫断路器，其英文单词为：Circuit Breaker

熔断器3个状态：

• Closed：关闭状态，所有请求都正常访问。

• Open：打开状态，所有请求都会被降级。Hystrix会对请求情况计数，当一定时间内失败请求百分比达到阈值，则触发熔断，断路器会完全打开。默认失败比例的阈值是50%，请求次数最少不低于20次。默认是 五秒之内请求20次 如果有10次失败（50%），则请求不能正常访问。

• Half Open：半开状态，open状态不是永久的，打开后会进入休眠时间（默认是5S）。随后断路器会自动进入半开状态。此时会释放部分请求通过，若这些请求都是健康的，则会完全关闭断路器，否则继续保持打开，再次进行休眠计时

动手实践

为了能够精确控制请求的成功或失败，我们在provider业务中加入一段逻辑：

    @RequestMapping(value = "/provider/{id}")
    public String provider(@PathVariable String id){
        if(id.equals("1")){
            throw new RuntimeException("异常");
        }
        return "provider id = " + id + "port = " + port;
    }

消费方的业务代码

    @RequestMapping(value = "/consumerLoadBalanced/{id}")
    @HystrixCommand
    public String consumerLoadBalanced(@PathVariable String id){
        String url = "http://spring-provider/provider/" + id;
        String consumer = restTemplate.getForObject(url, String.class);
        return "LoadBalanced restTemplate consumer " + consumer;
    }
    public String fallbackMethod(){
        return "全局默认，系统繁忙，请稍后再试！";
    }

我们准备两个请求窗口：

• 一个请求：http://localhost:8280/consumerLoadBalanced/1，注定失败

• 一个请求：http://localhost:8280/consumerLoadBalanced/2，肯定成功

当我们疯狂访问id为1的请求时（超过20次），就会触发熔断。断路器会断开，一切请求都会被降级处理。

此时你访问id为2的请求，会发现返回的也是失败，过一段时间又恢复正常。

熔断策略配置

hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 6000
      circuitBreaker:
        requestVolumeThreshold: 20
        sleepWindowInMilliseconds: 10000
        errorThresholdPercentage: 50
        #forceOpen: true #是否强制开启熔断（跳闸），默认false，如果为true，则所有请求都将被拒绝，直接执行fallback降级方法

解读：

• requestVolumeThreshold：触发熔断的最小请求次数，默认20，通过一个窗口10s内请求数大于20个就启动熔断器

• errorThresholdPercentage：触发熔断的失败请求最小占比，默认50%

• sleepWindowInMilliseconds：休眠时长，默认是5000毫秒

• forceOpen 是否强制跳闸

解决灾难性雪崩

---

线程池隔离

在前面讲过，当大多数人在使用Tomcat时，多个HTTP请求不同的接口时，tomcat服务器会创建一个线程池，来处理这些请求，它们会共享这个线程池，假设其中一个HTTP请求某个接口访问的数据库响应非常慢，这将造成服务响应时间延迟增加，大多数线程阻塞等待数据响应返回，导致整个Tomcat线程池都的线程都被用完，甚至拖垮整个Tomcat。因此，如果我们能把不同接口请求隔离到不同的线程池，则请求某个接口的线程池满了也不会对其他服务造成灾难性故障。这就需要线程隔离或者信号量隔离来实现了

默认情况下 Hystrix 是使用线程池作为隔离策略，请求的每个接口都准备了独立的线程池，请求相同接口的线程池相同（从线程池中取出的一个线程里执行该请求），请求不同的接口会创建不同的线程池，如:用户请求/provider接口，那么hystrix就为这个接口创建一个线程池，池里可以规定多少个线程和一个缓存队列（假如说：池里有10个线程，队列大小100，那么这个并发量最大就是110，如果第111个请求也请求该接口时，如果没有线程被回收，队列也放不下，那么直接会降级）

hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 6000  
          strategy: THREAD    ##默认值  采用线程池隔离技术
-------------------------------------------------------
hystrix:
  threadpool:
    default:
      coreSize: 200
      maxQueueSize: 1000
      queueSizeRejectionThreshold: 800 
#第1201个请求不会立马降级，具体的要看线程请求的超时时间   配置......thread.timeoutInMilliseconds: 6000

参数	说明
coreSize	并发执行的最大线程数，默认 10
maxQueueSize	BlockingQueue 的最大队列数，默认值 -1
queueSizeRejectionThreshold	这个属性是控制队列最大阈值的，即使 maxQueueSize 没有达到，达到 queueSizeRejectionThreshold 该值后，请求也会被拒绝，默认值 5

需要说明的是必须配置maxQueueSize和queueSizeRejectionThreshold，不能只配一个

信号量隔离

底层使用原子计算器技术，针对每个服务（接口）都设置自己独立的阈值，比如设置每个服务接口最多同时只能访问50次，超出后则进行服务降级处理，当客户端需向依赖服务发起请求时， 计数器+1，请求返回成功后 计数器-1。

信号量隔离主要是通过控制并发请求量，防止请求线程大面积阻塞，从而达到限流和防止雪崩的目的

配置参数：

hystrix:
  command:
    default:  #也可以把default 改成某个服务名，针对某个服务。
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 6000
          strategy: SEMAPHORE   #线程池隔离技术   还有一种就是信号量隔离  strategy: SEMAPHORE

          semaphore:
            maxConcurrentRequests: 100   #默认信号量最大值是100

使用场景

线程池隔离：请求并发量大，并且耗时长（请求耗时长一般是计算量大，读数据库），采用线程池隔离，这样的话，可以保证大量的容器线程可用，不会由于服务原因，一直处于阻塞状态或等待状态，快速失败返回。

信号量隔离：请求并发量大，并且耗时短（请求耗时短可能是计算量小，读缓存），采用信号量隔离，因为这类服务的返回通常会非常快，不会占用容器线程太长时间，而且也减少了线程切换的一些开销，提高了缓存服务的效率。