Hystrix断路器
我们在使用分布式系统的时候总会面临着一个问题
数十个的依赖关系,有时候会不可避免的出错,
而多个接口调用一个服务有一个挂了,就会导致整个调用的接口无法使用
我们称这个为:服务雪崩
服务雪崩
多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”.
对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。
所以，通常当你发现一个模块下的某个实例失败后，这时候这个模块依然还会接收流量，然后这个有问题的模块还调用了其他的模块，这样就会发生级联故障，或者叫雪崩。
有需求那就有人出手解决于是乎:Hystrix出现了
Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。
"断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝)，向调用方返回一个符合预期的、可处理的备选响应（FallBack)，而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要地占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。
讲了这么多他能解决什么呢?
服务降级
服务熔断
接近实时的监控
官网连接:https://github.com/Netflix/Hystrix/wiki/How-To-Use
然而这么好的东西 : Hystrix官宣，停更进维
为了后面新的学习,我们需要理解思想,主要学习思想
Hystrix重要概念
服务降级fallback
服务器忙，请稍候再试，不让客户端等待并立刻返回一个友好提示，fallback方法
要是让客户端看到这个
哪些情况会触发降级:
程序运行异常
超时
服务熔断触发服务降级
线程池/信号量打满也会导致服务降级
不太好
我们可以在服务器出问题的时候编写兜底方法,如果服务出问题,有一个兜底,调用友好提示
服务熔断机制
类比保险丝达到最大服务访问后，直接拒绝访问，拉闸限电，然后调用服务降级的方法并返回友好提示
服务的降级->进而熔断->恢复调用链路
最核心的是可以重启服务
他就是类似一个机制,如果服务器出现触发机制的问题,停止服务,调用服务降级,尝试恢复服务
服务限流flowlimit(这里我暂时没有实践,等到Alibaba的版本的时候在使用)
秒杀高并发等操作，严禁一窝蜂的过来拥挤，大家排队，一秒钟N个，有序进行
服务降级: 实例模块编写
新建项目cloud-provider-hystrix-payment8001
导入核心依赖
<dependencies> <!--新增hystrix--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-hystrix</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency> <dependency> <groupId>com.atguigu.springcloud</groupId> <artifactId>cloud-api-commons</artifactId> <version>${project.version}</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <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>
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> <!--新增hystrix--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-hystrix</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-openfeign</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency> <dependency> <groupId>com.atguigu.springcloud</groupId> <artifactId>cloud-api-commons</artifactId> <version>${project.version}</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <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>
配置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; } }
之后测试
再高并发场景下会出现什么情况
2W个线程压8001
消费端80微服务再去访问正常的OK微服务8001地址
此时的80访问有两种情况
要么转圈圈等待
要么超时
为什么会出现上述情况呢?
8001同一层次的其他接口服务被困死，因为tomcat线程里面的工作线程已经被挤占完毕
80此时调用8001，客户端访问响应缓慢，转圈圈
正因为有上述故障或不佳表现，才有我们的降级/容错/限流等技术诞生
如何解决？解决的要求
这个时候我们的问题有了解决方案
超时导致服务器变慢（转圈）--------->超时不再等待,超过一定时间调用fallback方法
出错（宕机或程序运行出错）---------->出错要有兜底有方法兜底
解决:
对方服务（8001）超时了，调用者（80）不能一直卡死等待，必须有服务降级
对方服务（8001）down机了，调用者（80）不能一直卡死等待，必须有服务降级
对方服务（8001）OK，调用者（80）自己出故障或有自我要求（自己的等待时间小于服务提供者），自己处理降级
有了方案呢我们可以去执行
8001fallback
设置自身调用超时时间的峰值，峰值内可以正常运行，超过了需要有兜底的方法处理，作服务降级fallback
业务类启用 我们需要使用到Hystrix的注解
@HystrixCommand报异常后如何处理: 一旦调用服务方法失败并抛出了错误信息后，会自动调用@HystrixCommand标注好的fallbackMethod调用类中的指定方法
老规矩用了新的组件
主启动类就要激活
添加新注解@EnableCircuitBreaker
此时的主启动类
@SpringBootApplication @EnableEurekaClient @EnableCircuitBreaker public class paymentHystrix8001 { public static void main(String[] args) { SpringApplication.run(paymentHystrix8001.class,args); } }
80fallback
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); }
测试:
单个eureka先启动7001
PaymentHystrixMain8001启动
正常访问测试
故意关闭微服务8001
客户端自己调用提升: 此时服务端provider已经down了，但是我们做了服务降级处理，让客户端在服务端不可用时也会获得提示信息而不会挂起耗死服务器
小总结:
到这里我们就解决了有关客户端和服务端两方面的服务降级解决方案
