服务熔断和雪崩（熔断与服务雪崩）

服务熔断和雪崩（熔断与服务雪崩）调用端如果发现服务故障，就不调用了，直接返回失败。这种机制叫熔断，熔断有两种策略：一种是根据请求失败率做熔断，另一种是根据请求响应时间做熔断。熔断是降级的一种方式，而降级是一种兜底的方案，表示在系统出故障之后采取一个备用方案。比如电商商品展示页，有图片、文字描述、价格、库存、优惠活动等信息，当优惠活动的服务宕机，其他信息可以正常展示，不影响用户下单。所以能熔断的服务不会是核心链路上的必选服务。2、熔断1、线程隔离为响应慢的接口调用单独准备一个线程池（限制线程个数），与主业务处理线程隔离开，不在一起同步调用了，当线程池没有空闲线程，并且线程池内部队列满了的情况下，线程池会抛出异常，拒绝新的请求，从而防止调用线程阻塞。一个机器能开的线程数有限，并且线程切换开销大。信号量隔离方式相比线程池隔离更轻量，不会新增线程池，而是通过控制调用接口的线程数，信号量等于你需要控制的线程数。在线程访问资源之前获

在现实生活中的当电路中电流过大温度升高，会熔断保险丝跳闸，起到保护电路的作用。而系统上的熔断是调用端对自己保护，举个例子：服务A需要调用服务B、服务B里面要调用第三方服务获取接口数据，但第三方接口响应很慢，导致整个调用链路的响应也会变得很慢。这样会出现什么问题呢，假设服务B的请求线程在等待第三方接口返回，服务A在等服务B返回，此时所有线程出现阻塞，当服务的请求连接数满了，将会拒绝接收新的请求。有时服务B调用超时报错，紧接着影响到服务A超时，最坏状况是服务B如果是个基础数据服务，它故障了，会影响多个服务不可用，因为服务之间相互调用，所以故障最终会扩大到影响整个系统不可用，这个现象称为服务雪崩。

服务雪崩

服务雪崩在微服务架构应用里时常发生，发生场景有两个，一是接口响应慢，访问线程阻塞，迟迟未释放，导致服务的请求链接数满了，拒绝接收新请求。二是基础服务故障，影响多个服务不可用。

要解决上面两个问题，需要引入一种新技术，且满足下面两个需求：

1、线程隔离

为响应慢的接口调用单独准备一个线程池（限制线程个数），与主业务处理线程隔离开，不在一起同步调用了，当线程池没有空闲线程，并且线程池内部队列满了的情况下，线程池会抛出异常，拒绝新的请求，从而防止调用线程阻塞。

一个机器能开的线程数有限，并且线程切换开销大。信号量隔离方式相比线程池隔离更轻量，不会新增线程池，而是通过控制调用接口的线程数，信号量等于你需要控制的线程数。在线程访问资源之前获取信号量，当访问结束时，释放信号量。一旦信号量到达最大阈值，线程获取不到信号量，会丢弃请求，而不是阻塞在那里等待信号量。

2、熔断

调用端如果发现服务故障，就不调用了，直接返回失败。这种机制叫熔断，熔断有两种策略：一种是根据请求失败率做熔断，另一种是根据请求响应时间做熔断。熔断是降级的一种方式，而降级是一种兜底的方案，表示在系统出故障之后采取一个备用方案。比如电商商品展示页，有图片、文字描述、价格、库存、优惠活动等信息，当优惠活动的服务宕机，其他信息可以正常展示，不影响用户下单。所以能熔断的服务不会是核心链路上的必选服务。

目前有两个比较流行的框架可以解决以上需求，一个是Netflix开源的Hystrix；另一个是阿里开源的Sentinel。两者的对比如下图：

（1）根据请求失败率做熔断。客户端调用某个服务，如果服务在短时间内大量超时或者报错，客户端开启熔断，就不再调用此服务。

以Hystrix为例，它有几个参数来配置熔断器的策略

上面参数说明，每20个请求中，如果有50%的失败率，熔断器就会打开，此时再调用第三方接口，会直接返回失败，或者执行降级方法。直到5秒后，重新检测接口是否再次调用失败，如果成功，熔断器关闭，否则继续打开。

（2）根据请求响应时间做熔断。是Sentinel提供的另一种思路

上面代码说明，在20秒的统计时间内，有超过100个的请求，其中有60%的请求响应时间超过50ms时，熔断器将开启。直到10秒后，重新检测下一个请求响应时间，如果响应时间小于50ms，结束熔断，否则会再次被熔断。