Hystrix断路器
概述
分布式系统面临的问题
复杂的分布式体系结构中,应用程序可能会有有数十个依赖关系,每个依赖关系在某些时候将不可避免地会失败。
服务雪崩
多个微服务之间调用的时候,假设微服务A调用微服务B和微服务C,微服务B和微服务C又调用其它的微服务,这就是所谓的“扇出”。
如果扇出的链路上某个微服务的调用响应时间过长或者不可用,对微服务A的调用就会占用越来越多的系统资源,进而引起系统崩溃,这就是所谓的“雪崩效应”。
对于高流量的应用来说,单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败还糟糕的是,这些应用程序还
可能导致服务之间的延迟增加,备份队列,线程和其他系统资源紧张,导致整个系统发生更多的级联故障。这些都表示需要对故障和延
迟进行隔离和管理,以便单个依赖关系的失败,不能取消整个应用程序或系统。
所以,当一个模块下的某个实例失败后,这时候这个模块依然还会接收流量,然后这个有问题的模块还调用了其他的模块,这样就
会发生级联故障,或者叫雪崩。
Hystrix介绍
Hystrix是一个用于处理分布式系统的延迟和容错的开源库。
Hystrix的作用
在分布式系统里,许多依赖不可避免的会调用失败,比如超时、异常等,Hystrix能够保证在一个依赖出问题的情况下, 不会导致整体服务失败,避免级联故障,以提高分布式系统的弹性。
Hystrix的工作原理
“断路器”本身是一种开关装置, 当某个服务单元发生故障之后,通过断路器的故障监控(类似保险丝使家里跳闸、限电,家里就没电了,不至于发生火灾),向调用方返回一个符合预期的、可处理的备选响应(FallBack) ,而不是长时间的等待或者抛出调用方无法处理的异常,这样就保证了服务调用方的线程不会被长时间、不必要地占用,从而避免了故障在分布式系统中的蔓延,乃至雪崩。
Hystrix都有什么功能
服务降级、服务熔断、接近实时的监控、服务限流、服务隔离等等
Hystrix重要概念
服务降级(fallback)
服务降级就是指系统不可用了,向服务调用方返回一个符合预期的,可处理的备选响应。
通常是不让客户端等待并立刻返回一个友好提示。
哪些情况会发生降级
- 程序运行异常
- 超时
- 服务熔断
- 线程池/信号量打满
服务熔断(break)
就是保险丝的意思,通常指的是某一个服务在达到最大访问次数后,直接拒绝访问,然后调用服务降级的方法并返回友好提示。
一般过程:服务降级 -> 服务熔断 -> 恢复调用链路
熔断机制
熔断机制是应对雪崩效应的一种微服务链路保护机制。
- 当扇出链路的某个微服务出错不可用或者响应时间太长时,会进行服务的降级,进而熔断该节点微服务的调用,快速返回错误的响应信息。
- 当检测到该节点微服务调用响应正常后,恢复调用链路。
在Spring Cloud框架里,熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况,
当失败的调用到一定阈值,缺省是5秒内20次调用失败,就会启动熔断机制。熔断机制的注解是@HystrixCommand
熔断类型
熔断打开
- 请求不再进行调用当前服务,内部设置时钟一般为MTTR (平均故障处理时间),当打开时长达到所设时钟则进入半熔断状态
熔断关闭
- 熔断关闭不会对服务进行熔断
熔断半开
- 部分请求根据规则调用当前服务,如果请求成功且符合规则则认为当前服务恢复正常,关闭熔断
服务限流(flowlimit)
秒杀高并发等操作,严禁服务拥挤,需要挨个排队,一秒钟N个,有序进行
Hystrix案例
构建
1.先将7001的环境换成单机版
2.创建cloud-provider-hystrix-payment8001模块
3.创建pom
<!--hystrix-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>
<!--添加Eureka Client依赖-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
<!--再添加通用依赖-->
4.创建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 # 单机版
5.创建启动类
@SpringBootApplication
@EnableEurekaClient
public class PaymentHystrixMain8001{
public static void main(String[] args){
SpringApplication.run(PaymentHystrixMain8001.class , args);
}
}
6.创建service
package com.indi.springcloud.service;
@Service
public class PaymentService{
/**
* 直接返回信息
* @param id
* @return
*/
public String paymentInfo_OK(Integer id){
return "线程池:" + Thread.currentThread().getName() + "paymentInfo_OK," + " id:" + id + "^_^";
}
/**
* 等待3秒再返回信息
* @param id
* @return
*/
public String paymentInfo_TimeOut(Integer id){
int seconds = 3;
try{
TimeUnit.SECONDS.sleep(seconds);
}catch(InterruptedException e){
e.printStackTrace();
}
return "线程池:" + Thread.currentThread().getName() + "paymentInfo_OK," + " id:" + id + ",耗费(秒):"+ seconds + "^_^";
}
}
7.创建controller
package com.indi.springcloud.controller;
@RestController
@Slf4j
public class PaymentController{
@Resource
private PaymentService paymentService;
@Value("${server.port}")
private String serverPort;
@GetMapping(value = "/payment/hystrix/ok/{id}")
public String paymentInfo_OK(@PathVariable("id") Integer id){
String result = paymentService.paymentInfo_OK(id);
log.info("******" + result);
return result;
}
@GetMapping(value = "/payment/hystrix/timeout/{id}")
public String paymentInfo_TimeOut(@PathVariable("id") Integer id){
String result = paymentService.paymentInfo_TimeOut(id);
log.info("******" + result);
return result;
}
}
8.测试
JMeter高并发测试
环境
我们创建20000个线程去访问之前写的延时接口
结论
结果我们发现当线程多的时候,原来秒加载的请求开始等待了,有等待的请求等的时间更长了。
主要是因为我们使用20000个线程去访问那个延时的接口,瞬间就会把tomcat里面的线程用尽,而tomcat因为默认工作线程数被打满,根本就没有多余的线程来分解压力和处理,此时就会把该微服务的资源全部集中过去处理延时接口,从而导致正常的接口资源不够,出现卡顿的现象。
这还是服务提供者8001自己测试,假如此时外部的消费者80也来访问,那消费者只能干等,最终导致消费端80不满意,服务端8001直接被拖死。
添加消费者模块
1.新建cloud-consumer-feign-hystrix-order80
2.创建pom
<!--openfeign-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>
<!--hystrix-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>
<!--添加Eureka Client依赖-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
3.创建yml
server:
port: 80
eureka:
client:
# 表示是否将自己注册进EurekaServer,默认为true。
register-with-eureka: false
service-url:
defaultZone: http://localhost:7001/eureka # 单机版
4.创建启动类
@SpringBootApplication
@EnableFeignClients
public class OrderHystrixMain80 {
public static void main(String[] args) {
SpringApplication.run(OrderHystrixMain80.class, args);
}
}
5.创建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_TimeOut(@PathVariable("id") Integer id);
}
6.创建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);
log.info("*****" + result);
return result;
}
@GetMapping("/consumer/payment/hystrix/timeout/{id}")
public String paymentInfo_TimeOut(@PathVariable("id") Integer id){
String result = paymentHystrixService.paymentInfo_TimeOut(id);
log.info("*****" + result);
return result;
}
}
7.测试
正常测试80的秒加载模块,没有问题,不需要等待。
开启上述的JMeter高并发测试,2W个线程压8001,再测试消费者80的秒加载模块,就出现等待的情况了。
如果再同时测试8001的秒加载请求、以及8001的有等待时间的请求,就会出现下面的情况,消费者模块报超时错误。
如何解决上述的问题?
超时导致服务器变慢(转圈):让超时不再等待
出错(宕机或程序运行出错):出错要有兜底
解决:
- 对方服务(8001)超时了,调用者(80)不能一直卡死等待,必须要有服务降级
- 对方服务(8001)down机了,调用者(80)不能一直卡死等待,必须要有服务降级
- 对方服务(8001)OK,调用者(80)自己出故障或有自我要求(自己的等待时间小于服务提供者),自己处理降级
服务降级
降级配置
@HystrixCommon
8001先从自身找问题
设置8001自身调用超时时间的峰值,峰值内可以正常运行,超过了需要有兜底的方法处理,作为服务降级fallback。
8001服务降级
主启动类
PaymentHystrixMain8001.java
controller
PaymenHystrixController.java
测试
80服务降级
修改yml
feign:
hystrix:
# 开启消费者模块的容错
enabled: true
主启动类
OrderHystrixMain80.java
controller
OrderHystrixController.java
测试
全局服务降级
上述的方法会产生一些问题:
- 每个业务方法配置一个fallback方法,代码冗余较多
- 和业务逻辑混在一起,代码耦合度较高
冗余的解决办法
除了个别重要核心业务,需要单独设置fallback以外,其它普通的业务可以通过@DefaultProperties(defaultFallback = "")
跳转到默认的处理结果页面
具体实现
测试
耦合度的解决办法
与其在controller层为每个方法都提供一个fallback,难以解耦,不如直接针对controller层上面的service,对service接口下的的所有微服务都做一个统一的降级处理。
因为只要使用Feign调用微服务,一定会使用FeignClient
,而FeignClient
中会有一些方法的定义,我们针对FeignClient
这个接口下的全部方法统一的进行降级处理,这样就可以达到解耦的目的。
具体实现
service
PaymentFallbackService.java
@Component
public class PaymentFallbackService implements PaymentHystrixService{
@Override
public String paymentInfo_OK(Integer id){
return "消费端:服务器已宕机,请稍后重试";
}
@Override
public String paymentInfo_TimeOut(Integer id){
return "消费端:服务器已宕机,请稍后重试";
}
}
添加注解实现
PaymentHystrixService.java
@FeignClient(value = "CLOUD-PROVIDER-HYSTRIX-PAYMENT" , fallback = PaymentFallbackService.class)
测试
服务熔断
执行流程
断路器的打开和关闭是按照以下这5部来完成的
- 先查看请求次数有没有达到预期值:
requestVolumeThreshold
- 再查看错误百分比达到了多少:
errorThresholdPercentage
- 满足上述条件之后将会把断路器设置为OPEN开启状态
- 当它打开之后,所有的请求都将无法使用
- 在一定的时间范围内:
sleepWindowInMilliseconds
,如果遇到下一个请求,尝试着让它通过一下,将断路器设置成所谓的HALF-OPEN半开状态,如果这个请求还是不行,则说明还没恢复,断路器则依旧设置为OPEN开启状态,如果这个请求通过了,则说明服务已经恢复了,则将断路器设置为CLOSE关闭状态。
具体配置
修改cloud-provider-hystrix-payment8001模块
1.Service
修改PaymentService.java
/**
* 服务熔断:手动抛出异常,测试回调方法
*
* @param id
* @return
*/
@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 serialNum = IdUtil.simpleUUID(); // 等价于UUID.randomUUID().toString()
return Thread.currentThread().getName() + "\t" + "调用成功:流水号:" + serialNum;
}
/**
* 服务熔断:回调方法
*
* @param id
* @return
*/
public String paymentCircuitBreaker_fallback(@PathVariable("id") Integer id) {
return "id 不能负数,请稍候再试";
}
2.Service
修改PaymentController.java
@GetMapping("/payment/circuit/{id}")
public String paymentCircuitBreaker(@PathVariable("id") Integer id){
String result = paymentService.paymentCircuitBreaker(id);
log.info("*****" + result);
return result;
}
测试
正常测试
成功
熔断测试
连续测试10次以上负数的情况,然后再测试正数,我们发现此时正数的情况也不正常了
但是再测试几次正数之后,发现起初还是错误,但是慢慢就恢复正常了
总结
涉及到断路器的三个重要参数
- 快照时间窗:断路器确定是否打开需要统计一些请求和错误数据,而统计的时间范围就是快照时间窗,默认为最近的10秒。
- 请求总数阈值:在快照时间窗口内,必须满足请求总数阈值才有资格熔断。默认为20,意味着在10秒内,如果hystrix的调用总次数不足20次,即使所有请求都超时或者其他原因失败,断路器都不会打开。
- 错误百分比阈值:当请求总数在快照时间窗内超过了阈值,比如发生了30次调用,并且有15次发生了超时异常,也就是超过了50的错误百分比,在默认设定的50%阈值情况下,这时候就会将断路器打开。
断路器开启或关闭的条件
- 当满足一定阈值的时候(默认10秒内超过20个请求)
- 当失败率达到一定的时候(默认10秒内超过50%的请求失败)
- 到达以上阈值,断路器将会开启
- 当开启的时候,所有请求都不会进行转发
- 一段时间之后(默认是5秒),这个时候断路器是半开状态,会让其中一个请求进行转发。如果成功,断路器会关闭,若失败,继续开启,重复4和5
断路器开启后
- 再有请求调用的时候,将不会调用主逻辑,而是直接调用降级fallback,通过断路器,实现了自动的发现错误并将降级逻辑切换为主逻辑,减少相应延迟的效果。
原来的主逻辑如何恢复?
- 对于这个问题,Hystrix实现了自动恢复功能,当断路器打开,对主逻辑进行熔断之后,hystrix会启动一个休眠时间窗,在这个时间窗内,降级逻辑会临时的成为主逻辑,当休眠时间窗到期,断路器将进入半开状态,释放一次请求到原来的主逻辑上,如果此次请求正常返回,断路器将继续闭合,主逻辑恢复,如果这次请求依然有问题,断路器继续保持打开状态,休眠时间窗重新计时。
全部的配置
@HystrixCommand(fallbackMethod = "str_fallbackMethod" ,
groupKey = "strGroupCommand" ,
commandKey = " strCommard",
threadPoolKey = "strThreadPool",
commandProperties = {
// 设置隔离策略,THREAD 表示线程池SEMAPHORE: 信号池隔离
@HystrixProperty(name = "execution.isolation.strategy", value = "THREAD"),
// 当隔离策略选择信号池隔离的时候,用来没置信号池的大小(最大并发数)
@HystrixProperty(name = "execution.isolation.semaphore.maxConcurrentRequests", value = "10"),
// 配置命令执行的超时时间
@HystrixProperty(name ="execution.isolation.thread.timeoutinMilliseconds", value = "10"),
// 是否启用超时时间
@HystrixProperty(name = "execution.timeout.enabled", value = "true"),
// 执行超时的时候是否中断
@HystrixProperty(name = "execution.isolation.thread.interruptOnTimeout", value = "true"),
// 执行被取消的时候是否中断
@HystrixProperty(name = "execution.isolation.thread.interruptOnCancel", value = "true"),
// 允许回调方法执行的最大并发数
@HystrixProperty(name = "fallback.isolation.semaphore.maxConcurrentRequests", value = "10"),
// 服务降级是否启用,是否执行回调函数
@HystrixProperty(name = "fallback.enabled", value = "true"),
// 是否启用断路器
@HystrixProperty(name = "circuitBreaker.enabled", value = "true"),
// 该属性用来设置在滚动时间窗中,断路器熔断的最小请求数。例如,默认该值为20的时候,
// 如果滚动时间窗(默认10秒)内仅收到了19个请求, 即使这19个请求都失败了,断路器也不会打开。
@HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "20"),
// 该属性用来没置在演动时间窗中,表示在滚动时间窗中,在请求数量超过
// circuitBreake.requestVolumeThreshold的情况下,如果错误请求数的百分比超过50,
// 就把断路器没置为”打开”状态,否则就设置为"关闭”状态。
@HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value = "50"),
// 该属性用来没置当断路器打开之后的休眠时间窗。休眠时间窗结束之后,
// 会将断路器置为"半开”状态,尝试熔断的请求命令,如果依然失败就将断路器继续设置为”打开”状态,
// 如果成功就设置为"关闭”状态。
@HystrixProperty(name = "circuitBreaker.sleepWindowinMilliseconds", value = "5000"),
// 断路器强制打开
@HystrixProperty(name = "circuitBreaker.forceOpen", value = "false"),
// 断路器强制关闭
@HystrixProperty(name = "circuitBreaker.forceClosed", value = "false"),
// 滚动时间窗设置,该时间用于断路器判断健康度时需要收集信息的持续时间
@HystrixProperty(name = "metrics.rollingStats.timeinMilliseconds", value = "10000"),
// 该属性用来设置熔动时间窗统计指标信息时划分”桶"的数量,断路器在收集指标信息的时候会根据
// 设置的时间窗长度拆分成多个"桶"来累计各度量值,每个”桶"记录了-段时间内 的采集指标。
// 比如10秒内拆分成10个”桶"收集这样,所以timeinMilliseconds 必须能被numBuckets 整除。否则会抛异常
@HystrixProperty(name = "metrics.rollingStats.numBuckets", value = "10"),
//该属性用来没置对命令执行的延迟是否使用百分位数来跟踪和计算。如果设置为false, 那么所有的概要统计都将返回-1。
@HystrixProperty(name = "metrics.rollingPercentile.enabled", value = "false"),
//该属性用来没置百分位统计的滚动窗口的持续时间,单位为毫秒。
@HystrixProperty(name = "metrics.rolingPercentile.timeInMiliseconds", value = "60000"),
//该属性用来没置百分位统计演动窗口中使用“桶”的数量。
@HystrixProperty(name = "metrics.rollingPercenthle.numBuckets", value = "60000"),
// 该属性用来没置在执行过程中每个“桶”中保留的最大执行次数。如果在演动时间窗内发生超过该设定值的执行次数,
// 就从最初的位置开始重写。例如,将该值设置为100,熔动窗口为10秒,若在10秒内一个“桶”中发生了500次执行,
// 那么该“桶”中只保留最后的100次执行的统计。另外,增加该值的大小将会增加内存量的消耗,并增加排序百分位数所需的计算时间。
@HystrixProperty(name = "metrics.rollingPercentile.bucketSize", value = "100"),
// 该属性用来没置采集影响断路器状态的健康快照(请求的成功、错误百分比) 的间隔等待时间。
@HystrixProperty(name = "metrics.healthSnapshot.intervalinMilliseconds", value = "500"),
// 是否开启请求缓存
@HystrixProperty(name = "requestCache.enabled", value = "true"),
// HystrixCommand的执行和事件是否打印日志到HystrixRequestLog中
@HystrixProperty(name = "requestLog.enabled", value = "true"),
// 该属性用来汝置采集影响断路器状态的健康快照(请求的成功、错误百分比)的间隔等待时间。
@HystrixProperty(name = "metrics.healthSnapshot.intervalinMilliseconds", value = "500"),
// HystrixCommand的执行和事件是否打印日志到HystrixRequestLog中
@HystrixProperty(name = "requestLog.enabled", value = "true")
},
threadPoolProperties = {
// 该参数用来没置执行命令线程池的核心线程数,该值也就是命令执行的最大并发量
@HystrixProperty(name = "coreSize", value = "10"),
// 该参数用来没置线程池的最大队列大小。当设置为-1 时,线程地将使用SynchronousQueue实现的队列,
// 否则将使用LinkedBlockingQueue 实现的队列。
@HystrixProperty(name = "maxQueueSize", value = "-1"),
// 该参数用来为队列没置拒绝阙值。通过该参数, 即使队列没 有达到最大值也能拒绝请求。
// 该参数主要是对LinkedBlockingQueue队列的补充,因为LinkedBlockingQueue
// 队列不能动态修改它的对象大小,而通过该属性就可以调整拒绝请求的队列大小了。
@HystrixProperty(name = "queueSizeRejectionThreshold", value = "5")
}
)
Hystrix工作流程
蓝色:调用路径
红色:返回路径
简述版
- 选择一个Hystrix注册方式
- 二选一即可
- 判断缓存中是否包含需要返回的内容(如果有直接返回)
- 断路器是否为打开状态(如果是,直接跳转到8,返回)
- 断路器为健康状态,判断是否有可用资源(没有,直接跳转8)
- 构造方法和
Run()
方法 - 将正常,超时,异常的消息发送给断路器
- 调用
getFallback()
方法,也就是服务降级 - 直接返回正确结果
完整版
序号 | 描述 |
---|---|
1 | 创建HystrixConmand(用在依赖的服务返回单个操作结果的时候)或 HystrixObserableCommand(用在依赖的服务返回多个操作结果的时候)对象。 |
2 | 命令执行。其中HystrixComand实现了下面前两种执行方式:而HystrixObservableCommand实现了后两种执行方式:execute() :同步执行,从依赖的服务返回一个单一的结果对象, 或是在发生错误的时候抛出异常。queue() :异步执行,直接返回一个Future对象,其中包含了服务执行结束时要返回的单一结果对象。observe() :返回Observable对象,它代表了操作的多个结果,它是一个Hot Obserable(不论“事件源” 是否有 “订阅者”,都会在创建后对事件进行发布,所以对于Hot Observable的每一个“订阅者”都有可能是从“事件源”的中途开始的,并可能只是看到了整个操作的局部过程) toObservable() :同样会返回Observable对象,也代表了操作的多个结果,但它返回的是个Cold Observable(没有“订阅者”的时候并不会发布事件,而是进行等待,直到有“订阅者”之后才发布事件,所以对于Cold Observable的订阅者,它可以保证从开始看到整个操作的全部过程) |
3 | 若当前命令的请求缓存功能是被启用的,并且该命令缓存命中, 那么缓存的结果会立即以Observable对象的形式返回。 |
4 | 检查断路器是否为打开状态。如果断路器是打开的,那么Hystrix不会执行命令, 而是转接到 fallback 处理逻辑(第8步);如果断路器是关闭的,检查是否有可用资源来执行命令(第5步) |
5 | 线程池/请求队列/信号量是否占满。如果命令依赖服务的专有线程池和请求队列,或者信号量(不使用线程池的时候)已经被占满,那么Hystrix也不会执行命令,而是转接到fallback处理逻辑(第8步)) |
6 | Hystrix 会根据我们编写的方法来决定采取什么样的方式去请求依赖服务。HystrixCommand.run() : 返回一个单一的结果, 或者抛出异常。HystrixObservableCommand.construct() : 返回一个Observable 对象来发射多个结果,或通过onError() 发送错误通知。 |
7 | Hystrix会将“成功”、“失败”、 “拒绝”、 “超时” 等信息报告洽断路器,而断路器会维护一组计数器来统计这些数据。 断路器会使用这些统计数据来决定是否要将断路器打开,来对某个依赖服务的请求进行“熔断/短路”。 |
8 | 当命令执行失败的时候,Hystrix 会进入fallback尝试回退处理,我们通常也称该操作为 “服务降级”。而能够引起服务降级处理的情况有下面几种: 第4步:当前命令处于 “熔断/短路”状态,断路器是打开的时候。 第5步:当前命令的线程池、 请求队列或 者信号量被占满的时候。 第6步: HystrixObservableCommand.construct() 或HystrixCommand.run() 抛出异常的时候。 |
9 | 当Hystrix命令执行成功之后,它会将处理结果直接返回或是以Observable 的形式返回。 |
tips:如果我们没有为命令实现降级逻辑或者在降级逻辑中抛出了异常,Hystrix 依然会返回一个Observable对象,但是它不会发射任何结果数据,而是通过onError()
方法通知命令立即中断请求,并通过onError()
方法将引起命令失败的异常发送给调用者.
Hystrix图形化Dashboard
概述
除了隔离依赖服务的调用以外,Hystrix还提供了准实时的调用监控(Hystrix Dashboard),Hystrix会持续地记录所有通过Hystrix发起的请求的执行信息,并以统计报表和图形化的形式展示给用户,包括每秒执行多少请求,成功多少请求,失败多少,Netflix通过Hystrix-metrics-event-stream项目实现了对以上指标的监控,Spring Cloud也提供了HystrixDashboard整合,对监控内容转化成可视化页面
搭建
1.创建cloud-consumer-hystrix-dashboard9001模块
2.创建pom
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>
</dependency>
<!--再加boot web actuator-->
<!--再加通用配置-->
3.创建yml
tips:63集里有详细解释怎么关联文件,恢复idea对yml的识别,如果idea一旦不识别yml了,可以照着改一下。
4.给其他微服务添加依赖
所有Provider微服务提供类(8001/8002/8003)都需要添加监控的依赖,(我的项目里面一般都配了)
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
5.为其它微服务添加代码
/**
* 这是Spring Cloud升级之后会产生的一个Bug,以下是解决方案,直接使用即可。
* @return
*/
@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;
}
9001监控8001
在豪猪哥下面,填写监控地址:http://localhost:8001/hystrix.stream
测试地址
http://localhost:8001/payment/circuit/1
http://localhost:8001/payment/circuit/-1
先测试通过,然后先访问正确地址,再访问错误地址,再正确地址,会发现9001里面的断路器都是慢慢放开的
如何看
7色
1圆
实心圆:共有两种含义。它通过颜色的变化代表了实例的健康程度,它的健康度:绿色<黄色<橙色<红色依次递减。
实心圆除了颜色的变化之外,它的大小也会根据实例的请求流量发生变化,流量越大该实心圆就越大。所以通过该实心圆的展示,就
可以在大量的实例中快速的发现故障实例和高压力实例。
1线
曲线:用于记录2分钟内流量的相对变化,可以通过它来观察到流量的上升和下降趋势
整图说明