我们在使用分布式系统的时候总会面临着一个问题
数十个的依赖关系,有时候会不可避免的出错,
而多个接口调用一个服务有一个挂了,就会导致整个调用的接口无法使用
我们称这个为:服务雪崩
服务雪崩
多个微服务之间调用的时候,假设微服务A调用微服务B和微服务C,微服务B和微服务C又调用其它的微服务,这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用,对微服务A的调用就会占用越来越多的系统资源,进而引起系统崩溃,所谓的“雪崩效应”. 对于高流量的应用来说,单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的是,这些应用程序还可能导致服务之间的延迟增加,备份队列,线程和其他系统资源紧张,导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理,以便单个依赖关系的失败,不能取消整个应用程序或系统。 所以,通常当你发现一个模块下的某个实例失败后,这时候这个模块依然还会接收流量,然后这个有问题的模块还调用了其他的模块,这样就会发生级联故障,或者叫雪崩。
Hystrix是一个用于处理分布式系统的延迟和容错的开源库,在分布式系统里,许多依赖不可避免的会调用失败,比如超时、异常等,Hystrix能够保证在一个依赖出问题的情况下,不会导致整体服务失败,避免级联故障,以提高分布式系统的弹性。 "断路器”本身是一种开关装置,当某个服务单元发生故障之后,通过断路器的故障监控(类似熔断保险丝),向调用方返回一个符合预期的、可处理的备选响应(FallBack),而不是长时间的等待或者抛出调用方无法处理的异常,这样就保证了服务调用方的线程不会被长时间、不必要地占用,从而避免了故障在分布式系统中的蔓延,乃至雪崩。
讲了这么多他能解决什么呢?
官网连接:https://github.com/Netflix/Hystrix/wiki/How-To-Use
然而这么好的东西 : Hystrix官宣,停更进维
为了后面新的学习,我们需要理解思想,主要学习思想
服务降级fallback
服务器忙,请稍候再试,不让客户端等待并立刻返回一个友好提示,fallback方法
要是让客户端看到这个
哪些情况会触发降级:
不太好
我们可以在服务器出问题的时候编写兜底方法,如果服务出问题,有一个兜底,调用友好提示
服务熔断机制
类比保险丝达到最大服务访问后,直接拒绝访问,拉闸限电,然后调用服务降级的方法并返回友好提示
服务的降级->进而熔断->恢复调用链路
最核心的是可以重启服务
他就是类似一个机制,如果服务器出现触发机制的问题,停止服务,调用服务降级,尝试恢复服务
服务限流flowlimit(这里我暂时没有实践,等到Alibaba的版本的时候在使用)
秒杀高并发等操作,严禁一窝蜂的过来拥挤,大家排队,一秒钟N个,有序进行
新建项目cloud-provider-hystrix-payment8001
导入核心依赖
<dependencies>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-netflix-hystrixartifactId>
dependency>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-netflix-eureka-clientartifactId>
dependency>
<dependency>
<groupId>com.atguigu.springcloudgroupId>
<artifactId>cloud-api-commonsartifactId>
<version>${project.version}version>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-webartifactId>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-actuatorartifactId>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-devtoolsartifactId>
<scope>runtimescope>
<optional>trueoptional>
dependency>
<dependency>
<groupId>org.projectlombokgroupId>
<artifactId>lombokartifactId>
<optional>trueoptional>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-testartifactId>
<scope>testscope>
dependency>
dependencies>
yml配置
server:
port: 8001
eureka:
client:
register-with-eureka: true #表识不向注册中心注册自己
fetch-registry: true #表示自己就是注册中心,职责是维护服务实例,并不需要去检索服务
service-url:
# defaultZone: http://eureka7002.com:7002/eureka/ #设置与eureka server交互的地址查询服务和注册服务都需要依赖这个地址
defaultZone: http://eureka7001.com:7001/eureka/
# server:
# enable-self-preservation: false
spring:
application:
name: cloud-provider-hystrix-payment
# eviction-interval-timer-in-ms: 2000
编写主启动类
@SpringBootApplication
@EnableEurekaClient
public class PaymentHystrixMain8001 {
public static void main(String[] args) {
SpringApplication.run(PaymentHystrixMain8001.class,args);
}
}
之后编写服务(这里我们直接使用实现类)
@Service
public class PaymentService {
//成功
public String paymentInfo_OK(Integer id){
return "线程池:"+Thread.currentThread().getName()+" paymentInfo_OK,id: "+id+"\t"+"哈哈哈" ;
}
//失败
public String paymentInfo_TimeOut(Integer id){
int timeNumber = 3;
try { TimeUnit.SECONDS.sleep(timeNumber); }catch (Exception e) {e.printStackTrace();}
return "线程池:"+Thread.currentThread().getName()+" paymentInfo_TimeOut,id: "+id+"\t"+"呜呜呜"+" 耗时(秒)"+timeNumber;
}
}
编写控制层
@RestController
@Slf4j
public class PaymentController {
@Resource
private PaymentService paymentService;
@Value("${server.port}")
private String serverPort;
@GetMapping("/payment/hystrix/ok/{id}")
public String paymentInfo_OK(@PathVariable("id") Integer id){
String result = paymentService.paymentInfo_OK(id);
log.info("*******result:"+result);
return result;
}
@GetMapping("/payment/hystrix/timeout/{id}")
public String paymentInfo_TimeOut(@PathVariable("id") Integer id){
String result = paymentService.paymentInfo_TimeOut(id);
log.info("*******result:"+result);
return result;
}
}
之后启动测试方法
两个方法都OK
带入场景
开启Jmeter,来20000个并发压死8001,20000个请求都去访问paymentInfo_TimeOut服务
这个时候我们再次访问的时候哪怕是第一个方法也会出现转圈加载的情况
为什么会被卡死?
因为tomcat的默认的工作线程数被打满了,没有多余的线程来分解压力和处理。
上面还是服务提供者8001自己测试,
假如此时外部的消费者80也来访问,那消费者只能干等,最终导致消费端80不满意,服务端8001直接被拖死
以上还只是服务提供者的自测,这个时候我们就需要使用 hystrix的时候
我们一般使用在服务端,客户端也可以做两重保险
看热闹不嫌事情大,这个时候我们加入客户端,来更接近真实业务
新建模块cloud-consumer-feign-hystrix-order80
导入依赖
<dependencies>
<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>
<dependency>
<groupId>com.atguigu.springcloudgroupId>
<artifactId>cloud-api-commonsartifactId>
<version>${project.version}version>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-webartifactId>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-actuatorartifactId>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-devtoolsartifactId>
<scope>runtimescope>
<optional>trueoptional>
dependency>
<dependency>
<groupId>org.projectlombokgroupId>
<artifactId>lombokartifactId>
<optional>trueoptional>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-testartifactId>
<scope>testscope>
dependency>
dependencies>
配置yml
server
port: 80
eureka:
client:
register-with-eureka: true #表识不向注册中心注册自己
fetch-registry: true #表示自己就是注册中心,职责是维护服务实例,并不需要去检索服务
service-url:
defaultZone: http://eureka7001.com:7001/eureka/
spring:
application:
name: cloud-provider-hystrix-order
主启动类
@SpringBootApplication
@EnableEurekaClient
public class PaymentHystrixMain8001 {
public static void main(String[] args) {
SpringApplication.run(PaymentHystrixMain8001.class,args);
}
}
package com.atguigu.springcloud;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.openfeign.EnableFeignClients;
@SpringBootApplication
@EnableFeignClients
public class OrderHystrixMain80 {
public static void main(String[] args) {
SpringApplication.run(OrderHystrixMain80.class,args);
}
}
服务接口
package com.atguigu.springcloud.service;
import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.stereotype.Component;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
@Component
@FeignClient(value = "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);
}
controller接口
@RestController
@Slf4j
public class OrderHystrixController {
@Resource
private PaymentHystrixService paymentHystrixService;
@Value("${server.port}")
private String serverPort;
@GetMapping("/consumer/payment/hystrix/ok/{id}")
public String paymentInfo_OK(@PathVariable("id") Integer id){
String result = paymentHystrixService.paymentInfo_OK(id);
log.info("*******result:"+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:"+result);
return result;
}
}
之后测试
再高并发场景下会出现什么情况
此时的80访问有两种情况
为什么会出现上述情况呢?
正因为有上述故障或不佳表现,才有我们的降级/容错/限流等技术诞生
如何解决?解决的要求
这个时候我们的问题有了解决方案
解决:
有了方案呢我们可以去执行
设置自身调用超时时间的峰值,峰值内可以正常运行,超过了需要有兜底的方法处理,作服务降级fallback
业务类启用 我们需要使用到Hystrix的注解
@HystrixCommand报异常后如何处理
: 一旦调用服务方法失败并抛出了错误信息后,会自动调用@HystrixCommand标注好的fallbackMethod调用类中的指定方法
老规矩用了新的组件
主启动类就要激活
添加新注解@EnableCircuitBreaker
此时的主启动类
@SpringBootApplication
@EnableEurekaClient
@EnableCircuitBreaker
public class paymentHystrix8001 {
public static void main(String[] args) {
SpringApplication.run(paymentHystrix8001.class,args);
}
}
80订单微服务,也可以更好的保护自己,自己也依样画葫芦进行客户端降级保护
配置yml
feign:
hystrix:
enabled: true #如果处理自身的容错就开启。开启方式与生产端不一样。
主启动
@SpringBootApplication
@EnableFeignClients
@EnableHystrix
public class feignHystrixMain80 {
public static void main(String[] args) {
SpringApplication.run(feignHystrixMain80.class,args);
}
}
业务类
@GetMapping("/consumer/payment/hystrix/timeout/{id}")
@HystrixCommand(fallbackMethod = "paymentTimeOutFallbackMethod",commandProperties = {
@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "1500") //3秒钟以内就是正常的业务逻辑
})
public String paymentInfo_TimeOut(@PathVariable("id") Integer id){
String result = paymentHystrixService.paymentInfo_TimeOut(id);
return result;
}
//兜底方法
public String paymentTimeOutFallbackMethod(@PathVariable("id") Integer id){
return "我是消费者80,对付支付系统繁忙请10秒钟后再试或者自己运行出错请检查自己,(┬_┬)";
}
解决了服务兜底的问题,我们这个时候审视场景,会发现,如果每个方法都有一个兜底那是不是太膨胀了
于是乎我们需要一套公用的兜底方案,个别案例再去用一对一兜底
新注解:@DefaultProperties(defaultFallback = "")
接下来就是80Controller的改变
我们在思考一下,还能不能再优化?
本次案例服务降级处理是在客户端80实现完成的,与服务端8001没有关系,只需要为Feign客户端定义的接口添加一个服务降级处理的实现类即可实现解耦
我们只需要将统一的兜底方法抽象出来,和业务代码分离,就可以解决客户端,混乱的问题, 业务就只关心业务,兜底就专门负责兜底.
接下来
根据cloud-consumer-feign-hystrix-order80已经有的PaymentHystrixService接口,重新新建一个类(PaymentFallbackService)实现该接口,统一为接口里面的方法进行异常处理
package com.atguigu.springcloud.service;
import org.springframework.stereotype.Component;
@Component
public class PaymentFallbackService implements PaymentHystrixService {
@Override
public String paymentInfo_OK(Integer id) {
return "-----PaymentFallbackService fall back-paymentInfo_OK , (┬_┬)";
}
@Override
public String paymentInfo_TimeOut(Integer id) {
return "-----PaymentFallbackService fall back-paymentInfo_TimeOut , (┬_┬)";
}
}
使用fegin的好处就来了
fegin里集成了fegin于是乎我们可以这样来改建我们的80服务接口
fallback = PaymentFallbackService.class
设置参数指向我们的兜底类
@Component
@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_TimeOut(@PathVariable("id") Integer id);
}
测试:
到这里我们就解决了有关客户端和服务端两方面的服务降级解决方案
其实,服务熔断就是一种调用机制,
他来判断什么时候触发服务熔断,达到触发雕件,就暂停服务的使用,调用服务降级,和并且在一定时间或者是其他条件的完成尝试重启服务
马丁福勒提出的理论:https://martinfowler.com/bliki/CircuitBreaker.html
修改业务类cloud-provider-hystrix-payment8001
//服务熔断
@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;
}
CONTROLLER编写
//===服务熔断
@GetMapping("/payment/circuit/{id}")
public String paymentCircuitBreaker(@PathVariable("id") Integer id){
String result = paymentService.paymentCircuitBreaker(id);
log.info("*******result:"+result);
return result;
}
之后我们测试
一直用参数为-1的错误请求访问
之后访问正确的请求(参数为正数)会发现
服务暂时调用不了正确的业务代码
多次错误,然后慢慢正确,发现刚开始不满足条件,就算是正确的访问地址也不能进行访问,等待片刻之后就可以访问到了
熔断类型 熔断打开: 请求不再进行调用当前服务,内部设置时钟一般为MTTR(平均故障处理时间),当打开时长达到所设时钟则进入熔断状态 熔断关闭: 熔断关闭不会对服务进行熔断,而是暂时关闭服务,等待片刻就会进入半开状态 熔断半开: 部分请求根据规则调用当前服务,如果请求成功且符合规则则认为当前服务恢复正常,关闭熔断
官网的流程步骤:
什么时候会触发熔断呢?
涉及到断路器的三个重要参数:快照时间窗、请求总数阀值、错误百分比阀值。
断路器开启或者关闭的条件
断路器打开之后
再有请求调用的时候,将不会调用主逻辑,而是直接调用降级fallback。通过断路器,实现了自动地发现错误并将降级逻辑切换为主逻辑,减少响应延迟的效果。 原来的主逻辑要如何恢复呢? 对于这一问题,hystrix也为我们实现了自动恢复功能。 当断路器打开,对主逻辑进行熔断之后,hystrix会启动一个休眠时间窗,在这个时间窗内,降级逻辑是临时的成为主逻辑,当休眠时间窗到期,断路器将进入半开状态,释放一次请求到原来的主逻辑上,如果此次请求正常返回 那么断路器将继续闭合, 主逻辑恢复,如果这次请求依然有问题,断路器继续进入打开状态,休眠时间窗重新计时。
下面是触发条件全部配置解读
:@HystrixCommand(fallbackMethod = "str_fa1lbackMethod",
groupKey = "strGroupCommand",
commandKey = "strCommarld" ,
threadPoolKey = "strThreadPoo1",commandProperties = {
//设置隔离策略,THREAD表示线程池SEMAPHORE:信号池隔离
@HystrixProperty(name = "execution.isolation.strategy" , value = "THREAD"),
//当隔离策略选择信号地隔离的时候,用来没置信号地的大小(最大并发数)
@HystrixProperty(name = "execution.isolation.semaphore.maxConcurrentRequests" , value="10"),
//配置命令执行的超时时间
@HystrixProperty(name = "execution.isolation.thread.timeoutinNilliseconds",value = "10"),
//是否启用超时时间
@HystrixProperty(name = "execution.timeout.enabled" , value = "true"),
//执行超时的时候是否中断
@HystrixProperty(name ="execution.isolation.thread.interruptOnTimeout", value = "true"),
//执行被取消的时候是否中断
CHystrixProperty(name = "execution.isolation.thread.interruptOnCance1",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.requestVo1umeThreshold", value = "20"),
//该属性用来设置在滚动时间窗中,表示在滚动时间窗中,在请求数量超过
// circuitBreaker.requestVolumeThreshold 的情况下,如果错误请求数的百分比超过50,/就把断路器没置为“打开”状态,否则就没置为“关闭”状态。
CHystrixProperty(name ="circuitBreaker.errorThresholdPercentage", value = "50"),
//该属性用来没置当断路器打开之后的休眠时间窗。休眠时间窗结京之后,
//会将断路器置为“半开”状态,尝式熔断的请求命令,如果依然失败就将断路器继续设置为“打开”状态,//如果成功就没置为“关闭”状态。
@HystrixProperty(name = "circuitBreaker.sleepWindowinMilliseconds", value = "5000"),
//断路器强制打开
CHystrixProperty(name = "circuitBreaker.forceOpen", value = "fa1se"),
//断路器强制关闭
CHystrixProperty(name = "circuitBreaker.forceclosed" , value = "false"),
//滚动时间窗没置,该时间用于断路器判断健康度时需要收集信息的持续时间
CHystrixProperty(name = "metrics.rollingStats.timeinMilliseconds",value = "10000"),
//该属性用来设置滚动时间窗统计指标信息时划分"桶""的数量,断路器在收集指标信息的时候会根据/设置的时间窗长度拆分成多个“桶”来累计各度量值,每个”桶"记录了一段时间内的采集指标。
//比如10秒内拆分成10个"桶"收集这样,所以 timeinMilliseconds必须能被numBuckets整除。否则会抛异常
@HystrixProperty(name = "metrics.rollingStats.numBuckets", value = "10""),
//滚动时间窗没置,该时间用于断路器判断健康度时需要收集信息的持续时间
@HystrixProperty(name = "metrics.rollingStats.timeinMilliseconds",value = "10000"),
//该属性用来没置滚动时间窗统计指标信息时划分"捅"的数量,断路器在收集指标信息的时候会根据
//没置的时间窗长度拆分成多个“桶”来累计各度量值,每个”桶"记录了一段时间内的采集指标。
//比如10秒内拆分成10个"糖""收集这样,所以timeinWilliseconds必须能被numBuckets整除。否则会抛异常
@HystrixProperty(name = "metrics.rollingStats.numBuckets",value = "10"),
//该属性用来设置对命令执行的延迟是否使用百分位数来跟踪和计算。如果没置为false,那么所有的概要统计都将返回-1。
@HystrixProperty(name = "metrics.rollingPercentile.enabled",value = "false"),
//该属性用来没置百分位统计的滚动窗口的持续时间,单位为毫秒。
@HystrixProperty(name ="metrics.rollingPercenti1le.timeInNilliseconds" , value = "60000"),
//该属性用来设置百分位统计滚动窗口中使用A捅”的数量。
@HystrixProperty(name ="metrics.rollingPercentile.numBuckets" , value = "60000"),
//该属性用来设置在执行过程中每个“桶”中保留的最大执行次数。如果在滚动时间窗内发生超过该没定值的执行次数,
//就从最初的位置开始重写。例如,将该值没置为100,滚动窗口为10秒,若在10秒内一个“桶”中发生了500次执行,
//那么该“桶”中只保留最后的190-次执行的统计。另外,增加该值的大小将会增加内存量的消耗,并增加排序百分位数所需的计算时间。
@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.rollingPercentile.bucketSize",value = "100"),
/该属性用来没置采集影响断路器状态的健康快照(请求的成功、错误百分比)的间隔等待时间。CHystrixProperty(name = "metrics.healthSnapshot.intervalinMilliseconds" , value = "500"),
//是否开启请求缓存
@HystrixProperty(name = "requestCache.enabled", value = "true"),
// 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"),
})
github连接:https://github.com/Netflix/Hystrix/wiki/How-it-Works
hystrix工作流程
工作流程图:
步骤说明:
除了隔离依赖服务的调用以外,Hystri还提供了准实时的调用监控(Hystrix Dashboard),Hystrix会持续地记录所有通过Hystrix发起的请求的执行信息,并以统计报表和图形的形式展示给用户,包括每秒执行多少请求多少成功,多少失败等。Netflix通过 hystrix-metrics-event-stream项目实现了对以上指标的监控。Spring Cloud也提供了Hystrix Dashboard的整合,对监控内容转化成可视化界面。
搭建一个简单的模块
cloud-consumer-hystrix-dashboard9001
导入依赖
<dependencies>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-netflix-hystrix-dashboardartifactId>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-actuatorartifactId>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-devtoolsartifactId>
<scope>runtimescope>
<optional>trueoptional>
dependency>
<dependency>
<groupId>org.projectlombokgroupId>
<artifactId>lombokartifactId>
<optional>trueoptional>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-testartifactId>
<scope>testscope>
dependency>
dependencies>
配置yml(就一个端口号)
server:
port: 9001
主启动类
@SpringBootApplication
@EnableHystrixDashboard
public class HystrixDashboardMain9001 {
public static void main(String[] args) {
SpringApplication.run(HystrixDashboardMain9001.class,args);
}
}
我们需要:HystrixDashboardMain9001+新注解@EnableHystrixDashboard
我们要是要监控那一定要是倒入这个
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-actuatorartifactId>
dependency>
修改:cloud-provider-hystrix-payment8001
PS: 注意:新版本Hystrix需要在主启动类MainAppHystrix8001中指定监控路径
@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;
}
到这里简单的服务监控就搞定了,启动测试 !
首先是填写监控地址
我们可以这样测试:
资源监控显示的
到这里就算是暂时告一段落啦