1、雪崩问题

假设有一个微服务A，它调用了服务B、服务D，而某时刻服务D挂掉：

服务A要等待服务D的结果，而服务D已经不能正常响应了，此时服务A内部阻塞，不会释放tomcat的连接（此时服务A依赖于服务B的业务还是不受影响）。但随着这种服务A—服务D的请求越来越多，而tomcat的连接数有限，tomcat资源就会耗尽：

此时，再有请求进到服务A，哪怕是不需要访问服务D的请求，服务A也没资源处理了。即某个服务故障，最终导致了依赖它的某个服务也故障了。把这一点放大：

如果后面的服务，和资源耗尽不可用的服务有依赖关系，则后面的服务也会渐渐变得不可用，从而引起整个链路中的所有微服务都不可用：

微服务调用链路中的某个服务故障，引起整个链路中的所有微服务都不可用，这就是雪崩。

2、雪崩问题的四种解决思路

超时处理：设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待

这只能缓解雪崩问题，而不能彻底根除，因为比如设置等待1s就释放1个连接，但一秒钟之内进来了2个请求，终有一天，服务A的资源也可能被耗尽。

舱壁模式：限定每个业务能使用的线程数，避免耗尽整个tomcat的资源，因此也叫线程隔离

如上图，舱壁用木板隔开，哪怕触礁了，也只是被撞破的那一小块进水。对应到程序中，就是将可用线程数分割，服务A调用服务B，最多占用10个线程，服务A调用服务C最多10个线程：

现在哪怕服务A到C出问题了，能占用的tomcat资源也是有限的，不至于所有资源被耗尽（不至于整条船全进水了）。如此就解决了雪崩问题，但造成了一点资源浪费，明知A到C不通了，但还是在消耗资源去请求。

熔断降级：由断路器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求。

比如到服务A–服务D的这个请求，访问了三次，两次失败，即66%异常，阈值如果设为50%，则此时发生熔断，后续再有这个请求过来直接拦截，快速失败，立刻释放资源，从而解决雪崩问题。

流量控制：限制业务访问的QPS，避免服务因流量的突增而故障

以上三种是出现雪崩后的解决方案，流量控制则是预防雪崩，防止服务发生故障。服务不故障，也就不传递给依赖它的服务，也就没有雪崩问题了。当然了，流量控制只是预防了因高并发引起的服务故障。服务故障的原因可不止高并发一种。

小结：

3、服务保护技术选型对比

• 熔断降级策略中，sentinel既可以根据异常比例，也可以根据响应慢的比例
• 在限流和流量整形方面，也优于Hystrix
• Sentinel有控制台，即可视化操作界面
• 最后，Hystrix官方已经不再维护