3.7.5、雪崩效应

雪崩效应

在IO型服务中，假设服务A依赖服务B和服务C，而B服务和C服务有可能继续依赖其他的服务， 继续下去会使得调用链路过长。如果在A的链路上某个或几个被调用的子服务不可用或延迟较高，则会导致调用A服务的请求被堵住。

堵住的请求会消耗占用掉系统的线程、io等资源，当该类请求越来越多，占用的计算机资源越来越多的时候，会导致系统瓶颈出现，造成其他的请求同样不可用，最终导致业务系统崩溃，雪崩效应。

常见的导致雪崩的情况有以下几种：

程序bug导致服务不可用，或者运行缓慢
缓存击穿，导致调用全部访问某服务，导致down掉
访问量的突然激增。
硬件问题，这感觉只能说是点背了⊙︿⊙。

容断机制

当服务者无法正常为消费者提供服务时 ，如请求超时、后台服务无响应、后台服务异常等， 通过容断机制直接返回统一处理结果，并对下次请求进行同样处理，直到后台服务功能正常。

微服务的提供者可能是一个基础服务也能是一个聚合服务，当消费者的请求到来，如果服务中的一个或者几个无法正常工作（挂了），此时在不做任何处理的情况下，消费者只能等待，直到超时，在高负载场景下，此类问题可能会导致服务提供者的资源耗尽甚至整个系统崩溃。

限流机制

防止爆发式流量直接压到后台服务实例，造成资源耗尽、甚至应用崩溃

控制访问流量，通过指定的策略消减流量（如网络层面限制访问流量、后服务实例使用技术手段限制并发数量等），使得落到后台服务实例的请求在能承受的范围内。高并发是常常讨论的话题，如何限流，以及服务的实例能承受的范围是多大，什么情况下需要增加服务实例，调整资源，都需要结合实际进行严格的测试。

这样一个场景，provider是一个核心服务，给N个consumer提供服务，突然某个consumer抽风，流量飙升，占用了provider大部分机器时间，导致其他可能更重要的consumer不能被正常服务。

所以，provider端，需要根据consumer的重要程度，以及平时的QPS大小，来给每个consumer设置一个流量上线，同一时间内只会给A consumer提供N个线程支持，超过限制则等待或者直接拒绝。

常见的限流算法有：令牌桶、漏桶。计数器也可以进行粗暴限流实现。

降级机制

当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。

弃卒保帅，最终目的是保证核心服务可用，即使是有损的。但是核心服务肯定是无法舍弃的，舍弃也就意味着应用系统无法正常工作。只能是一种保障或者拯救措施。

降级和熔断的区别

1. 触发原因不太一样，服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑；
2. 管理目标的层次不太一样，熔断其实是一个框架级的处理，每个微服务都需要（无层级之分），而降级一般需要对业务有层级之分（比如降级一般是从最外围服务开始）