服务降级——Hystrix

是什么

Hystix是Netflix开源的一个延迟和容错库，用于隔离访问远程服务、第三方库，防止出现级联失败。
这么说，可能大家还是不明白，那Hystrix到底是什么呢？

我们来模拟一个场景，在微服务的大环境下，一个请求可能调用多个后端服务，而某一个后端服务也可能需要调用其他的服务，如果此时，其中一个服务宕机或出现异常，导致服务无法返回结果，那么调用这个服务的其他服务将进行等待状态，如果此时又来了多个同样的请求，那么这些请求也将处于等待阻塞的状态，由于服务器支持的线程和并发的数量有限，请求一直阻塞将导致服务器资源耗尽，从而导致所有其它服务都不可用，形成雪崩效应。

那么Hystix的出现有什么作用呢？它用来解决雪崩问题的手段有两个：
1、线程隔离
2、服务熔断

目前Hystix也已经不在更新，逐渐被resilience4j和sentinel代替。

线程隔离，服务降级

1、服务降级

优先保证核心服务，而非核心服务不可用或弱可用。

触发Hystix服务降级的情况：

• 线程池已满
• 请求超时

2、线程隔离

Hystrix为每个依赖服务调用分配一个小的线程池，如果线程池已满调用将被立即拒绝，默认不采用排队.加速失败判定时间。这样一来，如果线程池已满，或者请求超时，则会对该请求进行降级处理。

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

3、实践

在上一篇文章项目的基础上服务调用-Ribbon，我们做以下配置：

（1）在消费者模块引入依赖

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

（2）开启熔断

启动类中加上注解

@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
public class ConsumerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConsumerApplication.class,args);
    }
}

Spring就提供了一个组合注解：@SpringCloudApplication，用来替换 上面的三个注解。

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

（3）编写降级逻辑

在controller中，添加降级逻辑

@RestController
public class TestServer {
//    private static final String ITEMSERVER_URL="http://localhost:8002";

    private static final String ITEMSERVER_URL="http://ITEM-SERVER";

    @Autowired
    private RestTemplate restTemplate;

    @GetMapping("/test")
    @HystrixCommand(fallbackMethod = "queryUserByIdFallBack") //用来声明一个降级逻辑的方法
    public CommonResult<Integer> test(){
        return restTemplate.getForObject(ITEMSERVER_URL+"/test",CommonResult.class);
    }

    public CommonResult<Integer> queryUserByIdFallBack(){
        return new CommonResult<>(500,"请求繁忙，请稍后再试！");
    }
}

在接口方法上面添加一个注解@HystrixCommand，用来声明一个降级逻辑的方法。熔断的降级逻辑方法必须跟正常逻辑方法保证：相同的参数列表和返回值声明。

我们重启服务，当item-server提供正常服务时，访问与之前一致，但是我们突然关掉item-server 会发现页面返回了降级处理信息。

上面只是示范了一个方法，如果有多个方法需要进行降级处理，难道我们需要一个个的加上一个降级方法吗？答案当然不是的，我们可以将我们的降级处理的注解加载类上，在类上制定一个全局熔断的方法：

@RestController
@DefaultProperties(defaultFallback = "queryUserByIdFallBack") // 指定一个类的全局熔断方法
public class TestServer {
//    private static final String ITEMSERVER_URL="http://localhost:8002";

    private static final String ITEMSERVER_URL="http://ITEM-SERVER";

    @Autowired
    private RestTemplate restTemplate;

    @GetMapping("/test")
//    @HystrixCommand(fallbackMethod = "queryUserByIdFallBack") //用来声明一个降级逻辑的方法
    @HystrixCommand //标记该方法需要熔断
    public CommonResult<Integer> test(){
        return restTemplate.getForObject(ITEMSERVER_URL+"/test",CommonResult.class);
    }

    /**
     * 熔断方法
     * 返回值要和被熔断的方法的返回值一致
     * 熔断方法不需要参数
     * @return
     */
    public CommonResult<Integer> queryUserByIdFallBack(){
        return new CommonResult<>(500,"请求繁忙，请稍后再试！");
    }
}

重新运行产生了和上面同样的效果。

（4）设置超时

在之前的案例中，请求在超过1秒后都会返回错误信息，这是因为Hystix的默认超时时长为1，我们可以通过配置修改这个值：
我们可以通过hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds来设置Hystrix超时时间。该配置没有提示。

hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 6000 # 设置hystrix的超时时间为6000ms

服务熔断

1、是什么

熔断机制的原理就像家里的电路熔断器，如果电路发生短路能力可熔断电路。在分布式系统中应用后，服务调用方可以自己进行判断某些服务反应慢或者存在大量超时的情况时，能够主动熔断，防止整个系统被拖垮。

Hystrix可以实现弹性容错，当情况好转之后，可以自动重连。通过熔断的方式可以将厚度请求直接拒绝掉，一段时间之后允许部分请求通过，如果调用成功则回到电路闭合状态，否则继续断开。

熔断状态机3个状态：

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

2、实践

我们在消费者模块item-consumer的controller中加入逻辑：

 @GetMapping("/test")
//    @HystrixCommand(fallbackMethod = "queryUserByIdFallBack") //用来声明一个降级逻辑的方法
    @HystrixCommand //标记该方法需要熔断
    public CommonResult<Integer> test(@PathVariable("id")Long id){
        if (id == 1) {
            throw new RuntimeException("太忙了");
        }
        return restTemplate.getForObject(ITEMSERVER_URL+"/test",CommonResult.class);
    }

这样只要参数为1就一定失败，准备两个请求接口：
http://localhost:9002/test/1
http://localhost:9002/test/2
当我们疯狂访问id为1的请求时（超过20次），就会触发熔断。断路器会断开，一切请求都会被降级处理。
此时你访问id为2的请求，会发现返回的也是失败，而且失败时间很短，只有几毫秒左右：

默认的熔断触发要求较高，休眠时间窗较短，为了测试方便，我们可以通过配置修改熔断策略：

circuitBreaker.requestVolumeThreshold=10
circuitBreaker.sleepWindowInMilliseconds=10000
circuitBreaker.errorThresholdPercentage=50

• requestVolumeThreshold：触发熔断的最小请求次数，默认20
• errorThresholdPercentage：触发熔断的失败请求最小占比，默认50%
• sleepWindowInMilliseconds：休眠时长，默认是5000毫秒