大白话详解 Spring Cloud 服务降级与熔断

关注

发布于: 2021 年 03 月 01 日

1. Hystrix 断路器概述

1.1 分布式系统面临的问题

复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候将不可避免地失败。这就造成有可能会发生 服务雪崩 。那么什么是服务雪崩呢？

多个微服务之间调用的时候，假设微服务 A 调用微服务 B 和微服务 C，微服务 B 和微服务 C 又调用其他的微服务，这就是所谓的“ 扇出 ”（像一把打开的折扇）。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务 A 的调用就会占用越来越多的系统资源，进而引起系统崩溃，这就是所谓的” 雪崩效应 “。也就是系统的 高可用 受到了破坏。

对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源在几秒内饱和。比失败更糟的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发送更过的级联故障。这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。

所以，通常当发现一个模块下的某个实例失败后，这时候这个模块依然还会接受流量，然后这个有问题的模块还调用了其他的模块，这样就会发生级联故障，或者叫做雪崩。而面对这种糟糕的问题，我们就应该采取 服务降级、服务熔断 等方式来解决。

1.2 Hystrix 是什么

Hystrix 是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免地会调用失败，比如超时、异常等，Hystrix 能够保证在一个依赖出问题的情况下，不会导致整个服务失败，避免级联故障，以提高分布式系统的弹性。

“断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似于物理的熔断保险丝），向调用方返回一个符合预期的、可处理的备选响应（FallBack），而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。

1.3 Hystrix 作用

主要有服务降级、服务熔断、接近实时的监控、限流、隔离等等，其官方文档参考。当然 Hystrix 现在已经停更了，虽然有一些替代品，但是学习 Hystrix 及其里面的思想还是非常重要的！

1.4 Hystrix 重要概念

服务降级（Fall Back）假设微服务 A 要调用的服务 B 不可用了，需要服务 B 提供一个兜底的解决方法，而不是让服务 A 在那里傻等，耗死。不让客户端等待并立刻返回一个友好提示，比如像客户端提示服务器忙，请稍后再试等。哪些情况会触发服务降级呢？比如程序运行异常、超时、服务熔断触发服务降级、线程池/信号量打满也会导致服务降级。

服务熔断（Break）服务熔断就相当于物理上的 熔断保险丝 。类比保险丝达到最大服务访问后，直接拒绝访问，拉闸断电，然后调用服务降级的方法并返回友好提示。

** 服务限流（Flow Limit） ** 秒杀高并发等操作，严禁一窝蜂地过来拥挤，大家排队，一秒钟 N 个，有序进行。

2. Hystrix 案例

2.1 服务提供者 8003 模块

建 Module

cloud-provider-hystrix-payment8003

pom.xml

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

复制代码

yml 配置文件 / 主启动类

server:  port: 8003
spring:  application:    name: cloud-provider-hystrix-payment
eureka:  client:    register-with-eureka: true    fetchRegistry: true    service-url:      # 单机版      defaultZone: http://localhost:7001/eureka # 入驻的服务注册中心地址

复制代码

@SpringBootApplication@EnableEurekaClientpublic class PaymentHystrixMain8003 {    public static void main(String[] args) {        SpringApplication.run(PaymentHystrixMain8003.class,args);    }}

复制代码

业务类

service

@Servicepublic class PaymentService {    /**能够正常访问的方法*/    public String paymentInfo_OK(Integer id) {        return "线程池: " + Thread.currentThread().getName()                + " paymentInfo_OK,id: " + id + "\t" + "哈~";    }
    /**模拟出错的方法*/    public String paymentInfo_FAIL(Integer id) {        int timeNumber = 3;        //暂停几秒钟线程，程序本身没有错误，就是模拟超时        try {            TimeUnit.SECONDS.sleep(timeNumber);        }catch (InterruptedException e) {            e.printStackTrace();        }        return "线程池: " + Thread.currentThread().getName()                + " paymentInfo_FAIL,id: " + id + "\t" + "哈~ "                + "耗时" + timeNumber + "s";    }}

复制代码

controller

@RestController@Slf4j@RequestMapping("/payment/hystrix")public class PaymentController {    @Resource    private PaymentService paymentService;
    @Value("$server.port")    private String serverPort;
    @GetMapping("ok/{id}")    public String paymentInfo_OK(@PathVariable("id")Integer id) {        String result = paymentService.paymentInfo_OK(id);        log.info("===> result: " + result);        return result;    }
    @GetMapping("timeout/{id}")    public String paymentInfo_TimeOut(@PathVariable("id")Integer id) {        String result = paymentService.paymentInfo_FAIL(id);        log.info("===> result: " + result);        return result;    }}

复制代码

也就是说 cloud-provider-hystrix-payment 服务提供了两个方法， paymentInfo_OK 方法可以很快访问， paymentInfo_TimeOut 方法我们模拟了一个复杂的业物逻辑，通过线程休眠的方式使其模拟一个需要执行 3 秒的服务方法。

在启动了注册中心和 8003 服务后，我们对服务的 paymentInfo_OK （下面用 OK 代替）和 paymentInfo_TimeOut （下面用 TO 代替）分别进行访问，我们发现 http://localhost:8003/payment/hystrix/ok/1 可以很快的访问，而 http://localhost:8003/payment/hystrix/timeout/1 每次访问大约需要 3 秒的时间。

上述为根基平台，开始演示：正确 => 错误 => 降级熔断 => 正确

2.2 8003 高并发测试

服务提供方自测压力测试：

需要 3 秒的复杂业务逻辑 TO 访问时，需要时间很少的 OK 是完全可以正常访问的，但是在高并发的情况下，也就是说 TO 有很多访问量的时候， OK 还能够这么正常的访问吗？下面我们用 Jmeter 进行高并发压力测试，用 20000 个请求都去访问 TO 服务。

在 Jmeter 中新建一个 线程组 ：测试 Hystrix 用来模拟高并发访问 TO 服务，线程组配置参数如下：

然后我们用该线程组发送 HTTP 请求给 TO 服务，创建如下的 HTTP 请求进行压力测试：

我们观察 8001 服务的后端控制台，可以看到对 TO 服务进行了大量的访问。而此时我们再去访问 OK 服务时什么样的呢？=> 可以看到， OK 服务无法像之前一样很快能够得到访问，这里我们模拟的是 20000 的访问量（没敢模拟数字太大的访问量，怕把系统直接搞死），实际中可能会有远大于 20000 的访问量，当访问量更多的时候，甚至可能卡死服务，原因就是 Tomcat 的默认的工作线程数被打满了，没有多余的线程来分解压力和处理。

而刚才做的压力测试还只是服务提供方 8001 自己实现的测试，如果此时是外部的服务消费方 80 来访问该服务，那么服务消费方只能够进行干等，消费方显然会对这样的等待时间不满意，服务提供方很有可能直接被拖死。我们发现 8001 自测都会出现问题，那如果我们再用服务消费方测试呢？

2.3 服务消费者 80 模块进行压力测试

新建一个 Module：cloud-consumer-feign-hystrix-order80 作为服务消费方，服务消费方利用 feign 访问提供方的服务，编写对应的 service 接口如下：

@Component@FeignClient("CLOUD-PROVIDER-HYSTRIX-PAYMENT")public interface PaymentHystrixService {
    @GetMapping("/payment/hystrix/ok/{id}")    public String paymentInfo_OK(@PathVariable("id") Integer id);
    @GetMapping("/payment/hystrix/timeout/{id}")    public String paymentInfo_FAIL(@PathVariable("id") Integer id);}

复制代码

然后编写其 Controller：

@RestController@Slf4jpublic class OrderHystrixController {
    @Resource    private PaymentHystrixService paymentHystrixService;
    @GetMapping("/consumer/payment/hystrix/ok/{id}")    public String paymentInfo_OK(@PathVariable("id") Integer id) {        String result = paymentHystrixService.paymentInfo_OK(id);        return result;    }
    @GetMapping("/consumer/payment/hystrix/timeout/{id}")    public String paymentInfo_TimeOut(@PathVariable("id") Integer id) {        String result = paymentHystrixService.paymentInfo_FAIL(id);        return result;    }}

复制代码

将 80 服务启动，用 http://localhost/consumer/payment/hystrix/ok/1 对服务提供方的 OK 服务进行访问，再进行压力测试，和之前一样，无法迅速访问该服务，如果压力测试中的线程数更多的时候，很可能会造成超时错误，出现以下错误提示：

故障原因：8003 同一层次的其他接口服务被困死，因为 Tomcat 线程池里面的工作线程已经被挤占完毕，80 此时再调用 8003，必然导致客户端访问响应缓慢。正是因为出现了这种现象，所以我们才需要服务降级、容错、服务限流等技术。

2.4 发现问题

要解决的问题：

超时导致服务器变慢(转圈) => 超时不再等待
出错(宕机或程序运行出错) => 出错要有兜底

解决方案：

对方服务(8003)超时了，调用者(80)不能一直卡死等待，必须有服务降级
对方服务(8003)宕机了，调用者(80)不能一直卡死等待，必须有服务降级
对方服务(8003)OK，调用者(80)自己出故障或有自我要求(自己的等待时间小于服务提供者)，自己处理降级

3. Hystrix 服务降级 Fall Back

3.1 服务端服务提供方的服务降级

降级的配置用 @HystrixCommand 注解，在服务提供方自身找问题，设置自身调用超时时间的峰值，在峰值内可以正常运行，超过了峰值需要有兜底的方法处理，用作服务降级。

首先在服务提供方的业务类上启用 @HystrixCommand 实现报异常后如何处理，也就是一旦调用服务方法失败并抛出了错误信息后，会自动调用 @HystrixCommand 标注好的 fallbackMethod 服务降级方法。在服务提供方的 service 中我们修改 TO 服务：

@Servicepublic class PaymentService {    /**能够正常访问的方法*/    public String paymentInfo_OK(Integer id) {        return "线程池: " + Thread.currentThread().getName()                + " paymentInfo_OK,id: " + id + "\t" + "哈~";    }
    /**模拟出错的方法*/    @HystrixCommand(fallbackMethod = "paymentInfo_FailHandler",                    commandProperties = {            @HystrixProperty(                    name = "execution.isolation.thread.timeoutInMilliseconds",                    value = "3000")    })    public String paymentInfo_FAIL(Integer id) {        //int age = 10/0; //模拟异常，也会兜底        int timeNumber = 5;                //暂停几秒钟线程，程序本身没有错误，就是模拟超时        try {            TimeUnit.SECONDS.sleep(timeNumber);        }catch (InterruptedException e) {            e.printStackTrace();        }        return "线程池: " + Thread.currentThread().getName()                + " paymentInfo_FAIL,id: " + id + "\t" + "哈~ "                + "耗时" + timeNumber + "s";    }
    /** 定制服务降级方法*/    public String paymentInfo_FailHandler(Integer id) {        return "系统忙，请稍后再试";    }}

复制代码

然后在主启动类上添加 @EnableCircuitBreaker 注解对熔断器进行激活，TO 服务的访问时间 5 秒，而我们用 Hystrix 配置的时间峰值为 3 秒，也就是当 服务超时或服务出错 时，会访问我们设置的 fallbackMethod 服务降级方法，再次访问 TO 服务，我们发现其执行的方法确实为服务降级方法：

注意：我们自己配置过的热部署方式对 Java 代码的改动明显，但对 @HystrixCommand 内属性的修改建议重启微服务（有时不能及时生效）

3.2 客户端服务消费方的服务降级

既然服务的提供方可以进行降级保护，那么服务的消费方，也可以更好地保护自己，也可以对自己进行降级保护，也就是说 Hystrix 服务降级既可以放在服务端（服务提供方），也可以放在客户端（服务消费方），但是！通常是用客户端做服务降级，下面在服务消费方即客户端配置自己的服务降级保护，修改 80 消费方的配置文件，添加如下配置已使其支持 Hystrix：

feign:  hystrix:    enabled: true

复制代码

在 80 消费方的主启动类上添加 @EnableHystrix 激活 Hystrix 服务。然后在 80 的 Controller 中同样加入 @HystrixCommand 注解已实现服务降级：

@RestController@Slf4jpublic class OrderHystrixController {
    @Resource    private PaymentHystrixService paymentHystrixService;
    @GetMapping("/consumer/payment/hystrix/ok/{id}")    public String paymentInfo_OK(@PathVariable("id") Integer id) {        String result = paymentHystrixService.paymentInfo_OK(id);        return result;    }

    @GetMapping("/consumer/payment/hystrix/timeout/{id}")    @HystrixCommand(fallbackMethod = "paymentInfo_FailHandler",            commandProperties = {                    @HystrixProperty(                            name = "execution.isolation.thread.timeoutInMilliseconds",                            value = "1500")            })    public String paymentInfo_TimeOut(@PathVariable("id") Integer id) {        String result = paymentHystrixService.paymentInfo_FAIL(id);        return result;    }
    /** 定制服务降级方法*/    public String paymentInfo_FailHandler(Integer id) {        return "我是消费者80，系统忙，请稍后再试";    }}

复制代码

也就是说如果消费方访问服务提供方的时间超过了 1.5 秒，那么就会访问自己的降级服务方法。

3.3 统一全局服务降级方法

而当前的这种处理方式是有问题的，也就是每个业务方法都对应了一个服务降级方法，这会导致代码膨胀，所以我们应该定义一个统一的服务降级方法，统一的方法和自定义的方法分开。而且我们将服务降级方法和业务逻辑混合在了一起，这会导致代码混乱，业务逻辑不清晰。

对于第一个问题，我们可以用 feign 接口中的 @DefaultProperties(defaultFallback = "") 注解来配置全局的服务降级方法，也就是说自己配置过 @HystrixCommand(fallbackMethod = ""） fallbackMethod 方法的采用自己配置的服务降级方法，而没有配置过的就采用 @DefaultProperties(defaultFallback = "") 配置的全局的服务降级方法。这样的话通用的服务降级方法和独享的服务降级方法分开，避免了代码膨胀，合理减少了代码量，修改服务消费方 80 的 Controller 入下：

@RestController@Slf4j//没有特别指明就用这个统一的@DefaultProperties(defaultFallback = "payment_Global_FailHandler")public class OrderHystrixController {
    @Resource    private PaymentHystrixService paymentHystrixService;
    @GetMapping("/consumer/payment/hystrix/ok/{id}")    public String paymentInfo_OK(@PathVariable("id") Integer id) {        String result = paymentHystrixService.paymentInfo_OK(id);        return result;    }

    @GetMapping("/consumer/payment/hystrix/timeout/{id}")    //特别指明使用哪一个兜底方法//    @HystrixCommand(fallbackMethod = "paymentInfo_FailHandler",//            commandProperties = {//                    @HystrixProperty(//                            name = "execution.isolation.thread.timeoutInMilliseconds",//                            value = "1500")//    })    @HystrixCommand //没有具体指明就使用全局的    public String paymentInfo_TimeOut(@PathVariable("id") Integer id) {        String result = paymentHystrixService.paymentInfo_FAIL(id);        return result;    }
    /** 定制服务降级方法*/    public String paymentInfo_FailHandler(Integer id) {        return "我是消费者80，系统忙，请稍后再试";    }
    /**     * 全局服务降级方法     * @return     */    public String payment_Global_FailHandler() {        return "全局异常处理信息";    }}

复制代码

这里需要注意的是，无论是否配置了定制服务降级方法，都要在其服务上加入注解 @HystrixCommand ，否则服务降级和该服务没关系。

而对于第二个问题，我们可以为 Feign 客户端定义的接口添加一个服务降级处理的实现类即可实现解耦，我们的 80 客户端已经有了 PaymentHystrixService 接口，我们新建一个类 PaymentFallbackService 实现该接口，并重写接口中的方法，为接口里的方法进行异常处理，并且我们在 PaymentHystrixService @FeignClient 注解中声明其服务降级方法所在的类：

@Service//当出现错误是到PaymentFallbackService类中找服务降级方法@FeignClient(value = "CLOUD-PROVIDER-HYSTRIX-PAYMENT",              fallback = PaymentFallbackService.class)public interface PaymentHystrixService {
    @GetMapping("/payment/hystrix/ok/{id}")    public String paymentInfo_OK(@PathVariable("id") Integer id);
    @GetMapping("/payment/hystrix/timeout/{id}")    public String paymentInfo_FAIL(@PathVariable("id") Integer id);}

复制代码

@Servicepublic class PaymentFallbackService implements PaymentHystrixService{    @Override    public String paymentInfo_OK(Integer id) {        return "PaymentHystrixService paymentInfo_OK出现异常";    }
    @Override    public String paymentInfo_FAIL(Integer id) {        return "PaymentHystrixService paymentInfo_Fail出现异常";    }}

复制代码

然后我们将 Controller 中耦合的代码都取消：

@RestController@Slf4jpublic class OrderHystrixController {
    @Resource    private PaymentHystrixService paymentHystrixService;
    @GetMapping("/consumer/payment/hystrix/ok/{id}")    public String paymentInfo_OK(@PathVariable("id") Integer id) {        String result = paymentHystrixService.paymentInfo_OK(id);        return result;    }
    @GetMapping("/consumer/payment/hystrix/timeout/{id}")    public String paymentInfo_TimeOut(@PathVariable("id") Integer id) {        String result = paymentHystrixService.paymentInfo_FAIL(id);        return result;    }}

复制代码

然后我们关闭 8001 服务提供方服务，模拟服务器宕机，在服务访问出现错误时，访问了我们配置的 PaymentFallbackService 类中的服务降级方法，这样就实现了代码的解耦，使业务逻辑不再混乱。

4. Hystrix 服务熔断 Break

4.1 熔断机制概述

服务的降级 => 进而熔断 => 恢复调用链路

熔断机制是应对雪崩效应的一种微服务链路保护机制，当扇出链路的某个微服务出错不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，也就是说服务熔断会导致服务降级，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路。也就是说，服务熔断在服务好了之后会重新允许访问服务。

在 SpringCloud 框架中，熔断机制通过 Hystrix 实现。Hystrix 会监控微服务间的调用状况，当失败的调用到一定阈值，缺省是 5 秒内 20 次调用失败，就会启动熔断机制。熔断机制的注解是 @HystrixCommand 。关于熔断机制，具体可以参考论文 CircuitBreaker 。

4.2 实例

在 8003 服务提供方的 Service 中添加如下代码：

/** * 服务熔断 * fallbackMethod                               服务降级方法 * circuitBreaker.enabled                       是否开启断路器 * circuitBreaker.requestVolumeThreshold        请求次数 * circuitBreaker.sleepWindowInMilliseconds     时间窗口期 * circuitBreaker.errorThresholdPercentage      失败率达到多少后跳闸 * * 以下配置意思是在10秒时间内请求10次，如果有6次是失败的，就触发熔断器 * * 注解@HystrixProperty中的属性在com.netflix.hystrix.HystrixCommandProperties类中查看 */@HystrixCommand(fallbackMethod = "paymentCircuitBreaker_fallback",        commandProperties = {             @HystrixProperty(name = "circuitBreaker.enabled",                            value = "true"),             @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold",                            value = "10"),             @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds",                            value = "10000"),             @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage",                           value = "60")       })public String paymentCircuitBreaker(@PathVariable("id") Integer id) {    if (id < 0) {        throw new RuntimeException("===> id 不能为负数");    }    //hutool工具类的使用,等价于UUID.randomUUID().toString()    String serialNumber = IdUtil.simpleUUID();    return Thread.currentThread().getName() + " 调用成功，流水号： " + serialNumber;}
/** * 服务熔断触发的服务降级方法 * @param id * @return */public String paymentCircuitBreaker_fallback(@PathVariable("id") Integer id) {    return "id 不能为负数，请稍后再试。id:" + id;}

复制代码

在 @HystrixCommand 注解中配置熔断机制的参数，配置的参数含义如下：

属性名

含义

默认值

circuitBreaker.enabled

是否开启断路器

true

circuitBreaker.requestVolumeThreshold

请求次数

20 次

circuitBreaker.sleepWindowInMilliseconds

时间窗口期

5000ms

circuitBreaker.errorThresholdPercentage

失败率达到多少后跳闸

50%

这些属性名的具体含义以及其默认值可以在 com.netflix.hystrix.HystrixCommandProperties 类中进行查看。而我们在 service 中配置的意思就是在 10 秒时间内请求 10 次，如果有 6 次是失败的，就触发熔断器。

在 Controller 中添加该服务:

@GetMapping("circuit/{id}")public String paymentCircuitBreaker(@PathVariable("id") Long id) {    String result = paymentService.paymentCircuitBreaker(id);    log.info("====> result:" + result);    return result;}

复制代码

4.3 测试

根据我们的业物逻辑，也就是当我们的 id 为整数时，服务可以正常访问，而当 id 为负数时，访问服务出错。我们先访问 http://localhost:8003/payment/hystrix/circuit/11 代表正确的服务请求，可以发现一切正常！

然后我们进行大量的错误访问，强行触发服务熔断，然后在进行正确的访问。我们发现在进行超出我们阈值的错误访问后，触发了服务熔断，即使再进行正确的访问也无法进行，但是一定时间后，正确的服务访问又可以顺利进行，这就是服务熔断的整体过程：在触发了服务熔断后，先进行服务的降级，再 逐渐恢复调用链路 。

4.4 总结

结合官网中对熔断机制的描述，其熔断过程可以如下描述：

熔断器打开和关闭的精确方式如下：

假设电路上的访问达到某个阈值（ HystrixCommandProperties.circuitBreakerRequestVolumeThreshold() ）…
并假设误差百分比超过阈值误差百分比（ HystrixCommandProperties.circuitBreakerErrorThresholdPercentage() ）…
然后，断路器从 CLOSED 为 OPEN ，触发熔断机制。
当它断开时，它会使针对该断路器的所有请求短路。
经过一段时间（ HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds() ）后，下一个单个请求被允许通过（这是 HALF-OPEN 状态）。如果请求失败，断路器将 OPEN 在睡眠窗口期间返回到该状态。如果请求成功则断路器切换到 CLOSED ，并且第一条中的逻辑再次接管。

也就是在熔断机制中，熔断器分为三个状态：

状态

说明

熔断器打开 OPEN

请求不再进行调用当前服务，内部设置时钟一般为 MTTR（平均故障处理时间），当打开时长达到所设时钟则进入半熔断状态（HALF-OPEN）。

熔断器关闭 CLOSED

熔断关闭不会对服务进行熔断。

熔断器半开 HALF-OPEN

部分请求根据规则调用当前服务，如果请求成功且符合规则则认为当前服务恢复正常，关闭熔断。

下面是官网上的熔断器流程图：

那么熔断器在什么情况下开始起作用呢？

涉及到熔断器的三个重要参数：快照时间窗，请求总数阈值，错误百分比阈值

快照时间窗口期 circuitBreaker.sleepWindowInMilliseconds ：熔断器是否打开需要统计一些请求和错误数据，而统计的时间范围就是快找时间窗，默认为最近的 10 秒；
请求总数阈值 circuitBreaker.requestVolumeThreshold ：在快照时间窗内，必须满足请求总数阈值才有资格触发熔断，默认为 20 次，这意味着在快照时间窗规定的时间内，如果该 Hystrix 命令的调用次数不足 20 次，即使所有请求都超时或其他原因失败，熔断器都不会打开；
错误百分比阈值 circuitBreaker.errorThresholdPercentage ：当请求总数在快照时间窗内超过了阈值，且在这些调用中，超过错误百分比阈值比例的错误调用，熔断器就会打开。

在熔断器打开后

熔断器打开后再有请求调用的时候，将不会调用主逻辑，而是直接调用服务降级的方法，实现了自动发现错误并将降级逻辑切换为主逻辑，减少响应延迟的效果。

原来的主逻辑如何恢复呢? => 当熔断器打开后，对主逻辑进行熔断之后，Hystrix 会启动一个 休眠时间窗 ，在这个时间窗内，降级逻辑是临时的主逻辑，当休眠时间窗到期，熔断器会进入半开状态，释放一次请求到原来的主逻辑上，如果此次请求能够正常访问，则熔断器会进入闭合状态，从而恢复主逻辑，如果注册请求依然有问题，则熔断器继续保持打开状态，并且休眠时间窗重新计时。

Hystrix 所有常用配置

服务限流在 Alibaba 的 Sentinel 框架中会详解

5. Hystrix 工作流程

官网说明（Hystrix 怎么实操降级熔断限流

整体的 Hystrix 工作流程图如下：

步骤说明：

6. Hystrix 服务监控 Hystrix Dashboard

6.1 理解

除了隔离依赖服务的调用以外，Hystrix 还提供了准实时的调用监控——Hystrix Dashboard，Hystrix 会持续地记录所有通过 Hystrix 发起的请求的执行信息，并以统计报表和图形的形式展示给用户，包括每秒执行多少请求，多少成功，多少失败等。SpringCloud 也提供了 Hystrix Dashboard 的整合，对监控内容转化成可视化界面。

6.2 使用步骤

新建 Module：cloud-consumer-hystrix-dashboard9001 作为 Hystrix Dashboard 服务

添加 Hystrix Dashboard 的依赖：

<dependencies>    <!-- Hystrix Dashboard -->    <dependency>        <groupId>org.springframework.cloud</groupId>        <artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>    </dependency>    <!-- actuator监控 -->    <dependency>        <groupId>org.springframework.boot</groupId>        <artifactId>spring-boot-starter-actuator</artifactId>    </dependency>    <!-- 通用配置 -->    <dependency>        <groupId>org.springframework.boot</groupId>        <artifactId>spring-boot-devtools</artifactId>        <scope>runtime</scope>        <optional>true</optional>    </dependency>    <dependency>        <groupId>org.projectlombok</groupId>        <artifactId>lombok</artifactId>        <optional>true</optional>    </dependency>    <dependency>        <groupId>org.springframework.boot</groupId>        <artifactId>spring-boot-starter-test</artifactId>        <scope>test</scope>    </dependency></dependencies>

复制代码

写配置文件 application.yml，加个端口即可：

server:  port: 9001

复制代码

编写主启动类，在主启动类上添加 @EnableHystrixDashboard 注解开启 Hystrix Dashboard 功能：

@SpringBootApplication@EnableHystrixDashboardpublic class HystrixDashboardMain9001 {    public static void main(String[] args) {        SpringApplication.run(HystrixDashboardMain9001.class);    }}

复制代码

注意：所有的服务提供方微服务（如我们的 8001/8002/8003）都需要监控依赖配置：

<!--actuator监控信息完善--><dependency>	<groupId>org.springframework.boot</groupId>	<artifactId>spring-boot-starter-actuator</artifactId></dependency>

复制代码

访问 http://localhost:9001/hystrix 我们就可以看见 Hystrix Dashboard 的图形化界面

注意：新版本 Hystrix 需要在主启动类中指定监控路径（否则会报错：Unable to connect to Command Metric Stream）。为了让服务提供方的服务能被 Hystrix Dashboard 监控到，需要在提供方服务的主启动类中添加如下配置：

/** * 此配置是为了服务监控而配置，与服务容错本身无关，springcloud升级后的坑 * ServletRegistrationBean因为springboot的默认路径不是"/hystrix.stream"， * 只要在自己的项目里配置上下面的servlet就可以了 */@Beanpublic ServletRegistrationBean getServlet() {    HystrixMetricsStreamServlet streamServlet = new HystrixMetricsStreamServlet();    ServletRegistrationBean registrationBean = new ServletRegistrationBean(streamServlet);    registrationBean.setLoadOnStartup(1);    registrationBean.addUrlMappings("/hystrix.stream");    registrationBean.setName("HystrixMetricsStreamServlet");    return registrationBean;}

复制代码

在 Hystrix Dashboard 的图形化界面中输入要监控的服务提供者：

下面就是 Dashboard 对服务的监控状态：

如何看？

七色
一圈实现圆共有两种含义。它通过颜色的变化代表了实例的健康程度，它的健康度从绿色<黄色<橙色<红色递减。该实心圆除了颜色的变化之外，它的大小也会根据实例的请求流量发生变化，流量越大该实心圆也就越大。所以通过该实心圆的展示，就可以在大量的实例中快速的发现故障实例和高压力实例。
一线曲线用来记录 2 分钟内流量的相对变化，可以通过它来观察到流量的上升和下降趋势
整图说明 1

整图说明 2

一些复杂的情况

原文链接：https://www.cnblogs.com/mpolaris/p/14459451.html?utm_source=tuicool&utm_medium=referral

如果觉得本文对你有帮助，可以关注一下我公众号，回复关键字【面试】即可得到一份 Java 核心知识点整理与一份面试大礼包！另有更多技术干货文章以及相关资料共享，大家一起学习进步！

发布于: 2021 年 03 月 01 日阅读数: 17

原文链接:【http://xie.infoq.cn/article/b12d67c0d33c589981f2cbdbe】。未经作者许可，禁止转载。

Java王路飞

关注

需要资料添加小助理vx：17375779923 即可 2021.01.29 加入

Java领域;架构知识;面试心得;互联网行业最新资讯

评论 (1 条评论)

发布

Java王路飞

大白话详解 Spring Cloud 服务降级与熔断

2021 年 03 月 01 日 15:17

 0 回复

没有更多了

创作场景

大白话详解 Spring Cloud 服务降级与熔断

1. Hystrix 断路器概述

1.1 分布式系统面临的问题

1.2 Hystrix 是什么

1.3 Hystrix 作用

1.4 Hystrix 重要概念

2. Hystrix 案例

2.1 服务提供者 8003 模块

建 Module

pom.xml

yml 配置文件 / 主启动类

业务类

2.2 8003 高并发测试

服务提供方自测压力测试：

2.3 服务消费者 80 模块进行压力测试

2.4 发现问题

3. Hystrix 服务降级 Fall Back

3.1 服务端服务提供方的服务降级

3.2 客户端服务消费方的服务降级

3.3 统一全局服务降级方法

4. Hystrix 服务熔断 Break

4.1 熔断机制概述

4.2 实例

在 8003 服务提供方的 Service 中添加如下代码：

在 Controller 中添加该服务:

4.3 测试

4.4 总结

熔断器打开和关闭的精确方式如下：

也就是在熔断机制中，熔断器分为三个状态：

那么熔断器在什么情况下开始起作用呢？

在熔断器打开后

Hystrix 所有常用配置

5. Hystrix 工作流程

6. Hystrix 服务监控 Hystrix Dashboard

6.1 理解

6.2 使用步骤

Java王路飞

评论 (1 条评论)