文章目录

零、前言

0. 之前写过两篇Spring Cloud，但是感觉不够具体，所以重新写了一份。

新 Spring Cloud (一) 之 Eureka 服务注册中心
 新 SpringCloud (二) 之 Ribbon 负载均衡
 新 Spring Cloud (三) 之 Hystrix熔断保护
 新 Spring Cloud (四) 之 Fegin远程调用
 新 Spring Cloud (五) 之 Zuul 网关

一、简介

Hystrix,英文意思是豪猪，是一种保护机制。Hystrix也是Netflix公司的一款组件。Hystix是Netflix开源的一个延迟和容错库，用于隔离访问远程服务、第三方库，防止出现级联失败。

1. Hystrix设计原则

防止单个服务的故障，耗尽整个系统服务的容器（比如tomcat）的线程资源，避免分布式环境里大量级联失败。通过第三方客户端访问（通常是通过网络）依赖服务出现失败、拒绝、超时或短路时执行回退逻辑
用快速失败代替排队(每个依赖服务维护一个小的线程池或信号量，当线程池满或信号量满，会立即拒绝服务而不会排队等待)和优雅的服务降级；当依赖服务失效后又恢复正常，快速恢复
提供接近实时的监控和警报，从而能够快速发现故障和修复。监控信息包括请求成功，失败（客户端抛出的异常），超时和线程拒绝。如果访问依赖服务的错误百分比超过阈值,断路器会跳闸，此时服务会在一段时间内停止对特定服务的所有请求
将所有请求外部系统（或请求依赖服务）封装到HystrixCommand或HystrixObservableCommand对象中，然后这些请求在一个独立的线程中执行。使用隔离技术来限制任何一个依赖的失败对系统的影响。每个依赖服务维护一个小的线程池（或信号量），当线程池满或信号量满，会立即拒绝服务而不会排队等待

2. 雪崩问题

1. 介绍
在微服务架构中，服务之间的调用错综复杂，一个请求可能需要多个微服务接口才能实现，形成非常复杂的调用链路。

如图，一次业务请求，需要调用A、P、H、I四个服务，这四个服务又可能调用其它服务。

如果此时，某个服务出现异常：

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

服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，最后导致整个系统崩溃不可用，形成雪崩效应。
比如：

2. 解决方案

线程隔离、服务降级
服务熔断

3. 线程隔离、服务降级

为了解决雪崩问题，Hystrix 提供了线程隔离（服务隔离）的做法。即为每一个服务分配一个线程池，比如上面的I服务，线程池里有5个线程，如果一个请求过来，阻塞在这，则占用一个线程，有新请求过来时还可以从线程池中再获取一个线程来访问I服务，即不会影响后续请求的访问。不过如果分配给I服务的线程已满，即线程池中的5条线程都被占用，后续请求过来时则不会再访问I服务，而是直接拒绝访问，引发服务降级。另外，如果当前正在访问的请求超时，也会进行引发服务降级。

综上：
Hystrix为每个依赖服务调用分配一个小的线程池，如果线程池已满调用将被立即拒绝，默认不采用排队.加速失败判定时间。用户的请求将不再直接访问服务，而是通过线程池中的空闲线程来访问服务，如果线程池已满，或者请求超时，则会进行降级处理，什么是服务降级？
服务降级：优先保证核心服务，而非核心服务不可用或弱可用。
用户的请求故障时，不会被阻塞，更不会无休止的等待或者看到系统崩溃，至少可以看到一个执行结果（例如返回友好的提示信息）。服务降级虽然会导致请求失败，但是不会导致阻塞，而且最多会影响这个依赖服务对应的线程池中的资源，对其它服务没有响应。

触发Hystix服务降级的情况：

线程池已满
请求超时

4. 服务熔断

熔断机制的原理很简单，像家里的电路熔断器，如果电路发生短路能立刻熔断电路，避免发生灾难。在分布式系统中应用这一模式之后，服务调用方可以自己进行判断某些服务反应慢或者存在大量超时的情况时，能够主动熔断，防止整个系统被拖垮。不同于电路熔断只能断不能自动重连，Hystrix 可以实现弹性容错，当情况好转之后，可以自动重连。这通过断路的方式，可以将后续请求直接拒绝掉，一段时间之后允许部分请求通过，如果调用成功则回到电路闭合状态，否则继续断开。
当Hystrix Command请求后端服务失败数量超过一定比例(默认50%), 断路器会切换到开路状态(Open). 这时所有请求会直接失败而不会发送到后端服务. 断路器保持在开路状态一段时间后(默认5秒), 自动切换到半开路状态(HALF-OPEN).这时会判断下一次请求的返回情况, 如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN). Hystrix的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力.

熔断状态机3个状态：

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

二、项目实践

以下所有操作都在服务消费者（EurekaServerConsumer）中操作

1. 引入依赖

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

2.启动类上添加注解 @EnableCircuitBreaker 或者将三个注解合并使用 @SpringCloudApplication 注解

@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker   // 开启熔断器
public class EurekaServerConsumerApplication {
    public static void main(String[] args) {
        SpringApplication.run(EurekaServerConsumerApplication.class, args);
    }
    
    @Bean
    @LoadBalanced
    public RestTemplate restTemplate(){
        return new RestTemplate();
    }
}

1. 线程隔离、服务降级

1. 针对单一方法的熔断

编写服务降级逻辑，即编写一个熔断方法 callTaxiFallback，规则是要和被熔断的方法有同样的参数列表和返回参数。
在需要熔断的方法上加上注解 @HystrixCommand(fallbackMethod = "fallbackMethod") 其中 fallbackMethod 指定了对应的熔断方法。

@RequestMapping("passenger")
@RestController
public class PassengerController {
    @Autowired
    private RestTemplate restTemplate;
    
    @RequestMapping("callTaxi")
    @HystrixCommand(fallbackMethod = "callTaxiFallback")    // 指定熔断方法
    public String callTaxi(String msg) {
        String url = "http://eureka-server-provider/driver/takeOrder";  // 通过 Eureka 服务注册中心的服务名称来调用
        // post方式嗲用传递参数
        MultiValueMap<String,String> multiValueMap =  new LinkedMultiValueMap<String,String>();
        multiValueMap.add("msg", msg);
        // 访问服务
        String result = restTemplate.postForObject(url, multiValueMap, String.class);
        System.out.println("乘客收到信息: " + result);
        return result;
    }

    // callTaxi 的熔断方法 - 参数列表和返回值要和代理的方法一致
    public String callTaxiFallback(String msg){
        return "服务请求失败，请稍后重试";
    }
}

其中
callTaxiFallback 是 callTaxi 的熔断方法。callTaxi通过 @HystrixCommand(fallbackMethod = "callTaxiFallback") 来指定其对应的熔断方法。

关掉所有服务提供者（EurekaServerProvider）的服务，这样可以模拟出服务超时的情况，随后我们访问http://localhost:10010/passenger/callTaxi。访问结果如下，可以看到，熔断方法生效。

2. 针对类的熔断

上面的一种情况已经实现了对方法的熔断，但是可以预见，实际服务中，会存在很多的接口，我们不可能为每个方法都写一个熔断方法。这时候我们就可以将其配置在类的层面上。

编写服务降级逻辑, 即编写一个熔断方法 callTaxiFallback 。规则是返回值一定要与被熔断方法一致
在需要熔断的类上加上注解 @DefaultProperties(defaultFallback = "passengerFallback") ， defaultFallback 指定熔断方法。
需要熔断的方法上加上注解 @HystrixCommand，不在需要指定熔断方法，当然如果需要也可以指定，与类上的注解不冲突。注意：如果方法需要熔断， @HystrixCommand注解不可省略。可以通过 @HystrixCommand来指定方法是否需要降级。加上需要降级，不加则不降级。

如下： callTaxi方法使用@HystrixCommand注解标注需要熔断方法，并且没有指定熔断方法，则使用默认的类指定的熔断方法 passengerFallback()
callTaxiNoFallBack 方法没有使用@HystrixCommand注解标注，则表示该方法不需要熔断
callTaxiWithFallBack 方法指定了自己的熔断方法 callTaxiFallBack

@RequestMapping("passenger")
@RestController
@DefaultProperties(defaultFallback = "passengerFallback")     // 在类上指明统一的失败降级方法
public class PassengerController {
    @Autowired
    private RestTemplate restTemplate;

    /**
     * 使用默认熔断方法
     * @param msg
     * @return
     */
    @RequestMapping("callTaxi")
    @HystrixCommand  // 标记该方法需要熔断
    public String callTaxi(String msg) {
        String url = "http://eureka-server-provider/driver/takeOrder";  // 通过 Eureka 服务注册中心的服务名称来调用
        // post方式嗲用传递参数
        MultiValueMap<String,String> multiValueMap =  new LinkedMultiValueMap<String,String>();
        multiValueMap.add("msg", msg);
        // 访问服务
        String result = restTemplate.postForObject(url, multiValueMap, String.class);
        System.out.println("乘客收到信息: " + result);
        return result;
    }

    /**
     *  没有熔断方法
     * @param msg
     * @return
     */
    @RequestMapping("callTaxiNoFallBack")
    public String callTaxiNoFallBack(String msg) {
        String url = "http://eureka-server-provider/driver/takeOrder";  // 通过 Eureka 服务注册中心的服务名称来调用
        // post方式嗲用传递参数
        MultiValueMap<String,String> multiValueMap =  new LinkedMultiValueMap<String,String>();
        multiValueMap.add("msg", msg);
        // 访问服务
        String result = restTemplate.postForObject(url, multiValueMap, String.class);
        System.out.println("乘客收到信息: " + result);
        return result;
    }

    /**
     * 自定义熔断方法
     * @param msg
     * @return
     */
    @RequestMapping("callTaxiWithFallBack")
    @HystrixCommand(fallbackMethod = "callTaxiFallBack")
    public String callTaxiWithFallBack(String msg) {
        String url = "http://eureka-server-provider/driver/takeOrder";  // 通过 Eureka 服务注册中心的服务名称来调用
        // post方式嗲用传递参数
        MultiValueMap<String,String> multiValueMap =  new LinkedMultiValueMap<String,String>();
        multiValueMap.add("msg", msg);
        // 访问服务
        String result = restTemplate.postForObject(url, multiValueMap, String.class);
        System.out.println("乘客收到信息: " + result);
        return result;
    }

    public String callTaxiFallBack(String msg){
        return "callTaxiFallBack ： 服务请求失败，请稍后重试";
    }

    /**
     * 熔断方法
     * 返回值要和被熔断的方法的返回值一致
     * 熔断方法不需要参数
     * @return
     */
    public String passengerFallback(){
        return "passengerFallback ： 服务请求失败，请稍后重试";
    }
}

测试如下：
callTaxi方法

callTaxiNoFallBack 方法

callTaxiWithFallBack 方法

2. 服务熔断

改造之前的服务提供者服务（EurekaServerProvider），如下，不接待叫张三的人，目的是为了在伪造某种请求失败的状况来触发熔断。也就是说，这里如果请求参数是张三，则请求失败，如果是其它，则请求成功。
为了让效果更明显，我们需要配置一些参数
下面的配置是，当有四次请求时，则将熔断机制打开。Hystix会对请求情况计数，当一定时间内失败请求百分比达到阈值，这里是百分之五十，则触发熔断，断路器会完全打开，随后进入休眠时间（这里配置成了10s）。随后断路器进入半开状态，此时会释放部分请求通过，若这些请求都是健康的，则会完全关闭断路器，否则继续保持打开，再次进行休眠计时
```
hystrix:
  command:
    default:
      circuitBreaker:
        requestVolumeThreshold: 4   # 触发熔断的最小请求次数，默认20
        errorThresholdPercentage: 50  # ：触发熔断的失败请求最小占比，默认50%
        sleepWindowInMilliseconds: 10000  # 休眠时长，默认是5000毫秒
```
按照我们第一步的修改，如果服务参数是张三时，则会拒绝请求并抛出异常，如果不是张三则通过。我们可以模拟
我们使用张三三调用两次服务没有问题：

随后我们使用张三调用两次服务，服务调用失败，这时候达到4次的阈值，并且失败次数两次，也达到大了50% 的比例，此时熔断器打开：

随后我们使用张三三再次调用服务，发现张三三也会失败，验证熔断器已经打开：

等一段时间后，这里是10s，再次访问张三三便可以访问，因为10s后熔断器已闭合

补：一些配置参数

hystrix:
  command:
    default:
      circuitBreaker:
        requestVolumeThreshold: 4   # 触发熔断的最小请求次数，默认20
        errorThresholdPercentage: 50  # ：触发熔断的失败请求最小占比，默认50%
        sleepWindowInMilliseconds: 10000  # 休眠时长，默认是5000毫秒
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 6000  # 设置hystrix的超时时间为6000ms， Hystix的默认超时时长为1000ms 超过1000ms的请求会返回错误方法

以上：内容部分参考
https://www.cnblogs.com/huangjuncong/p/9026949.html
如有侵扰，联系删除。内容仅用于自我记录学习使用。如有错误，欢迎指正

新 Spring Cloud (三) 之 Hystrix熔断保护

文章目录

零、前言

0. 之前写过两篇Spring Cloud，但是感觉不够具体，所以重新写了一份。

一、简介

1. Hystrix设计原则

2. 雪崩问题

3. 线程隔离、服务降级

4. 服务熔断

二、项目实践

1. 线程隔离、服务降级

1. 针对单一方法的熔断

2. 针对类的熔断

2. 服务熔断

vue项目获取富文本编辑器wangEditor内容导出为word（html转word格式并下载）

dotnet C# 创建 X11 应用时设置窗口背景颜色

Navicat安装与激活教程

TDengine docker安装方法

vue3组件通信与props

sapui5

Alpine Linux apk add DNS lookup error

部分JDK版本的发布时间

工作中用到的脚本合集

合并代码时Beyond Compare设置

Spring源碼分析十二：@AspectJ方式的AOP 之 getAdvicesAndAdvisorsForBean

Spring源碼分析十一：@AspectJ方式的AOP

Spring 源碼分析總結篇一: Spring IOC篇

Spring源碼分析：全集整理

Spring 源碼分析衍生篇一：FactoryBean介紹

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結

新 Spring Cloud (三) 之 Hystrix熔断保护

文章目录

零、 前言

0. 之前写过两篇Spring Cloud，但是感觉不够具体，所以重新写了一份。

一、简介

1. Hystrix设计原则

2. 雪崩问题

3. 线程隔离、服务降级

4. 服务熔断

二、项目实践

1. 线程隔离、服务降级

1. 针对单一方法的熔断

2. 针对类的熔断

2. 服务熔断

零、前言