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

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 @EnableEurekaClient public class PaymentHystrixMain8003 { public static void main(String[] args) { SpringApplication.run(PaymentHystrixMain8003.class,args); } }

业务类

• service

@Service public 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 服务，线程组配置参数如下：

​

编辑切换为居中

添加图片注释，不超过 140 字（可选）

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

​

编辑切换为居中

添加图片注释，不超过 140 字（可选）

我们观察8001服务的后端控制台，可以看到