微服务熔断、降级——Hystrix
抱养⼀、概述
1、服务雪崩
户外活动主题
分布式系统环境下，服务间类似依赖⾮常常见，⼀个业务调⽤通常依赖多个基础服务。如下图，对于同步调⽤，当库存服务不可⽤时，商品服务请求线程被阻塞，当有⼤批量请求调⽤库存服务时，最终可能导致整个商品服务资源耗尽，⽆法继续对外提供服务。并且这种不可⽤可能沿请求调⽤链向上传递，这种现象被称为雪崩效应。
雪崩效应常见场景
1）硬件故障：如服务器宕机，机房断电，光纤被挖断等。
2）流量激增：如异常流量，重试加⼤流量等。
3）缓存穿透：⼀般发⽣在应⽤重启，所有缓存失效时，以及短时间内⼤量缓存失效时。⼤量的缓存不命中，使请求直击后端服务，造成服务提供者超负荷运⾏，引起服务不可⽤。
4）程序 BUG：如程序逻辑导致内存泄漏，JVM 长时间 FullGC 等。 同步等待：服务间采⽤同步调⽤模式，同步等待造成的资源耗尽。
雪崩效应应对策略
针对造成雪崩效应的不同场景，可以使⽤不同的应对策略，没有⼀种通⽤所有场景的策略，参考如下：
1）硬件故障：多机房容灾、异地多活等。
2）流量激增：服务⾃动扩容、流量控制（限流、关闭重试）等。 缓存穿透：缓存预加载、缓存异步加载等。
3）程序 BUG：修改程序 bug、及时释放资源等。
4）同步等待：资源隔离、MQ 解耦、不可⽤服务调⽤快速失败等。资源隔离通常指不同服务调⽤采⽤不同的线程池；不可⽤服务调⽤快速失败⼀般通过熔断器模式结合超时机制实现。
综上所述，如果⼀个应⽤不能对来⾃依赖的故障进⾏隔离，那该应⽤本⾝就处在被拖垮的风险中。
因此，为了构建稳定、可靠的分布式系统，我们的服务应当具有⾃我保护能⼒，当依赖服务不可⽤时，当前服务启动⾃我保护功能，从⽽避免发⽣雪崩效应。
2、Hystrix
（1）Hystrix 是什么
Hystrix是⼀个⽤于处理分布式系统的延迟和容错的开源库，在分布式系统⾥，许多依赖不可避免的会调⽤失败，⽐如超时、异常
等，Hystrix 能够保证在⼀个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提⾼分布式系统的弹性。
"断路器”本⾝是⼀种开关装置，当某个服务单元发⽣故障之后，通过断路器的故障监控（类似熔断保险丝)，向调⽤⽅返回⼀个符合预期的、可处理的备选响应（FallBack)，⽽不是长时间的等待或者抛出调⽤⽅⽆法处理的异常，这样就保证了服务调⽤⽅的线程不会被长时间、不必要地占⽤，从⽽避免了故障在分布式系统中的蔓延，乃⾄雪崩。
（2）Hystrix 设计⽬标：
对来⾃依赖的延迟和故障进⾏防护和控制——这些依赖通常都是通过⽹络访问的
阻⽌故障的连锁反应
快速失败并迅速恢复
回退并优雅降级
提供近实时的监控与告警
（3）Hystrix 遵循的设计原则：
防⽌任何单独的依赖耗尽资源（线程）
过载⽴即切断并快速失败，防⽌排队吴哥窟在哪
尽可能提供回退以保护⽤户免受故障
使⽤隔离技术（例如隔板，泳道和断路器模式）来限制任何⼀个依赖的影响
通过近实时的指标，监控和告警，确保故障被及时发现
通过动态修改配置属性，确保故障及时恢复
防⽌整个依赖客户端执⾏失败，⽽不仅仅是⽹络通信
（4）Hystrix 如何实现这些设计⽬标？
使⽤命令模式将所有对外部服务（或依赖关系）的调⽤包装在 HystrixCommand 或 HystrixObrvableCommand 对象中，并将该对象放在单独的线程中执⾏；
每个依赖都维护着⼀个线程池（或信号量），线程池被耗尽则拒绝请求（⽽不是让请求排队）。
记录请求成功，失败，超时和线程拒绝。
服务错误百分⽐超过了阈值，熔断器开关⾃动打开，⼀段时间内停⽌对该服务的所有请求。
行驶证丢失请求失败，被拒绝，超时或熔断时执⾏降级逻辑。
近实时地监控指标和配置的修改。
⼆、服务熔断、降级与限流
1、服务降级——丢车保帅
服务降级是指当服务器压⼒剧增的情况下，为了预防某些功能（业务场景）出现负荷过载或者响应慢的情况，在其内部暂时舍弃对⼀些⾮核⼼的接⼝和服务的请求，⽽直接返回⼀个提前准备好的 fallback（退路）错误处理信息。这样，虽然提供的是⼀个有损的服务，但释放了服务器资源以保证核⼼业务正常运作或⾼效运作，保证了整个系统的稳定性和可⽤性。说⽩了，就是尽可能的把系统资源让给优先级⾼的服务。
资源有限，⽽请求是⽆限的。如果在并发⾼峰期，不做服务降级处理，⼀⽅⾯肯定会影响整体服务的性能，严重的话可能会导致宕机某些重要的服务不可⽤。所以，⼀般在⾼峰期，为了保证核⼼功能服务的可⽤性，都要对某些服务降级处理。⽐如当双 11 活动时，把交易⽆关的服务统统降级，如查看蚂蚁深林，查看历史订单等等。
（1）服务降级主要⽤于什么场景呢？
当整个微服务架构整体的负载超出了预设的上限阈值或即将到来的流量预计将会超过预设的阈值时，为了保证重要或基本的服务能正常运⾏，可以将⼀些不重要或不紧急的服务或任务进⾏服务的延迟使⽤ 或暂停使⽤。
降级的⽅式可以根据业务来，可以延迟服务，⽐如延迟给⽤户增加积分，只是放到⼀个缓存中，等服务平稳之后再执⾏；或者在粒度范围内关闭服务，⽐如关闭相关⽂章的推荐。
（2）实现服务降级需要考虑⼏个问题
1）那些服务是核⼼服务，哪些服务是⾮核⼼服务
2）那些服务可以⽀持降级，那些服务不能⽀持降级，降级策略是什么
3）除服务降级之外是否存在更复杂的业务放通场景，策略是什么？
（3）降级分类
1）超时降级：主要配置好超时时间和超时重试次数和机制，并使⽤异步机制探测回复情况
2）失败次数降级：主要是⼀些不稳定的 api，当失败调⽤次数达到⼀定阀值⾃动降级，同样要使⽤异步机制探测回复情况
3）故障降级：⽐如要调⽤的远程服务挂掉了（⽹络故障、DNS故障、http服务返回错误的状态码、rpc服务抛出异常），则可以直接降级。降级后的处理⽅案有：默认值（⽐如库存服务挂了，返回默认现货）、兜底数据（⽐如⼴告挂了，返回提前准备好的⼀些静态页⾯）、缓存（之前暂存的⼀些缓存数据）
4）限流降级：秒杀或者抢购⼀些限购商品时，此时可能会因为访问量太⼤⽽导致系统崩溃，此时会使⽤限流来进⾏限制访问量，当达到限流阀值，后续请求会被降级；降级后的处理⽅案可以是：排队页⾯（将⽤户导流到排队页⾯等⼀会重试）、⽆货（直接告知⽤户没货了）、错误页（如活动太⽕爆了，稍后重试）。
2、服务熔断
降级⼀般⽽⾔指的是我们⾃⾝的系统出现了故障⽽降级。⽽熔断⼀般是指依赖的外部接⼝出现故障的情况断绝和外部接⼝的关系。
在微服务架构中，微服务之间的数据交互通过远程调⽤完成，微服务A调⽤微服务 B 和微服务 C，微服务B和微服务 C ⼜调⽤其它的微服务，此时如果链路上某个微服务的调⽤响应时间过长或者不可⽤，那么对微服务 A 的调⽤就会占⽤越来越多的系统资源，进⽽引起系统崩溃，导致“雪崩效应”。
服务熔断是应对雪崩效应的⼀种微服务链路保护机制。例如在⾼压电路中，如果某个地⽅的电压过⾼，熔断器就会熔断，对电路进⾏保护。同样，在微服务架构中，熔断机制也是起着类似的作⽤。当调⽤链路的某个微服务不可⽤或者响应时间太长时，会进⾏服务熔断，不再有该节点微服务的调⽤，快速返回错误的响应信息。当检测到该节点微服务调⽤响应正常后，恢复调⽤链路。
服务熔断解决如下问题：
1）当所依赖的对象不稳定时，能够起到快速失败的⽬的；
2）快速失败后，能够根据⼀定的算法动态试探所依赖对象是否恢复。
3、服务限流限流
上⾯说的两个算是请求过来我们都受理了，这个限流就更狠了，直接跟请求说对不起再见！也就是系统规定了多少承受能⼒，只允许这么些请求能过来，其他的请求不对其进⾏处理。
⼀般限制的指标有：请求总量或某段时间内请求总量。
1）请求总量：⽐如秒杀的，秒杀100份产品，我就放5000名进来，超过的直接拒绝请求了。
2）某段时间内请求总量：⽐如规定了每秒请求的峰值是1W，这⼀秒内多的请求直接拒绝了。咱们下⼀秒再见。
番茄酱炒年糕熔断 VS 降级
（1）相同点：
⽬标⼀致 都是从可⽤性和可靠性出发，为了防⽌系统崩溃；
⽤户体验类似 最终都让⽤户体验到的是某些功能暂时不可⽤；
（2）不同点：
1）触发原因不同：服务熔断⼀般是某个服务（下游服务）故障引起，⽽服务降级⼀般是从整体负荷考虑；
2）实现⽅式不同：服务降级具有代码侵⼊性(由控制器完成/或⾃动降级)，熔断⼀般称为⾃我熔断。
总结
（1）限流：限制并发的请求访问量，超过阈值则拒绝；
（2）降级：服务分优先级，牺牲⾮核⼼服务（不可⽤），保证核⼼服务稳定；从整体负荷考虑；
（3）熔断：依赖的下游服务故障触发熔断，避免引发本系统崩溃；系统⾃动执⾏和恢复
三、Hystrix 进⾏服务降级
服务降级就是指服务器忙，请稍候再试，不让客户端等待并⽴刻返回⼀个友好提⽰ fallback。
哪些情况会触发降级：
1）程序运⾏异常，
2）超时，
3）服务熔断触发服务降级，
狄仁杰简介4）线程池/信号量打满也会导致服务降级；
服务降级分为服务端降级和客户端降级，好⽐⼀双筷⼦，你可以夹⾁，也可以夹菜，不过⼀般是⽤来在客户端降级使⽤，具体情况具体分析使⽤。
添加依赖
<!--使⽤ openfeign 进⾏服务调⽤-->
<!--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>
1、服务端服务降级
注：服务端指的是被调⽤的⼀⽅。
（1）使⽤ @HystrixCommand 在被调⽤的服务端设置兜底的 fallback 降级⽅法
@Service
public class ProvideHystrixService {
/**
* 成功访问
*/
public String getOk(Integer id){
工资return"线程池："+ Thread.currentThread().getName()+" ID:"+ id +"\t 访问成功";
}
/
**
* 访问超时
*/
@HystrixCommand(fallbackMethod ="paymentFallback_handler", commandProperties ={@HystrixProperty(name="execution.isolation.thread.timeoutIn Milliconds",value ="5000")})
public String getTimeout(Integer id){
int timeout =6;
try{
TimeUnit.SECONDS.sleep(timeout);
}catch(InterruptedException e){
e.printStackTrace();
}
return"线程池："+ Thread.currentThread().getName()+" ID:"+ id +"\t 访问超时，超时时间(秒)："+ timeout;
}
// 兜底的 fallback ⽅法
public String paymentFallback_handler(Integer id){
return"线程池："+ Thread.currentThread().getName()+" paymentFallback_handler---ID:"+ id +"\t ";
}
}
@HystrixCommand 注解是⽅法级别的，在你需要捕获的⽅法上加上注解。fallbackMethod 属性指定了捕获异常时需要执⾏的⽅
法，commandProperties 属性指定了异常条件。
（2）主启动类加注解 @EnableCircuitBreaker
@SpringBootApplication
@EnableEurekaClient
@EnableCircuitBreaker
public class ProvideHystrixApplication {
public static void main(String[] args){
SpringApplication.run(ProvideHystrixApplication.class,args);
去括号法则}
2、客户端服务降级
注：客户端指的是调⽤的⼀⽅。
（1）在 yml 中配置启动 feign 的 hystrix ⽀持
feign:
hystrix:
#如果处理⾃⾝的容错就开启。
enabled:true
（2）主启动类加上启⽤注解 @EnableHystrix
