SpringCloud——Hystrix入门

SpringCloud——Hystrix

前言

主页：https://github.com/Netflix/Hystrix/

Hystix是Netflix开源的一个延迟和容错库，用于隔离访问远程服务，防止出现级联失败。

一、雪崩问题

示例：微服务中，服务间调用关系错综复杂，一个请求，可能需要调用多个微服务接口才能实现，会形成非常复杂的调用链路：
如图，一次业务请求，需要调用A、P、H、I四个服务，这四个服务又可能调用其它服务。 如果此时，某个服务出现异常：

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

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

解决方案：

Hystrix解决雪崩问题的手段，主要包括：

• 线程隔离
• 服务降级

二、线程隔离&服务降级

1. 原理

线程隔离示意图

• Hystrix为每个依赖服务调用分配一个小的线程池，如果线程池已满调用将被立即拒绝，默认不采用排队，加速失败判定时间。
• 用户的请求将不再直接访问服务，而是通过线程池中的空闲线程来访问服务，如果线程池已满，或者请求超时，则会进行降级处理，什么是服务降级？

服务降级：可以优先保证核心服务。

用户的请求故障时，不会被阻塞，更不会无休止的等待或者看到系统崩溃，至少可以看到一个执行结果（例如返回友好的提示信息）

服务降级虽然会导致请求失败，但是不会导致阻塞，而且最多会影响这个依赖服务对应的线程池中的资源，对其它服务没有影响

触发Hystrix服务降级的情况：

• 线程池已满
• 请求超时

2. 针对消费端的操作

1. 引入依赖

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

2. 开启熔断

在消费端启动类上加上注解@EnableCircuitBreaker

@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
public class ConsumerApplication {
// ...
}

这里的三个注解可以合并为@SpringCloudApplication一个注解

3. 编写降级逻辑

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

改造消费端的controller如下：（举了个例子）

@RestController
@RequestMapping("/consumer")
public class ConsumerController {
    @Autowired
    private RestTemplate restTemplate;
    
    @GetMapping("{id}")
    @HystrixCommand(fallbackMethod = "queryByIdFallback")
    public String queryById(@PathVariable Long id) {
        String url = "http://user-service/user/" + id;
        return restTemplate.getForObject(url, String.class);
    }
    
    public String queryByIdFallback(Long id) {
        return "对不起，网络太拥挤了！";
    }
}

说明一下，user-service是原先写好的一个服务端的名字，提供了一个rest接口/user/id，这里的queryById方法用来根据id查询user

注意：

1. @HystrixCommand(fallbackMethod = “queryByIdFallBack”)：用来声明一个降级逻辑的方法
2. 因为熔断的降级逻辑方法必须跟正常逻辑方法保证：相同的参数列表和返回值声明。

测试：
当 user-service 正常提供服务时，访问与以前一致。但是当将 user-service 停机时，会发现页面返回了降级处理信息：

4. 默认的fallback

可以把Fallback配置加在类上，实现默认fallback
@DefaultProperties(defaultFallback = “defaultFallBack”)：在类上指明统一的失败降级方法；该类中所有方法返回类型要与处理失败的方法的返回类型一致。

@RestController
@RequestMapping("/consumer")
@DefaultProperties(defaultFallback = "defaultFallback")
public class ConsumerController {
    @Autowired
    private RestTemplate restTemplate;

    @GetMapping("{id}")
    //@HystrixCommand(fallbackMethod = "queryByIdFallback")
    @HystrixCommand
    public String queryById(@PathVariable Long id) {
        String url = "http://user-service/user/" + id;
        return restTemplate.getForObject(url, String.class);
    }
    public String queryByIdFallback(Long id) {
        return "对不起，网络太拥挤了！";
    }
    public String defaultFallback() {
        return "默认提示：对不起，网络太拥挤了！";
    }
}

5. 超时设置

在之前的案例中，请求在超过1秒后都会返回错误信息，这是因为Hystrix的默认超时时长为1，我们可以通过配置修改这个值；修改 消费端application.yml 添加如下配置：

hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 2000

复制这个更方便

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=2000

为了触发超时，可以在服务端相应的方法中让线程休眠两秒

try {
    Thread.sleep(2000);
} catch (InterruptedException e) {
    e.printStackTrace();
}

可以看到请求超过了两秒然后失败了

三、服务熔断

1. 熔断原理

在服务熔断中，使用的熔断器，也叫断路器，其英文单词为：Circuit Breaker 熔断机制与家里使用的电路熔断原理类似；当如果电路发生短路的时候能立刻熔断电路，避免发生灾难。在分布式系统中应用服务熔断后；服务调用方可以自己进行判断哪些服务反应慢或存在大量超时，可以针对这些服务进行主动熔断，防止整个系统被拖垮。
Hystrix的服务熔断机制，可以实现弹性容错；当服务请求情况好转之后，可以自动重连。通过断路的方式，将后续请求直接拒绝，一段时间（默认5秒）之后允许部分请求通过，如果调用成功则回到断路器关闭状态，否则继续打开，拒绝请求的服务。

Hystrix的熔断状态机模型：

状态机有3个状态：

1. Closed：关闭状态（断路器关闭），所有请求都正常访问。
2. Open：打开状态（断路器打开），所有请求都会被降级。Hystrix会对请求情况计数，当一定时间内失败请求百分比达到阈值，则触发熔断，断路器会完全打开。默认失败比例的阈值是50%，请求次数最少不低于20次。
3. Half Open：半开状态，不是永久的，断路器打开后会进入休眠时间（默认是5S）。随后断路器会自动进入半开状态。此时会释放部分请求通过，若这些请求都是健康的，则会关闭断路器，否则继续保持打开，再次进行休眠计时

也就是这个意思：

2. 上手操作

为了能够精确控制请求的成功或失败，我们在消费端的controller中施加魔法

@GetMapping("{id}")
@HystrixCommand
public String queryById(@PathVariable Long id) {
    if (id == 1) {
        throw new RuntimeException("太忙了");
    }
    String url = "http://user-service/user/" + id;
    String user = restTemplate.getForObject(url, String.class);
    return user;
}

这样如果参数是id为1，一定失败，其它情况都成功，所以现在我们准备两个请求窗口：

• 一个请求：http://localhost:8080/consumer/1，注定失败
• 一个请求：http://localhost:8080/consumer/2，肯定成功

当我们疯狂访问id为1的请求时（超过20次），就会触发熔断。断路器会打开，一切请求都会被降级处理。不过，默认的熔断触发要求较高，休眠时间窗较短，为了测试方便，我们可以通过配置修改熔断策略：消费端的application.yml

方便大家复制：

hystrix.command.default.circuitBreaker.requestVolumeThreshold=10
hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds=10000
hystrix.command.default.circuitBreaker.errorThresholdPercentage=50
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=2000

重启消费端，接下来就疯狂发送第一个注定失败的请求，然后再尝试第二个本应该会成功的请求，发现也不行了，那就对了