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

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服务的后端控制台，可以看到对 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 @Slf4j 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}") 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 服务进行访问，再进行压力测试，和之前一样，无法迅速访问该服务，如果压力测试中的线程数更多的时候，很可能会造成超时错误，出现以下错误提示：

​

编辑切换为居中

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

故障原因：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 服务：

@Service public 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服务，我们发现其执行的方法确实为服务降级方法：

​

编辑

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

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

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

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

feign: hystrix: enabled: true

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

@RestController @Slf4j 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") }) 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); }

@Service public 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 @Slf4j 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}") 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 。

​

编辑切换为居中

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

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 总结

​

编辑切换为居中

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

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

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

• 假设电路上的访问达到某个阈值（ HystrixCommandProperties.circuitBreakerRequestVolumeThreshold() ）…

• 并假设误差百分比超过阈值误差百分比（ HystrixCommandProperties.circuitBreakerErrorThresholdPercentage() ）…

• 然后，断路器从 CLOSED 为 OPEN ，触发熔断机制。

• 当它断开时，它会使针对该断路器的所有请求短路。

• 经过一段时间（ HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds() ）后，下一个单个请求被允许通过（这是 HALF-OPEN 状态）。如果请求失败，断路器将 OPEN在睡眠窗口期间返回到该状态。如果请求成功则断路器切换到 CLOSED ，并且第一条中的逻辑再次接管。

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

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

​

编辑切换为居中

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

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

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

• 快照时间窗口期 circuitBreaker.sleepWindowInMilliseconds ：熔断器是否打开需要统计一些请求和错误数据，而统计的时间范围就是快找时间窗，默认为最近的10秒；

• 请求总数阈值 circuitBreaker.requestVolumeThreshold ：在快照时间窗内，必须满足请求总数阈值才有资格触发熔断，默认为20次，这意味着在快照时间窗规定的时间内，如果该Hystrix命令的调用次数不足20次，即使所有请求都超时或其他原因失败，熔断器都不会打开；

• 错误百分比阈值 circuitBreaker.errorThresholdPercentage ：当请求总数在快照时间窗内超过了阈值，且在这些调用中，超过错误百分比阈值比例的错误调用，熔断器就会打开。

在熔断器打开后

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

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

Hystrix所有常用配置

​

编辑切换为居中

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

​

编辑切换为居中

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

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

5. Hystrix工作流程

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

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

​

编辑切换为居中

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

步骤说明：

​

编辑切换为居中

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

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 @EnableHystrixDashboard public 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就可以了 */ @Bean public 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的图形化界面中输入要监控的服务提供者：

​

编辑切换为居中

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

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

​

编辑切换为居中

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

如何看？

• 七色

• 一圈 实现圆共有两种含义。它通过颜色的变化代表了实例的健康程度，它的健康度从绿色<黄色<橙色<红色递减。该实心圆除了颜色的变化之外，它的大小也会根据实例的请求流量发生变化，流量越大该实心圆也就越大。所以通过该实心圆的展示，就可以在大量的实例中快速的发现 故障实例和高压力实例。

• 一线 曲线用来记录2分钟内流量的相对变化，可以通过它来观察到流量的上升和下降趋势

• 整图说明1

​

编辑切换为居中

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

• 整图说明2

​

编辑切换为居中

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

• 一些复杂的情况

​

                                              资源获取：
大家 点赞、收藏、关注、评论啦 、 查看

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/AllinToyou/article/detail/536978