跟乐乐学微服务!(三)SpringCloud组件熔断器 Hystrix

最新推荐文章于 2022-09-06 15:14:19 发布

君を見つけて

最新推荐文章于 2022-09-06 15:14:19 发布

阅读量221

点赞数

分类专栏： Cloud微服务文章标签： Hystrix 微服务线程隔离熔断器

本文链接：https://blog.csdn.net/chinatopno1/article/details/118913985

版权

Cloud微服务专栏收录该内容

11 篇文章 0 订阅

订阅专栏

上一篇文章：跟乐乐学微服务!(二) SpringCloud组件负载均衡Ribbon的应用
上一篇文章：跟乐乐学微服务!(四) Spring Cloud组件 Feign

ps:审核员你懂技术吗？我这里只是以一个贷款系统举例子，介绍SpringCloud这个组件如何让服务器系统更加稳定的运行，怎么就不给通过审核了？不行我就直接投诉你们了。
知道不？做开发的程序员最怕的就是不懂技术的人在那里瞎扯，你要是觉得这个违章，先把你们CSDN的程序员叫过来看看是不是有违规内容，这就跟我去应聘程序员，人事一个不懂技术的问我java功底如何一样。

Hystrix能用来做什么？

Hystrix是一个熔断器，主要用于解决微服务中的雪崩问题，从而保证各个微服务的正常运行。

什么是雪崩问题？

假设我有一个即时小额贷款系统，
用户这时要完成一次即时小额贷款，那么需要通过调用服务，完成提交即时贷款申请、获取征信信息、记录贷款信息到后台、获取贷款额度这四个步骤。
而我们的系统架构是微服务架构，现在存在三个服务。
一个是服务消费者：接受用户的贷款请求，去消费服务提供者，
另一个是服务提供者A：提交即时贷款申请和获取征信信息，
再一个是服务提供者B：记录贷款信息到后台和获取贷款额度。
那么一次顺利的流程，大概如下图：
在这里插入图片描述

那么，此时，用于负责‘记录贷款信息到后台’和‘获取贷款额度‘的两个服务实例、提供者B都突然宕机或异常了的情况下，
随着消费方发往服务提供方B的请求都得不到回应，用户到消费方内的请求又越来越多，消费方最终不堪重负，就会出现雪崩。
在这里插入图片描述

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

对于雪崩问题，Hystrix提供通过服务降级来解决。

什么是服务降级？

前面提到了，对于雪崩问题，Hystrix通过服务降级来解决它。
服务降级就是，用户的请求在失败或者被服务器拒绝了的情况下，被转移到了一个指定的方法中进行后续处理，该方法最后大多会响应给用户一个提示信息，告诉用户当前暂不能访问。
服务降级的手段分别为线程隔离和服务熔断

服务降级手段之线程隔离

线程隔离概念

在这里插入图片描述

Hystrix会为每个服务调用分配一个线程池（默认为10），每个用户的每个请求需要先从线程池拿到线程，然后才能访问服务提供者。
如果线程池满了，该条请求无法拿到线程，消费者将会对该请求进行服务降级处理。
亦或是，尽管拿到了线程，但是访问服务消费方失败或超时（默认为1秒）了，消费者也将对用户的该条请求进行服务降级处理。
而服务降级处理，通俗来说就是对用户的请求失败这件事做一个善后处理，一般都是响应一条提示用户访问失败的信息给用户。

线程隔离实现

一.配置

在消费模块中引入Hystrix依赖

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>com.databasequeryproject</groupId>
        <artifactId>databasequery</artifactId>
        <version>0.0.1-SNAPSHOT</version>
    </parent>

    <artifactId>database-query-consumer</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>database-query-consumer</name>
    <description>Demo project for Spring Boot</description>

    <properties>
        <java.version>1.8</java.version>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
        <spring-boot.version>2.3.7.RELEASE</spring-boot.version>
    </properties>

    <dependencies>

        <!-- eureka客户端 -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
            <version>2.2.7.RELEASE</version>
        </dependency>

        <!-- Hystrix熔断器 -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
        </dependency>
    </dependencies>



</project>

在消费者模块的启动类中添加注解“@EnableCircuitBreaker”，用以开启Hystrix熔断。

二.编写降级业务逻辑

一个消费者的Controller中，每个方法都是用于访问服务提供方的。
但当这些方法线程池已满，或访问服务提供者失败时，将会自动运行一个称之为“降级业务”的方法，接下来我们去编写它。

OR.为不同的方法指定不同的降级业务

顾名思义，我们可以为每个方法指定各自对应的降级业务方法。

这需要我们使用@HystrixCommand注解，在需要被绑定降级业务的方法上声明。fallbackMethod属性用于指定该方法对应的降级业务方法名。

package com.databasequery.databasequeryconsumer.controller;

import com.databasequery.databasequeryconsumer.pojo.QueryResult;
import com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.cloud.client.ServiceInstance;
import org.springframework.cloud.client.discovery.DiscoveryClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.client.RestTemplate;

import java.util.List;

@RestController
@RequestMapping(value = "query")
public class QueryController {

    // restTemplate用于访问服务提供方暴露的接口。
    @Autowired
    private RestTemplate restTemplate;

    @HystrixCommand(fallbackMethod = "fallbackMethodOfqqQuery")
    @GetMapping("qq/{qqNumber}")
    public Object qqQuery(@PathVariable("qqNumber") String qqNumber){
        String url = "http://database-provider-service/query/qq/"+qqNumber;
        Object qr =   restTemplate.getForObject(url, Object.class);
       return qr;
    }

    public  Object fallbackMethodOfqqQuery(String qqNumber){

        String responseErrorStr = "不好意思，服务正忙，请您稍后再试！";
        return responseErrorStr;
    }
}

同时，被绑定了降级业务的方法，和降级业务方法，它们两个方法的参数列表和返回值类型要一致才能生效！
进行尝试，
当我们启动服务提供者模块’ProviderdatabasequeryApplication’后，访问消费者后，得到的响应内容是正常的。
但当我们停止运行‘ProviderdatabasequeryApplication’模块后，则响应内容边成了提示信息

OR.为所有方法指定同一个降级业务

有时候，我们没有必要为所有的方法都指定出各自的降级业务。那么
我们可以把一个类下的所有方法，都绑定给同一个降级业务方法去处理。
它只要求两者的返回值相同即可。

同样的，在需要被绑定降级业务的方法上添加@HystrixCommand注解，但不声明任何属性。
其次是在类上添加添加@DefaultProperties注解，使用defaultFallback属性指定一个用于处理降级业务的方法名。
降级业务方法只需返回值类型和被绑定方法相同.

package com.databasequery.databasequeryconsumer.controller;

import com.databasequery.databasequeryconsumer.pojo.QueryResult;
import com.netflix.hystrix.contrib.javanica.annotation.DefaultProperties;
import com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.cloud.client.ServiceInstance;
import org.springframework.cloud.client.discovery.DiscoveryClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.client.RestTemplate;

import java.io.BufferedReader;
import java.io.FileInputStream;
import java.io.InputStreamReader;
import java.util.List;

@RestController
@RequestMapping(value = "query")
@DefaultProperties(defaultFallback = "defaultFallbach") //指定当前类的全局服务降级方法
public class QueryController {

    // restTemplate用于访问服务提供方暴露的接口。
    @Autowired
    private RestTemplate restTemplate;

    //@HystrixCommand(fallbackMethod = "fallbackMethodOfqqQuery")
    @HystrixCommand
    @GetMapping("qq/{qqNumber}")
    public Object qqQuery(@PathVariable("qqNumber") String qqNumber){
        String url = "http://database-provider-service/query/qq/"+qqNumber;
        Object qr =   restTemplate.getForObject(url, Object.class);
       return qr;
    }

    public Object fallbackMethodOfqqQuery(String qqNumber){
        String responseErrorStr = "不好意思，服务正忙，请您稍后再试！";
        return responseErrorStr;
    }

    public Object defaultFallbach(){
        String responseErrorStr = "不好意思，服务正忙，请您稍后再试！--- 来自全局默认的降级方法";
        return responseErrorStr;
    }
}

在这里插入图片描述

在下图中我们可以看到，当启动服务提供方模块时是正常访问的。但是当关闭了服务提供方模块、出现请求失败后，因为当前类声明了使用全局默认降级业务处理，所以响应内容为defaultFallbach方法给出的“不好意思，服务正忙，请您稍后再试！—
来自全局默认的降级方法”。

在这里插入图片描述

三.指定线程池和超时时间

Hystrix的依赖线程池大小默认为10，我们可以在application中为其设置指定的大小。

hystrix.threadpool.default.coreSize = 20  # 指定线程池的最大线程数，默认10

当前用户的请求从线程池拿到线程后，接着当前的服务消费方会请求服务提供方，如果超时，则进行服务降级。
Hystrix默认为1秒，考虑到网络延时的因素，1秒多数情况下是不够的，因此我们需要设置指定的超时时间。

  command.default.execution.isolation.thread.timeoutInMilliseconds = 10000 # 设置超时时间。单位毫秒 10000 = 10秒。

最终的yaml格式如下:

hystrix:
  threadpool:
    default:
      coreSize: 20 #指定线程池的最大线程数，默认10
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 30000 # 设置超时时间。单位毫秒 10000 = 10秒。

注意：ribbon同样具有超时设置，如果Ribbon的超时为5秒，Hystrix超时为10秒。那么超过5秒时，ribbon会先hystrix一步触发超时机制，而超时机制又引起了服务降级。
也就是说，这个服务降级并非hystrix超时引起的，此时hystrix的超时作用等同于无效。

参考：https://www.cnblogs.com/wugang/p/14497236.html

服务降级手段之服务熔断

服务熔断概念

前面提到过，在线程隔离中，触发服务降级的条件有两个，一是当线程池中没有多余线程，二是请求服务提供方超时/失败。
但是，线程隔离还不足以保证服务的稳定性。
就比如有A和B两个服务提供者，此时服务提供者B出现了宕机，那么消费方只有在请求提供方超时的情况下才会触发服务降级，那么就会出现 请求—> 超时—>触发降级 这种情况，这样一来就很浪费性能，也容易造成业务上的不稳定。
那么，如何让消费方不需要重复性地访问宕机了的服务提供方，就能直接对用户发来的这类请求进行降级处理呢？这个时候，就需要服务熔断来解决这个问题了。
在这里插入图片描述

熔断器存在三个状态：

熔断器关闭状态：允许所有请求通过。若请求超时/失败的次数和比例超过阈值，将会进入开启状态。
熔断器开启状态：开启状态将持续一定时间（默认五秒），这期间熔断器会使服务休眠，所有请求会被降级处理。时间过后，自动成为半开状态。
熔断器半开状态：此时会释放一部分请求访问。若后续请求是健康的，则熔断器成为关闭状态；若后续请求依然超时/失败，熔断器重新进入开启状态。

服务熔断实现

一.配置熔断器(断路器)参数

熔断器的参数，诸如失败比例、失败次数、休眠时间等已经有了默认配置，但是这些默认的参数对熔断开启要求比较高，因此为了更好演示熔断的实现，我们先将其更改为更易触发熔断机制的参数。

如果请求失败比例超过了阈值，熔断器同样也将会成为开启状态，默认的失败比例为50%。

hystrix.command.default.circuitBreaker.errorThresholdPercentage=50 # 失败比例的阈值，默认50%

如果用户的请求在消费方失败，或者是用户通过消费方请求提供方失败，并达到了一定次数，熔断器将会由关闭状态成为开启状态。默认失败次数的阈值为20次。

hystrix.command.default.circuitBreaker.requestVolumeThreshold=5 # 开启熔断状态的最小请求失败次数，默认20

当熔断器成为开启状态后，开启状态并非永久的，默认持续5秒。这期间，会将消费者自身的服务进行休眠，因此用户的所有请求会被降级处理。

hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds=10000 # 熔断开启后，服务的休眠时间。默认5秒

服务熔断的配置结合线程隔离的配置，最终转为yam格式后如下：

hystrix:
  threadpool: # 配置线程隔离池
    default:
      coreSize: 20 #指定线程池的最大线程数，默认10
  command:
    default:
      circuitBreaker: # 配置断路器
        errorThresholdPercentage: 50 # 开启熔断状态阈值比例，默认50%
        sleepWindowInMilliseconds: 10000 # 熔断状态后的服务休眠时间，默认5秒。10000ms = 10秒
        requestVolumeThreshold: 5 # 开启熔断状态的最小请求失败次数，默认20次。此处为10次。
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 10000 # 设置超时时间。

二.模拟熔断

先展示一下消费者controller层的代码。

@RestController
@RequestMapping(value = "query")
@DefaultProperties(defaultFallback = "defaultFallbach") //指定当前类的全局服务降级方法
public class QueryController {

    // restTemplate用于访问服务提供方暴露的接口。
    @Autowired
    private RestTemplate restTemplate;
    private int num = 0;
    
    @HystrixCommand
    @GetMapping("qq/{qqNumber}")
    public Object qqQuery(@PathVariable("qqNumber") String qqNumber){
    	num++;
        System.out.println("第"+num+"次请求");
        //访问服务提供方：http://127.0.0.1:8081/query/qq/{qqnum}
        String url = "http://database-provider-service/query/qq/"+qqNumber;
        Object qr =   restTemplate.getForObject(url, Object.class);
       return qr;
    }
    
    public Object fallbackMethodOfqqQuery(String qqNumber){
        String responseErrorStr = "不好意思，服务正忙，请您稍后再试！";
        return responseErrorStr;
    }

    public Object defaultFallbach(){
        String responseErrorStr = "不好意思，服务正忙，请您稍后再试！--- 来自全局默认的降级方法";
        return responseErrorStr;
    }
}

这里，我通过增加访问提供方的失败次数，来达到熔断阈值，进而触发熔断；因此，我要在服务提供方的controller这里更改一下逻辑：如果传入的参数为‘0000’，那么将触发异常。

@RestController
@RequestMapping(value = "query")
public class QueryController {

    @Autowired
    private QueryService queryService;

    @GetMapping("qq/{qqnum}")
    public QueryResult qqQueryMethod(@PathVariable("qqnum") String qqnum){
        if ("0000".equals(qqnum)){
            System.out.println("进入异常。。。");
           throw new RuntimeException("发生异常。。。。。");
        }
        QueryResult query = queryService.query(qqnum);
        return query;
    }
}

消费方暴露给用的请求接口为127.0.0.1:8082/query/qq/{qqNumber}。
我们准备两个浏览器窗口，要访问的地址分别为:
127.0.0.1:8082/query/qq/0000 必定进入异常
127.0.0.1:8082/query/qq/9999 必定成功
先访问参数为9999的，可以看到是能够访问的。
然后我们疯狂访问参数为0000的请求，这个请求必定会因失败而被降级处理，次数一直够5次，达到触发熔断阈值。

在这里插入图片描述

这个时候，因为熔断器已经被触发开启，在10秒内，我们即使访问参数为9999的请求，也被降级处理。

君を見つけて

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
跟乐乐学微服务!(三)SpringCloud组件熔断器 Hystrix

Hystrix能用来做什么？Hystrix是一个熔断器，主要用于解决微服务中的雪崩问题，从而保证各个微服务的正常运行。什么是雪崩问题？假设我有一个即时小额贷款系统，用户这时要完成一次即时小额贷款，那么需要通过调用服务，完成提交即时贷款申请、获取征信信息、记录贷款信息到后台、获取贷款额度这四个步骤。而我们的系统架构是微服务架构，现在存在三个服务。一个是服务消费者：接受用户的贷款请求，去消费服务提供者，另一个是服务提供者A：提交即时贷款申请和获取征信信息，再一个是服务提供者B：记录贷
复制链接

扫一扫