微服务开发的雪崩效应

醉酒当歌 提交于 2019-11-29 05:00:55

一)什么是雪崩效应

其实雪崩很好理解,雪崩就是一个点的触发灾难引起大规模的灾难伤害。那么微服务中的雪崩效应也是如此,在微服务中服务和服务之间的依赖关系是非常的多的,如果其中的一个服务出现问题,那么与之关联的服务或者依赖此服务的其他服务因为此服务的宕机,挤压大量请求无法给用户进行数据的反馈,而引起一系列服务的出现问题。
如图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次请求合并成一个的请求进行发送

标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!