1.服务雪崩

分布式系统中一定会遇到的一个问题：服务雪崩效应 或者叫级联效应
那么什么是服务雪崩效应呢？
在一个高度服务化的系统中,我们实现的一个业务逻辑通常会依赖多个服务,比如:
商品详情展示服务会依赖商品服务, 价格服务, 商品评论服务. 如图所示

调用三个依赖服务会共享商品详情服务的线程池. 如果其中的商品评论服务不可用, 就会出
现线程池里所有线程都因等待响应而被阻塞, 从而造成服务雪崩. 如图所示:

服务雪崩效应：因服务提供者的不可用导致服务调用者的不可用,并将不可用逐渐放大的过
程，就叫服务雪崩效应
讲了什么是服务雪崩效应，那么同学们知道为什么服务不可用吗？导致服务不可用的原因老
师总结有几点： 程序Bug，大流量请求，硬件故障，缓存击穿
【大流量请求】：在秒杀和大促开始前,如果准备不充分,瞬间大量请求会造成服务提供者的
不可用.
【硬件故障】：可能为硬件损坏造成的服务器主机宕机, 网络硬件故障造成的服务提供者的
不可访问.【缓存击穿】：一般发生在缓存应用重启, 缓存失效时高并发， 所有缓存被清空时,以及短
时间内大量缓存失效时. 大量的缓存不命中, 使请求直击后端,造成服务提供者超负荷运行,引
起服务不可用.
而且，同学们，在服务提供者不可用的时候，会出现重试的情况：用户重试、代码逻辑重试
用户重试：在服务提供者不可用后, 用户由于忍受不了界面上长时间的等待,会不断刷新页面
甚至提交表单.
代码逻辑重试：服务调用端的会存在大量服务异常后的重试逻辑.
这些重试最终导致：进一步加大请求流量.
那么，归根结底导致雪崩效应的最根本原因是：
大量请求线程同步等待造成的资源耗尽
当服务调用者使用 同步调用 时, 会产生大量的等待线程占用系统资源. 一旦线程资源被耗尽,
服务调用者提供的服务也将处于不可用状态, 于是服务雪崩效应产生了.
那么知道了分布式系统中的服务雪崩效应，以及产生的原因。那么，问题来了，怎么解决？
解决方案
那么解决方案有很多，老师根据自己的经验列举一下：
1. 超时机制
2. 服务限流
3. 服务熔断
4. 服务降级
当然还有其他的，老师不一一列举
超时机制
刚刚老师分析了，服务级联失败（服务雪崩效应）的最根本原因是：大量请求线程同步等待
造成的资源耗尽
那么，在不做任何处理的情况下，服务提供者不可用会导致消费者请求线程强制等待，而造
成系统资源耗尽，而且，既然服务提供者已经不可用了，还在作死的请求的话，是毫无意义的。那么，如果我们加入超时机制，例如2s，那么超过2s就会直接返回了，那么这样是不
是一定程度上可以抑制消费者资源耗尽的问题。
服务限流(资源隔离)
也就是限制请求核心服务提供者的流量，使大流量拦截在核心服务之外，这样可以更好的保
证核心服务提供者不出问题，对于一些出问题的服务可以限制流量访问，只分配固定线程资
源访问，这样能使整体的资源不至于被出问题的服务耗尽，进而整个系统雪崩
那么服务之间怎么限流，怎么资源隔离了？例如通过线程池+队列的方式，通过信号量的方
式。
如下图所示, 当商品评论服务不可用时, 即使商品服务独立分配的20个线程全部处于同步等
待状态,也不会影响其他依赖服务的调用.

服务熔断
远程服务不稳定或网络抖动时暂时关闭，就叫服务熔断。
可能有些同学还是不懂，举个通俗易懂的例子，就跟我们现实生活中的“跳闸”一样，跳闸
同学们应该都听说过吧，比如说家里有点短路了，那是不是闸会跳掉，等你把短路的问题找
到并且修复后，然后你把这个闸一送，是不是整个家庭的电路又恢复了正常。这就是熔断
器。
所以，同样的道理，当依赖的服务有大量超时时，在让新的请求去访问根本没有意义，只会
无畏的消耗现有资源。比如我们设置了超时时间为1s,如果短时间内有大量请求在1s内都得
不到响应，就意味着这个服务出现了异常，此时就没有必要再让其他的请求去访问这个依赖
了，这个时候就应该使用熔断器避免资源浪费。
服务降级
有服务熔断，必然要有服务降级。
所谓降级，就是当某个服务熔断之后，服务将不再被调用，此时客户端可以自己准备一个本
地的fallback（回退）回调，返回一个缺省值。 例如：(备用接口/缓存/mock数据)这样做，虽然服务水平下降，但好歹可用，比直接挂掉要强，当然这也要看适合的业务场
景。
好，同学们又有疑问了，老师讲了这么多理论，那么到底怎么来实际落地呢？
好，那么接下来将实际落地的实现。