Hystrix断路器原理及实现（服务降级、熔断、限流）
Hystrix断路器原理及实现（服务降级、熔断、限流）
- 分布式系统面临的问题
- Hystrix重要概念（面试常考）
- Hystrix案例
-
- Hystrix 服务提供者
- Hystrix 服务消费者
- 原因与解决方案
- 服务降级
- 服务熔断
- 服务限流（后续更新）
- Hystrix 工作流程
- 服务监控 HystrixDashboard
分布式系统面临的问题
1、服务雪崩
服务雪崩：多个服务之间在调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓“雪崩效应”。
对于高流量的应用来说，单一的后端依赖可能会导致所有的服务器上的所有资源都在几面中内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。所以，通常当你发现一个模块下的某个实例失败后，这时候这个模块依然还会接受流量，然后这个有问题的模块还调用了其他的模块，这样就会发生级联故障，或者叫雪崩。
2、Hystrix概念及作用
Hystrix是一个用于处理分布式系统的延迟和容错的开源库。在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整个服务失败，避免级联故障，以提高分布式系统的弹性。
“断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个符合预期的、可处理的预备响应（FallBack），而不是长时间等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要的占用，从而避免了故障在分布式系统中蔓延，乃至雪崩。
Hystrix重要概念（面试常考）
一、服务降级（fallback）
1、当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝），
向调用方返回一个符合预期的、可处理的预备响应（FallBack），而不是长时间等待或者抛出调用方无法处理的异常。比如：服务繁忙，请稍后再试，不让客户端等待并立刻返回一个友好提示：fallback。
2、哪些情况会触发降级
（1）程序运行异常
（2）超时
（3）服务熔断触发服务降级
（4）线程池/信号量打满也会导致服务降级
二、服务熔断（break）
1、系统发到最大服务访问量后，直接拒绝访问，限制后续的服务访问，并调用服务降级方法返回友好提示。
2、就是保险丝：服务降级–>进而熔断–>恢复调用链路
三、服务限流（flowlimit）
1、限流的目的是为了保护系统不被大量请求冲垮，通过限制请求的速度来保护系统。在电商的秒杀活动中，限流是必不可少的一个环节。限制高并发，请求进行排队，一秒处理N个请求，有序的进行。
Hystrix案例
Hystrix 服务提供者
1、导入pom依赖
注意：Eureka 中自带 springcloud-netfilx 的 Hystrix 依赖
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-netflix-hystrixartifactId>
dependency>
2、写yml配置文件
server:
port: 8001
spring:
application:
name: cloud-provider-hystrix-payment
eureka:
client:
#表示收将自己注册到EurekaServer，默认为true
register-with-eureka: true
#是否从EurekaServer抓取已有的注册信息，默认为true，单节点无所谓，集群必须设置为true才能配合ribbon使用负载均衡
fetchRegistry: true
service-url:
# defaultZone: http://localhost:7001/eureka #单机版
defaultZone: http://eureka7001.com:7001/eureka,http://eureka7002.com:7002/eureka #集群版
instance:
instance-id: hystrix-payment8001
#访问路径可以显示IP地址
prefer-ip-address: true
#eureka客户端向服务端发送心跳的时间间隔，单位为秒（默认为30秒）
lease-renewal-interval-in-seconds: 1
#eureka服务端在收到最后一次心跳后等待时间上限，单位为秒（默认为90秒），超时将删除服务
lease-expiration-duration-in-seconds: 2
3、主启动
@SpringBootApplication
@EnableEurekaClient
public class HystrixMainPayment8001 {
public static void main(String[] args) {
SpringApplication.run(HystrixMainPayment8001.class, args);
}
}
4、业务类
@Service
public class PaymentServiceImpl implements PaymentService {
/**
* 正常访问
*
* @return
* @params
*/
@Override
public String paymentInfo_OK(Integer id) {
return "线程池：" + Thread.currentThread().getName() + " paymentInfo_OK，id：" + id + "\t" + "笑脸，哈哈哈";
}
@Override
public String paymentInfo_Error(Integer id) {
int time = 3;
try {
TimeUnit.SECONDS.sleep(time);
} catch (InterruptedException e) {
e.printStackTrace();
}
return "线程池：" + Thread.currentThread().getName() + " paymentInfo_Timeout，id：" + id + "\t" + "哭脸，呜呜呜，耗时" + time + "秒";
}
}
5、controller
@RestController
@Slf4j
public class PaymentController {
@Resource
private PaymentService paymentService;
@GetMapping(value = "/payment/hystrix/ok/{id}")
public String getOK(@PathVariable("id") Integer id) {
String result = paymentService.paymentInfo_OK(id);
log.info("***result:{}" + result);
return result;
}
@GetMapping(value = "/payment/hystrix/error/{id}")
public String getError(@PathVariable("id") Integer id) {
String result = paymentService.paymentInfo_Error(id);
log.info("***result:{}" + result);
return result;
}
}
5、使用JMeter进行 （服务提供者自测） 测试，结果分析
（1）正常访问时，请求ok：每次刷新都很快响应请求，请求error： 也是在相应的时间内得到响应。
（2）使用JMeter发出 200次/s 请求时，请求 ok 服务也响应的变慢，error 也会变慢。
（3）结论：那么为什么会导致这种结果呢？
tomcat 的默认工作线程数被打满了，没有多余的线程来分解压力和处理。
Hystrix 服务消费者
1、引入pom依赖
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-netflix-hystrixartifactId>
dependency>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-openfeignartifactId>
dependency>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-netflix-eureka-clientartifactId>
dependency>
2、写yml配置文件
server:
port: 80
spring:
application:
name: cloud-payment-hystrix-order
eureka:
client:
#是否将自己注册到注册中心, 默认true
register-with-eureka: true
#是否从EurekaServer抓取已有的注册信息,单机无所谓,集群必须设置为true配合ribbon使用负载均衡
fetch-registry: true
service-url:
# defaultZone: http://localhost:7001/eureka #单机版
defaultZone: http://eureka7001.com:7001/eureka,http://eureka7002.com:7002/eureka #集群版
instance:
instance-id: hystrix-order80
#访问路径可以显示IP地址
prefer-ip-address: true
#eureka客户端向服务端发送心跳的时间间隔，单位为秒（默认为30秒）
lease-renewal-interval-in-seconds: 1
#eureka服务端在收到最后一次心跳后等待时间上限，单位为秒（默认为90秒），超时将删除服务
lease-expiration-duration-in-seconds: 4
#设置feign客户端超时时间(OpenFeign 默认支持ribbon)
ribbon:
#指的是建立连接所用时间,适用于网络状况正常情况下,两端连接所用时间
ReadTimeout: 5000
#指的是连接建立后,从服务器获取到可用资源所用时间
ConnectTimeout: 4000
3、省略服务调用，可参考：https://blog.csdn.net/qq_36763419/article/details/120063156
4、高并发测试
使用JMeter发出2w个线程压8001和8002，消费者80再去访问正常的ok微服务8001地址时候，消费者出现响应变慢（转圈圈），或者消费端报请求超时错误。
原因与解决方案
1、原因
服务提供者同一层次的其他接口服务被困死，因为 tomcat 线程池里面的线程已经被挤占完毕。消费者80此时调用服务提供者，客户端访问响应缓慢，转圈圈。
2、解决方案
（1）
问题：A、超时导致服务器变慢（转圈）：超时不再等待。
B、出错（宕机或程序运行报错）：出错要兜底。（2）
解决：A、对方服务（8001）超时了，调用者（80）不能一直卡死等待，必须有服务降级。
B、对方服务（8001）宕机了，调用这不能一直卡死等待，必须有服务降级。
C、对方服务（8001）OK，调用者（80）自己出故障或有自我要求（自己的等待时间小于服务提供者时间）,调用者（80）自己降级处理。
服务降级
1、降级配置（通常在消费者配置）：@HystrixCommand
2、服务提供者8001，先从自身找问题：设置服务提供者自身调用超时时间的峰值，峰值内正常运行，超过了需要有兜底的方法处理，作服务降级fallback。
3、8001 fallback
（1）业务类启用
@Service
public class PaymentServiceImpl implements PaymentService {
/*
使用 HystrixCommand 注解中 fallbackMethod 属性指的是当前
方法在调用失败的时候 执行的 paymentInfo_errorHandler 该方法【兜底方法】
@HystrixProperty(name = "execution.isolation.thread.timeoutMilliseconds", value = "3000") 表示请求改线程的时间为 3秒 是正常峰值
*/
@HystrixCommand(
fallbackMethod = "paymentInfo_errorHandler",
commandProperties = {@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "3000")}
)
@Override
public String paymentInfo_Error(Integer id) {
int time =5000;
// int a = 10 / 0;
// System.out.println(a);
try {
Thread.sleep(time);
} catch (InterruptedException e) {
e.printStackTrace();
}
return "线程池：" + Thread.currentThread().getName() + " paymentInfo_Timeout，id：" + id + "\t" + "哭脸，呜呜呜，耗时" + time + "秒";
}
public String paymentInfo_errorHandler(Integer id) {
return "线程池：" + Thread.currentThread().getName() + "系统繁忙或运行报错 paymentInfo_errorHandler，id：" + id + "\t" + "哭脸，呜呜呜";
}
}
（2）主启动类激活：添加新注解@EnableCircuitBreaker
4、80 fallback
（1）yml 添加如下配置
feign:
hystrix:
enabled: true #如果处理自身的容错就开启。开启方式与生产端不一样。
（2）主启动类激活：添加新注解@EnableHystrix
（3）业务类
@Component
@FeignClient(value = "CLOUD-PROVIDER-HYSTRIX-PAYMENT")
public interface PaymentHystrixService {
@GetMapping(value = "/payment/hystrix/ok/{id}")
public String getOK(@PathVariable("id") Integer id);
@GetMapping(value = "/payment/hystrix/error/{id}")
public String getError(@PathVariable("id") Integer id);
}
（4）controller
package com.atguigu.springcloud.controller;
import com.atguigu.springcloud.service.PaymentHystrixService;
import com.netflix.hystrix.contrib.javanica.annotation.DefaultProperties;
import com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand;
import com.netflix.hystrix.contrib.javanica.annotation.HystrixProperty;
import lombok.extern.slf4j.Slf4j;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RestController;
import javax.annotation.Resource;
/**
* @author 李宏伟
* @version 1.0
* @ClassName OrderController
* @Description
* @date 2021年09月06日 0:43
*/
@RestController
@Slf4j
//@DefaultProperties(defaultFallback = "payment_Global_FallbackMethod") //全局的
public class OrderHystrixController {
@Resource
private PaymentHystrixService paymentHystrixService;
@GetMapping(value = "/consumer/hystrix/ok/{id}")
public String getOK(@PathVariable("id") Integer id) {
String result = paymentHystrixService.getOK(id);
log.info("***result:{}" + result);
return result;
}
@GetMapping(value = "/consumer/hystrix/error/{id}")
// @HystrixCommand(
// fallbackMethod = "getErrorFallbackMethod",
// commandProperties = {
// //表示 3秒钟 以内就是正常的业务逻辑
// @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1500")
// }
// )
public String getError(@PathVariable("id") Integer id) {
String result = paymentHystrixService.getError(id);
log.info("***result:{}" + result);
return result;
}
public String getErrorFallbackMethod(Integer id) {
return "我是消费者80，对方支付系统繁忙请10秒钟后再试或者自己运行出错请检查自己,(┬＿┬)";
}
//下面是全局fallback方法
public String payment_Global_FallbackMethod() {
return "Global异常处理信息，请稍后再试,(┬＿┬)";
}
}
5、目前的问题与解决方案
（1）问题：每个业务方法对应一个兜底方法，导致代码膨胀
（2）解决方案：统一和自定义的分开【全局配置、部分定制配置fallback】。即：只需要为Feign客户端定义的接口添加一个服务降级处理的实现类即可实现解耦。根据 cloud-consumer-feign-hystrix-order80 已经有的 PaymentHystrixService 接口，创建类（PaymentFallbackServiceImpl）实现该接口，统一为接口里面的方法进行异常处理。代码如下：
A、Feign 远程调用接口类
@Component
@FeignClient(value = "CLOUD-PROVIDER-HYSTRIX-PAYMENT", fallback = PaymentFallbackServiceImpl.class)
//服务降级全局配置，针对微服务所有的请求进行该降级规则
@DefaultProperties(
commandProperties = {
@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1500")
}
)
public interface PaymentHystrixService {
@GetMapping(value = "/payment/hystrix/ok/{id}")
//对指定调用接口进行访问时间限制，并在指定时间内无响应，则进行服务降级
@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1500")
public String getOK(@PathVariable("id") Integer id);
@GetMapping(value = "/payment/hystrix/error/{id}")
public String getError(@PathVariable("id") Integer id);
}
B、Fallback 实现类
@Component
public class PaymentFallbackServiceImpl implements PaymentHystrixService {
@Override
public String getOK(Integer id) {
return "-------- PaymentFallbackServiceImpl fallback ----------";
}
@Override
public String getError(Integer id) {
return "-------- PaymentFallbackServiceImpl fallback, request timeout or RunException----------";
}
}
服务熔断
一、断路器：保险丝
二、熔断机制概述
熔断机制是对应雪崩的一种微服务链路保护机制。当扇出链路的某个微服务出错不可用或者响应时间太长时，会进行服务降级，进而熔断该节点微服务的调用，快速发返回错误的响应信息，当检测到该节点微服务调用响应正常后，恢复调用链路。在SpringCloud框架里，熔断机制 Hystrix 会监控微服务间调用的状况，当失败的调用到一定阀值，时间窗 5 秒内 20 次调用失败，就会启动熔断机制。熔断机制的注解是@HystrixCommand。
扩展：Hystrix配置服务降级、熔断注解的属性值来源于HystrixCommandProperties抽象类
@HystrixCommand(commandProperties = {
@HystrixProperty(name = "属性名", value = "属性值")
})
三、案例（实操）
1、修改 cloud-provider-hystrix-payment8001 的PaymentService 实现类
@Service
public class PaymentServiceImpl implements PaymentService {
/*======================= 服务熔断 =======================*/
@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 不能为负数");
}
String serialNumber = IdUtil.simpleUUID();
return Thread.currentThread().getName() + "\t" + "调用成功，流水号：" + serialNumber;
}
public String paymentCircuitBreaker_fallback(@PathVariable("id") Integer id) {
return " id 不能为负数，请稍后重试，哭脸 id：" + id;
}
}
2、修改 cloud-provider-hystrix-payment8001 的PaymentController.java
@RestController
@Slf4j
public class PaymentController {
@Resource
private PaymentService paymentService;
/*======================= 服务熔断 =======================*/
@GetMapping(value = "/payment/circuit/{id}")
public String paymentCircuitBreaker(@PathVariable("id") Integer id) {
String result = paymentService.paymentCircuitBreaker(id);
log.info("***result:${}" + result);
return result;
}
}
测试结果：输入负数，当失败率达到 60% 以上之后，当我们输入正数时，也会出现返回服务降级信息，多次错误,然后慢慢正确，发现刚开始不满足条件，就算是正确的访问地址也不能进行访问，需要慢慢的恢复链路。
3、客户端 cloud-consumer-feign-hystrix-order80 完整配置
（1）feign调用接口类：PaymentHystrixService.java
@Component
@FeignClient(value = "CLOUD-PROVIDER-HYSTRIX-PAYMENT", fallback = PaymentFallbackServiceImpl.class)
@DefaultProperties(
commandProperties = {
@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1500"),
@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 interface PaymentHystrixService {
/*======================= 服务熔断 =======================*/
@GetMapping(value = "/payment/hystrix/circuitbreaker/{id}")
public String paymentCircuitBreaker(@PathVariable("id") Integer id);
}
（2）feign调用接口实现类：PaymentHystrixServiceImpl.java
@Component
public class PaymentFallbackServiceImpl implements PaymentHystrixService {
@Override
public String paymentCircuitBreaker(Integer id) {
return "-------- PaymentFallbackServiceImpl circuit breaker ----------";
}
}
（3）controller层
@RestController
@Slf4j
public class OrderHystrixController {
@Resource
private PaymentHystrixService paymentHystrixService;
/*======================= 服务熔断 =======================*/
@GetMapping(value = "/consumer/hystrix/circuitbreaker/{id}")
public String paymentCircuitBreaker(@PathVariable("id") Integer id) {
String result = paymentHystrixService.paymentCircuitBreaker(id);
log.info("***result:{}" + result);
return result;
}
}
测试结果：输入负数，当失败率达到 60% 以上之后，当我们输入正数时，也会出现返回服务降级信息，多次错误,然后慢慢正确，发现刚开始不满足条件，就算是正确的访问地址也不能进行访问，需要慢慢的恢复链路。
结论：服务降级-->进而熔断-->恢复调用链路
四、服务熔断原理（总结）
1、服务熔断的原理结构图
This simple circuit breaker avoids making the protected call when the circuit is open, but would need an external intervention to reset it when things are well again. This is a reasonable approach with electrical circuit breakers in buildings, but for software circuit breakers we can have the breaker itself detect if the underlying calls are working again. We can implement this self-resetting behavior by trying the protected call again after a suitable interval, and resetting the breaker should it succeed.
译：这种简单的断路器避免在电路断开时发出受保护的呼叫，但需要外部干预，以便在情况恢复正常时将其复位。对于建筑物中的电气断路器，这是一种合理的方法，但对于软件断路器，我们可以让断路器本身检测底层调用是否再次工作。我们可以通过在适当的时间间隔后再次尝试受保护的调用，并在成功后重置断路器，来实现这种自重置行为。
2、熔断类型
（1）
熔断关闭：熔断关闭不会对服务熔断。
（2）熔断打开：请求不在进行调用当前服务，内部设置时钟一般为MTTR（平均故障处理时间），当打开时长达到所设置时钟则进入半熔断状态。
（3）熔断半开：部分请求根据规则条用当前服务，如果请求成功且符合规则，则认为当前服务恢复正常，关闭熔断。
3、Hystrix断路器在什么情况下起作用？
/*======================= 服务熔断 =======================*/ @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) { ...... }涉及到断路器的三个重要参数：
快照时间窗、请求总数阀值、错误百分比阀值。
（1）快照时间窗：断路器确定是否打开需要统计的一些请求和错误数据，而统计的时间范围就是快照时间窗，默认为最近的90 秒。
（2）请求总数阀值：在快找时间窗内，必须满足请求总数阀值才有资格熔断，默认为20次。意味着在时间范围内，如果该 hystrix 命令的调用次数不足20次，即使所有的请求都超时或其他原因失败，断路器都不会打开。（即：在时间快照窗内，请求超时或异常超过请求总数阀值，才会触发断路器）
（3）错误百分比阀值：当请求总数在快照时间窗内超过阀值，并且错误百分比满足其阀值才会熔断，默认为50%。
4、断路器打开之后，如何工作？
（1）断路器打开之后，再有请求调用的时候，将不会调用主逻辑，而是直接调用服务降级
fallback。通过断路器，实现了自动的发现异常或错误并将服务降级逻辑切换为主逻辑，减少响应延迟的效果。
（2）如何恢复原来的主逻辑？
对于这一问题，hystrix也为我们实现了自动恢复功能。当断路器打开，对主逻辑进行熔断之后，hystrix会启动一个休眠时间窗，在这个时间窗内，服务降级逻辑会替换主逻辑，当休眠时间窗到期，断路器也将进入半开状态，释放一次请求到原来的主逻辑上，如果此次请求正确返回，那么断路器将继续闭合，主逻辑恢复，如果这次请求依然有问题，断路器继续进入打开状态，休眠时间窗重新计时。
5、Hystrix 配置参数详解
官网地址：https://github.com/Netflix/Hystrix/wiki/Configuration
转发：https://www.cnblogs.com/zhenbianshu/p/9630167.html
服务限流（后续更新）
Hystrix 工作流程
Hystrix 工作流程：https://github.com/Netflix/Hystrix/wiki/How-it-Works
服务监控 HystrixDashboard
一、概述
除了隔离依赖服务的调用外，Hystrix 还提供了
准实时的调用监控（Hystrix Dashboard），Hystrix 会持续的记录所有通过Hystrix 发起的请求的执行信息，并以统计报表和图形的形式展示给用户，包括每秒执行多少请求、多少成功、多少失败等。Netflix 通过hystrix-metrics-event-stream项目实现了对以上指标的监控。SpringCloud也提供了Hystrix DashBoard的整合，对监控内容转化成可视化界面。
二、仪表盘9001
1、新建 cloud-consumer-hystrix-dashboard9001
2、引入 pom 依赖
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-netflix-hystrix-dashboardartifactId>
dependency>
3、yml 配置文件
server:
port: 9001
4、主启动类
@SpringBootApplication
//开启服务监控
@EnableHystrixDashboard
public class HystrixDashboardMain9001 {
public static void main(String[] args) {
SpringApplication.run(HystrixDashboardMain9001.class, args);
}
}
5、启动并打开浏览器 http://localhost:9001/hystrix
结果如下：
三、断路器演示
1、注意：新版本Hystrix需要在主被监控服务的启动类MainAppHystrix8001中指定监控路径
@SpringBootApplication
@EnableEurekaClient
@EnableCircuitBreaker
public class HystrixMainPayment8001 {
public static void main(String[] args) {
SpringApplication.run(HystrixMainPayment8001.class, args);
}
/*
此配置是为了服务监控而配置，与服务容错本身无关，springcloud 升级后的坑，
ServletRegistrationBean 因为 springboot 的默认路径不是 "/hystrix.stream"
只要在自己的项目里配置上下面的 servlet 就可以了
*/
@Bean
public ServletRegistrationBean<HystrixMetricsStreamServlet> getServlet() {
HystrixMetricsStreamServlet streamServlet = new HystrixMetricsStreamServlet();
ServletRegistrationBean<HystrixMetricsStreamServlet> registrationBean = new ServletRegistrationBean<>();
registrationBean.setServlet(streamServlet);
registrationBean.setLoadOnStartup(1);
registrationBean.addUrlMappings("/hystrix.stream");
registrationBean.setName("HystrixMetricsStreamServlet");
return registrationBean;
}
}
2、测试
（1）在监控面板中输入被监控的微服务地址
（2）测试地址
http://localhost/consumer/hystrix/circuitbreaker/10
http://localhost/consumer/hystrix/circuitbreaker/-10
3、服务监控图示解析（七色、一圈、一线）
（1）七色
（2）一圈
实心圆：共有两种含义。它通过颜色的变化代表了实例的健康程度，它的健康度从 绿色<黄色<橙色<红色 递减。
该实心圆除了颜色的变化之外，它的大小也会根据实例的请求流量发生变化，流量越大该实心圆就越大。所以通过该实心圆的展示，就可以在大量的实例中快速的发现故障实例和高压力实例。
（3）一线：请求访问频率。
整个图分析：
