四、Hystix熔断器

一、简介

Hystix，即熔断器（也叫断路器）。

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

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

二、熔断器的工作机制

正常工作的情况下，客户端请求调用服务API接口：

当有服务出现异常时，直接进行失败回滚，服务降级处理：

当服务繁忙时，如果服务出现异常，不是粗暴的直接报错，而是返回一个友好的提示，虽然拒绝了用户的访问，但是会返回一个结果。

这就好比去买鱼，平常超市买鱼会额外赠送杀鱼的服务。等到逢年过节，超时繁忙时，可能就不提供杀鱼服务了，这就是服务的降级。

系统特别繁忙时，一些次要服务暂时中断，优先保证主要服务的畅通，一切资源优先让给主要服务来使用，在双十一、618时，京东天猫都会采用这样的策略。

三、雪崩问题

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

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

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

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

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

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

线程隔离
服务熔断

四、线程隔离，服务降级

1. 原理

线程隔离示意图

服务降级（线程排满时触发，设置等待时长，若长时间未响应，返回友好错误信息）

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

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

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

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

触发Hystix服务降级的情况：

线程池已满
请求超时

五、动手实践（服务的降级是在消费方）

1. 引入依赖

首先在user-consumer中引入Hystix依赖：


    org.springframework.cloud
    spring-cloud-starter-netflix-hystrix

2. 开启熔断

一个标准的Eureka客户端都得配置以上三个注解，所以springboot提供了一个新的注解替代三个（里面还是引用了以上三个注解）

3.改造消费者

Hystix 默认超时时长1秒钟

为了实现超时，服务提供方可睡眠2秒

4.以上降级处理存在的问题

方法写在controller中，且每个方法都写降级处理方法，显然不可行
修改为统一处理逻辑

单个超时时长配置

重新取值覆盖即可

整体超时时长配置

六、服务熔断

1. 熔断原理

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

Hystix的熔断状态机模型

状态机有3个状态：

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

2. 动手实践

为了能够精确控制请求的成功或失败，我们在consumer的调用业务中加入一段逻辑并修改熔断时长，以便观察

开始测试

id为1无问题
id为2抛出异常，会触发降级熔断方法
多次快速点击id为2的请求，再访问请求为1的页面，发现服务被熔断了
等待5秒后，恢复正常