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 + " " + "哈~";
}
/**模拟出错的方法*/
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 + " " + "哈~ "
+ "耗时" + 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 服务,线程组配置参数如下:
![image-20210227003830057](https://gitee.com/mp2333/blog-img/raw/master/SpringCloud/20210227004158.png)
然后我们用该线程组发送HTTP请求给 TO 服务,创建如下的HTTP请求进行压力测试:
![image-20210227004313624](https://gitee.com/mp2333/blog-img/raw/master/SpringCloud/20210227004313.png)
我们观察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 服务进行访问,再进行压力测试,和之前一样,无法迅速访问该服务,如果压力测试中的线程数更多的时候,很可能会造成超时错误,出现以下错误提示:
![image-20210227202938314](https://gitee.com/mp2333/blog-img/raw/master/SpringCloud/20210227204622.png)
故障原因: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 + " " + "哈~";
}
/**模拟出错的方法*/
@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 + " " + "哈~ "
+ "耗时" + timeNumber + "s";
}
/** 定制服务降级方法*/
public String paymentInfo_FailHandler(Integer id) {
return "系统忙,请稍后再试";
}
}
然后在主启动类上添加 @EnableCircuitBreaker
注解对熔断器进行激活,TO服务的访问时间5秒,而我们用Hystrix配置的时间峰值为3秒,也就是当服务超时或服务出错时,会访问我们设置的fallbackMethod服务降级方法,再次访问TO服务,我们发现其执行的方法确实为服务降级方法:
![image-20210227234449381](https://gitee.com/mp2333/blog-img/raw/master/SpringCloud/20210227234449.png)
注意:我们自己配置过的热部署方式对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。
![image-20210228140850191](https://gitee.com/mp2333/blog-img/raw/master/SpringCloud/20210228140850.png)
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 总结
![image-20210228142306949](https://gitee.com/mp2333/blog-img/raw/master/SpringCloud/20210228142307.png)
结合官网中对熔断机制的描述,其熔断过程可以如下描述:
熔断器打开和关闭的精确方式如下:
- 假设电路上的访问达到某个阈值(
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所有常用配置
![image-20210228161057425](https://gitee.com/mp2333/blog-img/raw/master/SpringCloud/20210228161057.png)
![image-20210228161128573](https://gitee.com/mp2333/blog-img/raw/master/SpringCloud/20210228161128.png)
服务限流在Alibaba的Sentinel框架中会详解
5. Hystrix工作流程
整体的Hystrix工作流程图入下:
![20200522001442973](https://gitee.com/mp2333/blog-img/raw/master/SpringCloud/20210227205657.png)
步骤说明:
![image-20210228160554789](https://gitee.com/mp2333/blog-img/raw/master/SpringCloud/20210228160555.png)
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的图形化界面中输入要监控的服务提供者:
![image-20210228154411594](https://gitee.com/mp2333/blog-img/raw/master/SpringCloud/20210228154411.png)
下面就是Dashboard对服务的监控状态:
![image-20210228154635386](https://gitee.com/mp2333/blog-img/raw/master/SpringCloud/20210228154635.png)
如何看?
- 七色
- 一圈 实现圆共有两种含义。它通过颜色的变化代表了实例的健康程度,它的健康度从绿色<黄色<橙色<红色递减。该实心圆除了颜色的变化之外,它的大小也会根据实例的请求流量发生变化,流量越大该实心圆也就越大。所以通过该实心圆的展示,就可以在大量的实例中快速的发现 故障实例和高压力实例。
- 一线 曲线用来记录2分钟内流量的相对变化,可以通过它来观察到流量的上升和下降趋势
- 整图说明1
![image-20210228155330038](https://gitee.com/mp2333/blog-img/raw/master/SpringCloud/20210228155330.png)
- 整图说明2
![image-20210228155431090](https://gitee.com/mp2333/blog-img/raw/master/SpringCloud/20210228155431.png)
- 一些复杂的情况
![image-20210228155537514](https://gitee.com/mp2333/blog-img/raw/master/SpringCloud/20210228155537.png)