微服务开发的雪崩效应

一）什么是雪崩效应

其实雪崩很好理解，雪崩就是一个点的触发灾难引起大规模的灾难伤害。那么微服务中的雪崩效应也是如此，在微服务中服务和服务之间的依赖关系是非常的多的，如果其中的一个服务出现问题，那么与之关联的服务或者依赖此服务的其他服务因为此服务的宕机，挤压大量请求无法给用户进行数据的反馈，而引起一系列服务的出现问题。
如图1：
下图是一个的服务依赖流程图，当请求少量的时候，系统能够正常的运行。其中服务U和服务T的请求是比较集中的，用于处理服务X系列请求、服务J系列请求和服务Q、N的请求。当请求量在服务U和T的压力范围内系统是能够正常的请求响应的。

如果当请求量大了并发次数高了，此时服务X涌进大量的请求，交给服务U进行处理，并且此时服务U还在接受其他的请求，并将请求交给服务T，假如此时的服务T因为并发过高，CPU崩掉导致服务器宕机不能将结果返回给服务U，而此时的服务U将堆积大量的请求，并随着不断涌进的请求，最终服务U也会宕掉，接着引起一系列的连锁反应最坏的情况就是整个系统宕掉

二）如何解决雪崩效应

1.降级
超时降级、资源不足时(线程或信号量)降级，降级后可以配合降级接口返回托底数据。 实现一个 fallback 方法, 当请求后端服务出现异常的时候, 可以使用 fallback 方法返回的值。
2.隔离（线程池隔离和信号隔离）
限制调用分布式服务的资源使用，某一个调用的服务出现问题不会影响其他服务调用。
3.熔断
当失败率(如因网络故障/超时造成的失败率高)达到阀值自动触发降级，熔断器触发的快 速失败会进行快速恢复。
4.缓存
提供了请求缓存。
5.请求的合并
提供请求合并。请求的合并其实很简单，比如服务B涌进的500个请求，那么调用服务C的时候就要的发送500次请求，但是这无疑是非常耗费资源和时间的，那么就可以使用请求合并将这500次请求合并成一个的请求进行发送