php mysql网站开发全程实例,商店名怎么显示在地图上,外国wordpress后台怎样添加关键词,兼职网站推广如何做Hystrix 本专栏学习内容来自尚硅谷周阳老师的视频 有兴趣的小伙伴可以点击视频地址观看 简介
Hystrix是一个用于处理分布式系统的延迟和容错的一个开源库#xff0c;在分布式系统里#xff0c;许多依赖不可避免的会调用失败#xff0c;比如超时、异常等#xff0c;Hystrix…Hystrix 本专栏学习内容来自尚硅谷周阳老师的视频 有兴趣的小伙伴可以点击视频地址观看 简介
Hystrix是一个用于处理分布式系统的延迟和容错的一个开源库在分布式系统里许多依赖不可避免的会调用失败比如超时、异常等Hystrix能保证在一个依赖出现问题的情况下不会导致整体服务失败避免级联故障以提高分布式系统的稳定性。“断路器”本身是一种开关装置当某个服务单元发生故障之后通过断路器的故障监控类似熔断保险丝向调用方返回一个符合预期的可处理的备选响应而不是长时间等待或者抛出调用方无法处理的异常这样就保证了服务调用方的线程不会被长时间、不必要的占用从而避免了故障在分布式系统中的蔓延乃至雪崩。
重要概念
服务降级fallback
客户端去调用服务端的接口时此接口处理时间较长假设同一时间内有非常多的请求调用此接口就会导致服务器繁忙服务降级就是为了不让客户端等待并立刻返回一个友好的提示
哪些情况会触发降级
程序运行异常超时服务熔断触发服务降级线程池/信号量打满也会导致服务降级
服务熔断break
服务熔断类似于家里的保险丝当家中电器功率消耗异常时保险丝会直接断电俗称跳闸来保护电路的安全。服务熔断也是一样当客户端调用达到最大服务访问后直接拒绝访问然后用服务降级的方法返回一个友好提示
服务限流flowlimit
顾名思义就是对访问服务端的请求进行限制例如秒杀等高并发操作严禁一蜂窝请求过来需要对请求进行排队有序进行
压力测试
在学习Hystrix之前我们先来进行一个压力测试模拟一下客户端繁忙的情况。
服务端
最主要的是这两个方法一个是ok方法是不需要停顿很快就可以完成的而timeout方法模拟业务处理比较慢停顿三秒钟。
使用ApiPost进行压力测试当20000个请求访问timeout方法时会占用tomcat所有的线程导致我们访问ok接口的速度变慢。
Service
public class PaymentService {public String paymentInfo_OK(Integer id) {return 线程池 Thread.currentThread().getName() paymentInfo_OK,id: id\tO(∩_∩)O哈哈;}public String paymentInfo_TimeOut(Integer id) {long timeout 3;try {Thread.sleep(timeout * 1000);} catch (InterruptedException e) {e.printStackTrace();}return 线程池 Thread.currentThread().getName() paymentInfo_timeout,id: id\tO(∩_∩)O哈哈 等待 timeout 秒钟;}
}客户端
上述的测试仅仅是在服务端如果客户端这时候介入进来后果恐怕是更加的严重。
客户端通过OpenFeign来调用服务端
Component
FeignClient(value CLOUD-HYSTRIX-PAYMENT-SERVICE)
public interface PaymentHystrixService {GetMapping(/payment/hystrix/ok/{id})String paymentInfo_OK(PathVariable(id) Integer id);GetMapping(/payment/hystrix/timeout/{id})String paymentInfo_TimeOut(PathVariable(id) Integer id);
}故障现象
8001同一层次的其他接口服务被困死因为tomcat线程池中的工作现场已经被挤占完毕
解决方案
如果是超时导致响应变慢要求超时不再等待
如果是程序出错要有一个友好提示
服务端8001超时了客户端80不能一直卡死等待必须要有服务降级服务端8001宕机了客户端80不能一直卡死等待必须要有服务降级服务端8001正常客户端80自己出故障或者有自我要求自己的等待时间小于服务端处理时间自己处理降级
服务降级
服务端
作为服务端首先我们要保护自己在这里要再提一下服务降级的概念。
当程序调用超时或出现异常时必须有一个友好的提示或解决方案
设置服务端调用超时时间的峰值峰值内可以正常运行超过了需要有兜底的方案处理作服务降级fallback
修改service方法
/*** fallbackMethod 如果程序超时或异常兜底方法为paymentInfo_TimeOut_handler* HystrixProperty 设置程序的超时峰值* param id* return*/
HystrixCommand(fallbackMethod paymentInfo_TimeOut_handler,commandProperties {HystrixProperty(name execution.isolation.thread.timeoutInMilliseconds, value 3000)
})
public String paymentInfo_TimeOut(Integer id) {// 用于测试程序异常// int i 10 / 0; long timeout 5;try {Thread.sleep(timeout * 1000);} catch (InterruptedException e) {e.printStackTrace();}return 线程池 Thread.currentThread().getName() paymentInfo_timeout,id: id\tO(∩_∩)O哈哈 等待 timeout 秒钟;
}public String paymentInfo_TimeOut_handler(Integer id) {return 线程池 Thread.currentThread().getName() paymentInfo_TimeOut_handler,id: id\t调用超时或程序异常;
}开启hystrix
启动类加上以下注解
SpringBootApplication
EnableEurekaClient
EnableCircuitBreaker //启动hystrix
public class HystrixPaymentMain8001 {public static void main(String[] args){SpringApplication.run(HystrixPaymentMain8001.class,args);}
}测试
测试发现无论是超时还是程序异常paymentInfo_TimeOut_handler()都会给出一个兜底的处理方案这里需要注意的是我们打印了线程名称发现此线程不是从默认线程池中拿出的
2023-04-06 20:32:32.340 INFO 27057 --- [nio-8001-exec-1] c.y.s.controller.PaymentController : ****result: 线程池 hystrix-PaymentService-1paymentInfo_TimeOut_handler,id: 1 调用超时或程序异常客户端
客户端服务降级的处理方式跟服务端差不多由于客户端使用Feign来远程调用服务所以需要开启Feign内部的Hystrix
主启动类
EnableHystrix修改调用方法
GetMapping(/consumer/payment/hystrix/timeout/{id})
HystrixCommand(fallbackMethod paymentInfo_TimeOut_Handler,commandProperties {HystrixProperty(name execution.isolation.thread.timeoutInMilliseconds, value 1500)
})
public String paymentInfo_TimeOut(PathVariable(id) Integer id) {String result paymentHystrixService.paymentInfo_TimeOut(id);return result;
}public String paymentInfo_TimeOut_Handler(PathVariable(id) Integer id) {return 我是消费者80,对方支付系统繁忙请10秒钟后再试或者自己运行出错请检查自己,o(╥﹏╥)o;
}由于客户端设置超时时间为1.5秒所以当调用服务端等待时间超过1.5秒时触发兜底方案这里需要注意的是请求已经发送了只不过客户端终止了等待服务端照常运行
代码膨胀
上述的方案看起来是已经实现了服务降级没错但是在代码上出现了膨胀假设有100个服务降级方法就需要100个兜底方法这显然不符合我们的编码规范
修改客户端代码
DefaultProperties开启全局兜底方案这样就不需要一个一个写过去
HystrixCommand方法上标注此注解表示使用Hystrix断路器
HystrixCommand(fallbackMethod …)就近原则spring会调用自定义的兜底方案
RestController
Slf4j
DefaultProperties(defaultFallback payment_Global_FallbackMethod) //全局兜底方案
public class OrderHystirxController {Autowiredprivate PaymentHystrixService paymentHystrixService;GetMapping(/consumer/payment/hystrix/ok/{id})HystrixCommandpublic String paymentInfo_OK(PathVariable(id) Integer id) {int i 10 / 0;String result paymentHystrixService.paymentInfo_OK(id);return result;}GetMapping(/consumer/payment/hystrix/timeout/{id})HystrixCommand(fallbackMethod paymentInfo_TimeOut_Handler,commandProperties {HystrixProperty(name execution.isolation.thread.timeoutInMilliseconds, value 1500)})public String paymentInfo_TimeOut(PathVariable(id) Integer id) {String result paymentHystrixService.paymentInfo_TimeOut(id);return result;}public String paymentInfo_TimeOut_Handler(PathVariable(id) Integer id) {return 我是消费者80,对方支付系统繁忙请10秒钟后再试或者自己运行出错请检查自己,o(╥﹏╥)o;}public String payment_Global_FallbackMethod() {return 我是消费者80,这是全局兜底方案,o(╥﹏╥)o;}
}代码混乱
上述方案中我们发现整个服务降级处理方案和业务逻辑写在一起非常的混乱。
我们可以在Feign中开启Hystrix
配置注解
#在feign中开启hystrix
feign.hystrix.enabledtrue
#设置通用超时时间
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds2000创建PaymentFallbackService类实现PaymentHystrixService并修改
Component
FeignClient(value CLOUD-HYSTRIX-PAYMENT-SERVICE,fallback PaymentFallbackService.class)
public interface PaymentHystrixService {GetMapping(/payment/hystrix/ok/{id})String paymentInfo_OK(PathVariable(id) Integer id);GetMapping(/payment/hystrix/timeout/{id})String paymentInfo_TimeOut(PathVariable(id) Integer id);
}Component
public class PaymentFallbackService implements PaymentHystrixService{Overridepublic String paymentInfo_OK(Integer id) {return 服务调用失败---paymentInfo_OK;}Overridepublic String paymentInfo_TimeOut(Integer id) {return 服务调用失败---paymentInfo_TimeOut;}
}服务熔断
**熔断机制是应对雪崩效应的一种微服务链路保护机制。**当扇出链路的某个微服务出错不可用或者响应时间太长时会进行服务的降级进而熔断该节点微服务的调用快速返回错误的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。
在Spring Cloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况当失败的调用到一定阈值缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是HystrixCommand。 代码演示
为了演示方便只在8001服务端演示服务熔断不需要服务间的调用也可以完成
在PaymentService中添加如下代码综合来解释一下这几个注解的意思相当于10秒内请求次数在10次以上并且失败率达到60%则会“跳闸”就是服务熔断
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 不能负数请稍后再试/(ㄒoㄒ)/~~ id: id;
}在controller层添加调用代码测试访问该请求连续访问报错请求发现访问报错请求多了之后保险丝就会断开此后在访问正确的请求发现也会进入fallback中但是在一段时间后又会可以正常请求。
GetMapping(/payment/circuit/{id})
public String paymentCircuitBreaker(PathVariable(id) Integer id)
{String result paymentService.paymentCircuitBreaker(id);log.info(****result: result);return result;
}总结
服务熔断有以下几种熔断类型
熔断打开请求不再进行调用当前服务内部设置时钟一般为MTTR平均故障处理时间)当打开时长达到所设时钟则进入半熔断状态熔断关闭熔断关闭不会对服务进行熔断熔断半开部分请求根据规则调用当前服务如果请求成功且符合规则则认为当前服务恢复正常关闭熔断
涉及到断路器的三个重要参数
时间窗口期断路器确定是否打开需要统计一些请求和错误数据统计的时间范围就是时间窗口期默认为最近的10秒请求总数阈值在快照时间窗内必须满足请求总数阀值才有资格熔断。默认为20意味着在10秒内如果该hystrix命令的调用次数不足20次即使所有的请求都超时或其他原因失败断路器都不会打开。错误百分比阈值当请求总数在快照时间窗内超过了阀值比如发生了30次调用如果在这30次调用中有15次发生了超时异常也就是超过50%的错误百分比在默认设定50%阀值情况下这时候就会将断路器打开。
断路器断开在一段时间之后默认是5秒这个时候断路器处于半开状态会让其中一个请求进行转发如果成功断路器会关闭若失败继续打开。
工作流程
可以参考官网https://github.com/Netflix/Hystrix/wiki/How-it-Works
服务监控hystrixDashboard
除了隔离依赖服务的调用以外Hystrix还提供了准实时的调用监控Hystrix DashboardHystrix会持续地记录所有通过Hystrix发起的请求的执行信息并以统计报表和图形的形式展示给用户包括每秒执行多少请求多少成功多少失败等。Netflix通过hystrix-metrics-event-stream项目实现了对以上指标的监控。Spring Cloud也提供了Hystrix Dashboard的整合对监控内容转化成可视化界面。
创建服务
新建一个cloud-consumer-hystrix-dashboard9001服务修改pom文件
!-- dashboard核心依赖 --
dependencygroupIdorg.springframework.cloud/groupIdartifactIdspring-cloud-starter-netflix-hystrix-dashboard/artifactId
/dependency
dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-web/artifactId
/dependency
!-- 只要与图形化监控页面有关都需要actuator --
dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-actuator/artifactId
/dependency
dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-devtools/artifactIdscoperuntime/scopeoptionaltrue/optional
/dependency
dependencygroupIdorg.projectlombok/groupIdartifactIdlombok/artifactIdoptionaltrue/optional
/dependency
dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-test/artifactIdscopetest/scope
/dependency启动类
SpringBootApplication
EnableHystrixDashboard //开启dashboard
public class HystrixDashboardMain9001 {public static void main(String[] args) {SpringApplication.run(HystrixDashboardMain9001.class, args);}
}完成以上两步之后我们就可以打卡图形化监控页面也是一个非常可爱的页面 监控8001服务还需要在8001的主启动类里加上如下代码
SpringBootApplication
EnableEurekaClient
EnableCircuitBreaker //启动hystrix
public class HystrixPaymentMain8001 {public static void main(String[] args){SpringApplication.run(HystrixPaymentMain8001.class,args);}/***此配置是为了服务监控而配置与服务容错本身无关springcloud升级后的坑*ServletRegistrationBean因为springboot的默认路径不是/hystrix.stream*只要在自己的项目里配置上下面的servlet就可以了*/Beanpublic ServletRegistrationBean getServlet() {HystrixMetricsStreamServlet streamServlet new HystrixMetricsStreamServlet();ServletRegistrationBean registrationBean new ServletRegistrationBean(streamServlet);registrationBean.setLoadOnStartup(1);registrationBean.addUrlMappings(/hystrix.stream); //这是监控地址registrationBean.setName(HystrixMetricsStreamServlet);return registrationBean;}
}在图形化页面中输入http://localhost:8001/hystrix.stream即可监控该服务
