重庆专业网站建设公司哪家好,如何申请域名后缀,软件软件开发,国内免费的ip地址Spring Cloud Alibaba 雪崩效应和容错解决方案 文章目录1. 雪崩效应1.1. 举个例子#xff1a;2. 常见的容错方案#xff1a;2.1.超时#xff1a;2.2. 限流#xff1a;2.3. 仓壁模式#xff1a;2.3.1. 现实中的仓壁模式#xff1a;2.3.2. 软件中的仓壁模式#xff1a;2.4…Spring Cloud Alibaba 雪崩效应和容错解决方案
文章目录1. 雪崩效应1.1. 举个例子2. 常见的容错方案2.1.超时2.2. 限流2.3. 仓壁模式2.3.1. 现实中的仓壁模式2.3.2. 软件中的仓壁模式2.4. 断路器模式2.4.1. 现实中的断路器2.4.2. 软件中的断路器1. 雪崩效应
微服务架构的系统包含很多微服务微服务之间通过轻量级的通信机制进行通信构建成了一个完成的应用系统。但是每个微服务不能保证100%可用的网络呢有时也会出问题
1.1. 举个例子
现在有一个高并发的应用系统它包含4个微服务一开始每个微服务都是正常的然后在某一个时间点微服务A突然挂了所有的实例都挂了而这是一个高并发的应用系统.
B服务还在分光的调用A服务的API呢现在A服务挂了现在B服务发往A服务的请求就会强制等待 直到请求超时而在java程序里面一个请求呢往往对应着一个线程如果请求被强制等待那么线程就会被强制阻塞一直到请求超时的时候这个线程才会被释放由于这是一个高并发的应用系统阻塞的线程就会越来越多而线程对应的服务器的计算资源比方说内存、cpu如果不作任何处理的话终有一天B服务所在的服务器再也无法创建新的线程了于是B服务也挂了。
简言之B服务是被A服务拖垮的同样的道理C服务和D服务调用B服务C和D 也会被B服务拖垮我们把基础服务故障导致上层服务故障并且这个故障不断放大的过程称之为雪崩效应这样现象就像是滚雪球一样越滚越大最后整个服务可能都挂了在一些英文书里面常常把雪崩效应称之为cascading failure 级联失效 级联故障。
2. 常见的容错方案
A服务挂了B服务做好了容错就不会被A服务拖垮。 业界常使用的使用这些容错方案可以有效的避免雪崩效应
2.1.超时
比如说为每一次请求设置超时时间假若为1s不管这次请求会不会成功这个线程就会被释放这样只要线程释放的速度够快那么B服务就不会被A服务拖垮了
2.2. 限流
在一个高并发的应用系统中采坑能存在大量的线程阻塞如果我们经过评估发现微服务B的实例最大能够承载的qps是1000那么我们就可以为微服务B设置一个限流的值比方说是800qps或者其他一个低于1000qps的阈值这个时候只要某一个实例达到这个阈值再有流量进来就直接拒绝通过这种方式也实现了对自己的保护至少B服务不会被A服务拖到宕机。
2.3. 仓壁模式
2.3.1. 现实中的仓壁模式
泰坦尼克号号称永不沉没的船是基于技术而言的用到了仓壁模式一条船被划分了3个船舱每个船舱之间用2块钢板焊死即使某一个船舱进水也不会影响其他船舱当时泰坦尼克号的设计能够容纳2个主仓的进水船依然能够正常工作所谓主仓就是中间两边两个比较大的仓。3个仓进水了超出了泰坦尼克号的容错能力于是就悲剧了。
2.3.2. 软件中的仓壁模式
AController 有自己独立的线程池比方叫thread-pool-1 coreSize10 调用其他API挂了对于高并发的应用这个线程池就满了然后去排队再然后就直接拒绝了线程池大家应该是很熟悉线程池有自己的拒绝策略。 同理BController 有自己独立的线程池比方叫thread-pool-2 coreSize10 此时AController 线程池满了或者拒绝了不会影响BController 因为都有自己的线程池。 如果用船舱的例子类比的话现在这2个Controller 就好比2个船舱Controller 之间用2个独立的线程池焊死AController 类中的API调不通就相当于这个船仓进水了那么你的船舱进水和我的船舱没有关系这就是仓壁模式。
2.4. 断路器模式
断路器是服务容错里面最高端的方案
2.4.1. 现实中的断路器
每个人家里都有断路器就是电闸。 断路器说白了就是监控加开关它会实时监控电路的状态但发现某段时间内电流过大他就认为电路短路了然后就会跳闸从而保护电路不被烧毁。
2.4.2. 软件中的断路器
举个栗子 比如说AController 中调用API时我监控5s以内的错误率、错误次数等等如果错误率达到阈值又或者错误次数达到一定的阈值我就认为调用的服务已经挂了然后就跳闸不去调用远程的api服务了。
正常状态下断路器关闭
