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

1. Hystrix断路器概述

1.1 分布式系统面临的问题

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

多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其他的微服务，这就是所谓的“ 扇出 ”（像一把打开的折扇）。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，这就是所谓的” 雪崩效应# 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模块# 建Modulecloud-provider-hystrix-payment8003# pom.xml org.springframework.cloud spring-cloud-starter-netflix-hystrix# yml配置文件 / 主启动类server: port: 8003spring: application: name: cloud-provider-hystrix-paymenteureka: 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 熔断机制概述服务的降级 => 进而熔断 => 恢复调用链路熔断机制是应对雪崩效应的一种微服务链路保护机制，当扇出链路的某个微服务出错不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，也就是说服务熔断会导致服务降级，快速返回错误的响应信息。 当检测到该节点微服务调用响应正常后，恢复调用链路。 也就是说，服务熔断在服务好了之后会重新允许访问服务。在此我向大家推荐一个架构学习交流圈。交流学习指导伪鑫：1253431195（里面有大量的面试题及答案）里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多在SpringCloud框架中，熔断机制通过Hystrix实现。Hystrix会监控微服务间的调用状况， 当失败的调用到一定阈值，缺省是5秒内20次调用失败，就会启动熔断机制。 熔断机制的注解是@HystrixCommand 。关于熔断机制，具体可以参考论文 CircuitBreaker 。[外链图片转存中…(img-TySItkBy-1657707778442)]# 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 注解中配置熔断机制的参数，配置的参数含义如下：这些属性名的具体含义以及其默认值可以在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所有常用配置[外链图片转存中…(img-eSPVoZoa-1657707778446)]服务限流在Alibaba的Sentinel框架中会详解# 5. Hystrix工作流程官网说明（Hystrix怎么实操降级熔断限流整体的Hystrix工作流程图如下：[外链图片转存中…(img-piuvibv1-1657707778447)]步骤说明：# 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的依赖： org.springframework.cloud spring-cloud-starter-netflix-hystrix-dashboard org.springframework.boot spring-boot-starter-actuator org.springframework.boot spring-boot-devtools runtime true org.projectlombok lombok true org.springframework.boot spring-boot-starter-test test 写配置文件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）都需要监控依赖配置： org.springframework.boot spring-boot-starter-actuator访问 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* 一些复杂的情况