服务雪崩效应及如何应对

服务的雪崩

在微服务之间进行服务调用是由于某一个服务故障，导致级联服务故障的现象，称为雪崩效应。雪崩效应描述的是提供方不可用，导致消费方不可用并将不可用逐渐放大的过程。 在分布式系统中,由于网络原因或自身的原因,服务一般无法保证 100% 可用。如果一个服务出现了问题，调用这个服务就会出现线程阻塞的情况，此时若有大量的请求涌入，就会出现多条线程阻塞等待，进而导致服务瘫痪。​ 由于服务与服务之间的依赖性，故障会传播，会对整个微服造成严重后果，这就是服务故障的 “雪崩效应” 。

Service A的流量波动很大，流量经常会突然性增加！那么在这种情况下，就算Service A能扛得住请求，Service B和Service C未必能扛得住这突发的请求。此时，如果Service C因为抗不住请求，变得不可用。那么Service B的请求也会阻塞，慢慢耗尽Service B的线程资源，Service B就会变得不可用。紧接着，Service A也会不可用，这一过程如下图所示

如何处理

​ 服务器的雪崩效应其实就是由于某个微小的服务挂了,导致整一大片的服务都不可用.类似生活中的雪崩效应,由于落下的最后一片雪花引发了雪崩的情况.​ 雪崩发生的原因多种多样，有不合理的容量设计，或者是高并发下某一个方法响应变慢，亦或是某台机器的资源耗尽。我们无法完全杜绝雪崩源头的发生，只有做好足够的容错，保证在一个服务发生问题，不会影响到其它服务的正常运行。

常见的容错思路有隔离、超时、限流、熔断、降级这几种

隔离

比如服务A内总共有100个线程, 现在服务A可能会调用 服务B,服务C,服务D.我们在服务A进行远程调用的时候,给不同的服务分配固定的线程,不会把所有线程都分配给某个微服务. 比如调用服务B分配30个线程,调用服务C分配30个线程，调用服务D分配40个线程. 这样进行资源的隔离，保证即使下游某个服务挂了，也不至于把服务A的线程消耗完。比如服务B挂了，这时候最多只会占用服务A的30个线程,服务A还有70个线程可以调用服务C和服务D.

超时机制

在上游服务调用下游服务的时候，设置一个最大响应时间，如果超过这个时间，下游未作出反应，

就断开请求，释放掉线程。

限流机制

限流就是限制系统的输入和输出流量已达到保护系统的目的。为了保证系统的稳固运行,一旦达到

的需要限制的阈值,就需要限制流量并采取少量措施以完成限制流量的目的。

熔断机制

在互联网系统中，当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整

体的可用性，可以暂时切断对下游服务的调用。这种牺牲局部，保全整体的措施就叫做熔断。

服务熔断一般有三种状态：

熔断关闭状态（Closed）
服务没有故障时，熔断器所处的状态，对调用方的调用不做任何限制

熔断开启状态（Open）
后续对该服务接口的调用不再经过网络，直接执行本地的fallback方法

半熔断状态（Half-Open）
尝试恢复服务调用，允许有限的流量调用该服务，并监控调用成功率。如果成功率达到预

期，则说明服务已恢复，进入熔断关闭状态；如果成功率仍旧很低，则重新进入熔断关闭状

态。

降级机制

降级其实就是为服务提供一个兜底方案，一旦服务无法正常调用，就使用兜底方案。

落地方案

sentinel
熔断降级
限流实战
网关限流