Hystrix 服务熔断，降级_fallbackmethod 打印熔断原因

1.服务熔断

服务熔断的作用类似于我们家用的保险丝，当某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用。

2.服务降级

服务降级是从整个系统的负荷情况出发和考虑的，对某些负荷会比较高的情况，为了预防某些功能（业务场景）出现负荷过载或者响应慢的情况，在其内部暂时舍弃对一些非核心的接口和数据的请求，而直接返回一个提前准备好的fallback（退路）错误处理信息。这样，虽然提供的是一个有损的服务，但却保证了整个系统的稳定性和可用性。

3.Hystrix简介

Hystrix：英 [hɪst’rɪks] 美 [hɪst’rɪks] ，翻译过来是“豪猪”的意思。 在分布式环境中，不可避免地会出现某些依赖的服务发生故障的情况。Hystrix是这样的一个库，它通过添加容许时延和容错逻辑来帮助你控制这些分布式服务之间的交互。Hystrix通过隔离服务之间的访问点，阻止跨服务的级联故障，并提供了退路选项，所有这些都可以提高系统的整体弹性

3.1Hystrix的设计目的：

我们知道大量请求会阻塞在Tomcat服务器上,影响其它整个服务.在复杂的分布式架构的应用程序有很多的依赖,都会不可避免地在某些时候失败.高并发的依赖失败时如果没有隔离措施,当前应用服务就有被拖垮的风险.
Spring Cloud Netflix Hystrix就是隔离措施的一种实现,可以设置在某种超时或者失败情形下断开依赖调用或者返回指定逻辑,从而提高分布式系统的稳定性.

生活中举个例子，如电力过载保护器，当电流过大的的时候，出问题，过载器会自动断开，从而保护电器不受烧坏。因此Hystrix请求熔断的机制跟电力过载保护器的原理很类似。

比如：订单系统请求库存系统，结果一个请求过去，因为各种原因，网络超时，在规定几秒内没反应，或者服务本身就挂了，这时候更多的请求来了，不断的请求库存服务，不断的创建线程，因为没有返回，也就资源没有释放，

这也导致了系统资源被耗尽，你的服务奔溃了，这订单系统好好的，你访问了一个可能有问题的库存系统，结果导致你的订单系统也奔溃了，你再继续调用更多的依赖服务，可会会导致更多的系统奔溃，这时候Hystrix可以实现快速失败，

如果它在一段时间内侦测到许多类似的错误，会强迫其以后的多个调用快速失败，不再访问远程服务器，从而防止应用程序不断地尝试执行可能会失败的操作进而导致资源耗尽。这时候Hystrix进行FallBack操作来服务降级，

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

使得应用程序继续执行而不用等待修正错误，或者浪费CPU时间去等到长时间的超时产生。Hystrix熔断器也可以使应用程序能够诊断错误是否已经修正，如果已经修正，应用程序会再次尝试调用操作。

3.2Hystrix设计原则

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

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

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

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

3.3 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的请求，这样我们只需查询一次数据库，提升了效率。

3.4Hystrix流程说明:

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集成一次，再进行请求拦截来熔断。

4.使用Hystrix

4.1 引入Hystrix依赖

在 pom.xml 文件中引入Hystrix依赖：

<!-- Hystrix 依赖 -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>
1
2
3
4
5

4.2 修改启动类(熔断)

启动类上增加@EnableCircuitBreaker注解，开启熔断

@SpringBootApplication
@EnableDiscoveryClient
//开启熔断
@EnableCircuitBreaker
public class UserShopApplication {

    public static void main(String[] args) {

        SpringApplication.run(UserShopApplication.class);
    }
}

1
2
3
4
5
6
7
8
9
10
11
12

4.3修改Controller

接下来，我们为接口增加断路器功能，修改部分代码如下：

@RestController
@RequestMapping("/user")
public class UserController {

    @Autowired
    UserService userService;


    @RequestMapping("/login")
    public BaseResp login(@RequestBody TbUser tbUser){

        return userService.login(tbUser);
    }


    /**
     *  通过uuid,从Redis中，解析jwt令牌，并获取获取用户信息
     * @param uuid 前端传来的token 本质是uuid
     * @return
     * @throws InterruptedException
     * fallbackMethod: 当发生熔断进入的方法
     * 注意：熔断如果发生在远程调用中，那么一定发生在被调用方
     */
    @RequestMapping("/verifier")
    @HystrixCommand(commandProperties={
            //请求在接口中停留3秒中时间 还没有结束当前线程的话 把当前的线程进行熔断
            @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "3000")
    },fallbackMethod = "verifierFallback")
    public TbUser verifier(@RequestParam("token")String uuid) throws InterruptedException {
        //模拟发生异常,让程序进入休眠3.5秒
        Thread.sleep(3500);
        //int i = 1/0;
        return userService.verifier(uuid);
    }

    /**
     * 接口出现异常的时候进入fallback方法
     * @param uuid
     * @return
     * 这个方法功能可以自定义，看你给用户反馈什么信息
     */
    public TbUser verifierFallback(@RequestParam("token")String uuid){
        System.out.println("进入了熔断  fallback方法");
        return null;
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

4.4 调用测试（远程调用）

最后在控制台打印出：

我们发现调用成功后，打印了fallback的方法，也就是当前业务产生了错误，会自动调用fallbackMethod 方法来进行熔断。

注意：被调用方的方法有参数的话，必须在fallbackMethod的参数中一一对应起来

5.Feign结合Hystrix

5.1 在调用方导入jar包

<!--
            Feign 远程调用的依赖1.结合http的远程调用。2.结合了ribbon的负载均衡
        -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-openfeign</artifactId>
        </dependency>
<!-- Hystrix服务依赖 熔断、降级 -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
        </dependency>
1
2
3
4
5
6
7
8
9
10
11
12

5.2、启动类开启@EnableHystrix（开启降级）

@SpringBootApplication
@EnableDiscoveryClient
//标注当前工程开启feign远程调用
@EnableFeignClients
//开启降级
@EnableHystrix
public class ShopGoodsApplication {

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14

5.3 、配置yml文件

ribbon:
  ConnectTimeout: 5000 # 请求连接超时时间
  ReadTimeout: 5000 # 请求处理的超时时间
hystrix:
  command:
    default:  #default全局有效，service id指定应用有效
      execution:
        timeout:
          enabled: true
        isolation:
          thread:
            timeoutInMilliseconds: 20000
#feign结合hystrix使用
feign:
  hystrix:
    enabled: true
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

通过配置@FeignClient注解的fallback属性来位MessageServiceClient指定一个自定义的fallback处理类（UserClientFallback）。

//serviceId服务编号 唯一标识
@FeignClient(serviceId = "shop-user",fallback = UserClientFallback.class)
public interface  UserClient {
	//远程调用client(shop-user)服务中的接口
    @RequestMapping("/user/verifier")
    public TbUser verifier(@RequestParam("token")String uuid);
}

1
2
3
4
5
6
7
8

5.5 创建Fallback处理类

MessageServiceFallback需要实现ClientInterface接口，并且在Spring容器中必须存在一个该类型的有效Bean。在这里，我们使用@Component注解将其注入到Spring容器中。

@Component
public class UserClientFallback implements UserClient{

    @Override
    public TbUser verifier(String uuid) {
        System.out.println("进入了降级方法");
        return null;
    }
}

1
2
3
4
5
6
7
8
9
10

当远程调用服务不可用时，执行测试方法，返回结果如下：

调用接口失败，对其进行降级处理