本专栏学习内容来自尚硅谷周阳老师的视频
有兴趣的小伙伴可以点击视频地址观看
Hystrix是一个用于处理分布式系统的延迟和容错的一个开源库,在分布式系统里,许多依赖不可避免的会调用失败,比如超时、异常等,Hystrix能保证在一个依赖出现问题的情况下,不会导致整体服务失败,避免级联故障,以提高分布式系统的稳定性。“断路器”本身是一种开关装置,当某个服务单元发生故障之后,通过断路器的故障监控(类似熔断保险丝),向调用方返回一个符合预期的,可处理的备选响应,而不是长时间等待或者抛出调用方无法处理的异常,这样就保证了服务调用方的线程不会被长时间、不必要的占用,从而避免了故障在分布式系统中的蔓延,乃至雪崩。
客户端去调用服务端的接口时,此接口处理时间较长,假设同一时间内有非常多的请求调用此接口,就会导致服务器繁忙,服务降级就是为了不让客户端等待并立刻返回一个友好的提示
哪些情况会触发降级
服务熔断类似于家里的保险丝,当家中电器功率消耗异常时,保险丝会直接断电,俗称跳闸,来保护电路的安全。服务熔断也是一样,当客户端调用达到最大服务访问后,直接拒绝访问,然后用服务降级的方法返回一个友好提示
顾名思义,就是对访问服务端的请求进行限制,例如秒杀等高并发操作,严禁一蜂窝请求过来,需要对请求进行排队,有序进行
在学习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+"\t"+"O(∩_∩)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+"\t"+"O(∩_∩)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线程池中的工作现场已经被挤占完毕
如果是超时导致响应变慢,要求超时不再等待
如果是程序出错,要有一个友好提示
作为服务端,首先我们要保护自己,在这里要再提一下服务降级的概念。
当程序调用超时或出现异常时,必须有一个友好的提示或解决方案
设置服务端调用超时时间的峰值,峰值内可以正常运行,超过了需要有兜底的方案处理,作服务降级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+"\t"+"O(∩_∩)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 {
@Autowired
private PaymentHystrixService paymentHystrixService;
@GetMapping("/consumer/payment/hystrix/ok/{id}")
@HystrixCommand
public 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.enabled=true
#设置通用超时时间
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=2000
创建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{
@Override
public String paymentInfo_OK(Integer id) {
return "服务调用失败---paymentInfo_OK";
}
@Override
public 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;
}
服务熔断,有以下几种熔断类型
涉及到断路器的三个重要参数
断路器断开,在一段时间之后(默认是5秒),这个时候断路器处于半开状态,会让其中一个请求进行转发,如果成功,断路器会关闭,若失败,继续打开。
可以参考官网https://github.com/Netflix/Hystrix/wiki/How-it-Works
除了隔离依赖服务的调用以外,Hystrix还提供了准实时的调用监控(Hystrix Dashboard),Hystrix会持续地记录所有通过Hystrix发起的请求的执行信息,并以统计报表和图形的形式展示给用户,包括每秒执行多少请求多少成功,多少失败等。Netflix通过hystrix-metrics-event-stream项目实现了对以上指标的监控。Spring Cloud也提供了Hystrix Dashboard的整合,对监控内容转化成可视化界面。
新建一个cloud-consumer-hystrix-dashboard9001服务,修改pom文件
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-netflix-hystrix-dashboardartifactId>
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>
启动类
@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就可以了
*/
@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;
}
}
在图形化页面中输入http://localhost:8001/hystrix.stream即可监控该服务