Hystrix组件

Spring Cloud Hystrix

• ​​1、Hystrix简介​​
• ​​2、Hystrix基本功能​​

• ​​2.1 隔离​​
• ​​2.2 限流​​
• ​​2.3 熔断​​
• ​​2.4 降级​​

• ​​3、Hystrix断路器​​

• ​​3.1 Hystrix断路器打开关闭的条件：​​
• ​​3.2断路器流程​​

• ​​4、服务熔断实现​​

• ​​4.1 在项目中引入hystrix依赖​​
• ​​4.2 开启断路器​​
• ​​4.3 使用HystrixCommand注解实现断路​​
• ​​4.4 访问测试​​

• ​​5、服务降级的实现​​
• ​​5.1 客户端openfeign+hystrix实现服务降级思路​​

• ​​5.2 开启openfeign支持服务降级​​
• ​​5.3 在openfeign客户端中加入Hystrix​​
• ​​5.4 开发fallback处理类​​
• ​​5.5 服务降级测试​​

1、Hystrix简介

  Netflix Hystrix是SOA/微服务架构中提供服务隔离、熔断、降级机制的工具/框架。Netflix Hystrix是断路器的一种实现，用于高微服务架构的可用性，是防止服务出现雪崩的利器。
  在分布式架构中，一个应用依赖多个服务是非常常见的。如果其中一个依赖由于延迟过高发生阻塞，调用该服务的线程就会阻塞。如果相关业务的QPS较高，就可能产生大量阻塞，从而导致该应用/服务由于服务器资源被耗尽而拖垮。
关于服务雪崩、降级、熔断的概念请看这里：​​javascript:void(0)​​

2、Hystrix基本功能

  Hystrix具有隔离(线程池隔离、信号量隔离)服务降级、熔断、限流、缓存等功能，基本上能覆盖到微服务中调用依赖服务会遇到的问题。

2.1 隔离

• 线程池隔离：每个服务对应一个线程池，线程池满了就会进行降级。使用线程池存储当前的请求，线程池对请求做处理，设置任务返回处理超时时间，堆积的请求进入线程池队列。这种方式需要为每个依赖的服务申请线程池，有一定的资源消耗，好处是可以应对突发流量(流量洪峰来临时，处理不完可将数据存储到线程池队列慢慢处理)。
• 信号量隔离：基于Tomcat线程池来控制，当线程达到某个百分比时将拒绝访问走降级流程。信号量的资源隔离只是起到一个开关的作用，比如服务A的信号量大小为10，就是说它同时只允许有10个Tomcat线程来访问服务A，其他请求都会被拒绝，从而达到资源隔离和限流保护的作用。

2.2 限流

限流就是信号量隔离(一般不会使用该模式)

2.3 熔断

出发快速失败，保证系统可用性。

2.4 降级

使用回调方法返回托底数据。
Hystrix被设计的目标是：对通过第三方客户端访问的依赖项(通常通过网络)的延迟和故障进行保护和控制；在复杂的分布式系统中阻止级联故障；快速失败，快速回复；回退，尽可能优雅地降级；启用类似实时监控、警报和操作的控制。

3、Hystrix断路器

3.1 Hystrix断路器打开关闭的条件：

• 1、当满足一定的阈值的时候(默认10秒内超过20个请求次数)
• 2、当失败率达到一定的时候(默认10秒内超过50%的请求失败)
• 3、达到以上阈值时断路器将会开启
• 4、当断路器开启的时候，所有请求都不会进行转发。
• 5、一段时间之后(默认是5秒)，这个时候断路器是半开状态，会让其中一个请求进行转发。如果成功，断路器将会关闭，若失败，继续开启。重复步骤4和5。

3.2断路器流程

4、服务熔断实现

4.1 在项目中引入hystrix依赖

这里将consul和web依赖都引入

<!--引入hystrix-->
<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>
 <!--web-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <!--consul client-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-consul-discovery</artifactId>
        </dependency>
        <!-- actuator-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>

4.2 开启断路器

application.properties:

4.3 使用HystrixCommand注解实现断路

@GetMapping("demo")
    @HystrixCommand(fallbackMethod = "demoFallBack")  //自定义熔断处理
    public String demo(Integer id){
        System.out.println("demo OK!!!");
        if(id<=0){
            throw new RuntimeException("无效id");
        }
        return "demo OK!!!";
    }
    //自己备选处理
    public String demoFallBack(Integer id){
        return "当前活动过于火爆，服务已经被熔断了！！！";
    }

  上述的fallbackMethod参数用来指定熔断时快速返回的处理方法，而当Id<0时抛出异常是为了模拟非法参数时服务熔断。

  这里也可用默认的处理方法：

4.4 访问测试

  先启动consul，在cmd中​​consul agent -dev​​​ 随后启动项目，访问​​localhost:8500​​查看服务是否注册成功

正常的参数访问

错误参数访问：

5、服务降级的实现

5.1 客户端openfeign+hystrix实现服务降级思路

引入hystrix依赖
配置文件开启feign支持hystrix
在feign客户端调用加入fallBack指定降级处理
开发降级处理方法

项目结构：

5.2 开启openfeign支持服务降级

在客户端配置文件中加入：​​feign.hystrix.enabled=true #开启openfeign支持降级​​

5.3 在openfeign客户端中加入Hystrix

5.4 开发fallback处理类

5.5 服务降级测试

启动服务：

服务注册中心查看：

客户端用于测试的controller:

访问：​​localhost:8991/test​​

上图可看出，这时出发了Hystrix的fallback

现在我们直接将HystrixApplication这个服务停掉再次访问​​localhost:8991/test​​

访问前：

访问后：

即当调用服务不可用时，直接回执自定义默认处理。