分布式系统关注点(8)——99%的人都能看懂的「熔断」以及最佳实践

指导 09-04 阅读: 评论:
后台-系统设置-扩展变量-手机广告位-内容正文顶部

当我们工作所在的系统处于分布式系统初期的时候,往往这时候每个服务都只部署了一个节点。

那么在这样的背景下,如果某个服务A需要发布一个新版本,往往会对正在运行的其它依赖服务A的程序产生影响。甚至,一旦服务A的启动预热过程耗时过长,问题会更严重,大量请求会阻塞,产生级联影响,导致整个系统卡慢。

举个夸张的例子来形容:一幢楼的下水管是从最高楼直通到最低楼的,这个时候如果你家楼下的管道口堵住了,那么所有楼上的污水就会倒灌到你家。如果这导致你家的管道口也堵住了,之后又会倒灌到楼上一层,以此类推。

然而实际生活中一旦你发现了这个问题,必然会想办法先避免影响到自己家,然后跑到楼下让他们赶紧疏通管道。此时,避免影响自己家的办法就可被称之为「熔断」。

熔断本质上是一个过载保护机制。这一概念来源于电子工程中的断路器,可能你曾经被这个东西的“跳闸”保护过。

在互联网系统中的熔断机制是指:当下游服务因访问压力过大而响应变慢或失败,上游服务为了保护自己以及系统整体的可用性,可以暂时切断对下游服务的调用。

做熔断的思路大体上就是:一个中心思想,分四步走。

二、熔断怎么做

首先,需秉持的一个中心思想是:量力而行。因为软件和人不同,没有奇迹会发生,什么样的性能撑多少流量是固定的。这是根本。

然后,这四步走分别是:

定义一个识别是否处于“不可用”状态的策略

切断联系

定义一个识别是否处于“可用”状态的策略,并尝试探测

重新恢复正常

定义一个识别是否处于“不正常”状态的策略

相信软件开发经验丰富的你也知道,识别一个系统是否正常,无非是两个点。

是不是能调通

如果能调通,耗时是不是超过预期的长

但是,由于分布式系统被建立在一个并不是100%可靠的网络上,所以上述的情况总有发生,因此我们不能将偶发的瞬时异常等同于系统“不可用”(避免以偏概全)。由此我们需要引入一个「时间窗口」的概念,这个时间窗口用来“放宽”判定“不可用”的区间,也意味着多给了系统几次证明自己“可用”机会。但是,如果系统还是在这个时间窗口内达到了你定义“不可用”标准,那么我们就要“断臂求生”了。

这个标准可以有两种方式来指定。

阈值。比如,在10秒内出现100次“无法连接”或者出现100次大于5秒的请求。

百分比。比如,在10秒内有30%请求“无法连接”或者30%的请求大于5秒。

切断联系

切断联系要尽可能的“果断”,既然已经认定了对方“不可用”,那么索性就默认“失败”,避免做无用功,也顺带能缓解对方的压力。

分布式系统中的程序间调用,一般都会通过一些RPC框架进行。

那么,这个时候作为客户端一方,在自己进程内通过代理发起调用之前就可以直接返回失败,不走网络。

定义一个识别是否处于“可用”状态的策略,并尝试探测

切断联系后,功能的完整性必然会受影响,所以还是需要尽快恢复回来,以提供完整的服务能力。这事肯定不能人为去干预,及时性必然会受到影响。那么如何能够自动的识别依赖系统是否“可用”呢?这也需要你来定义一个策略。

一般来说这个策略与识别“不可用”的策略类似,只是这里是一个反向指标。

阈值。比如,在10秒内出现100次“调用成功”并且耗时都小于1秒。

百分比。比如,在10秒内有95%请求“调用成功”并且98%的请求小于1秒。

稍微不同的地方在于,大多数情况下,一个系统“不可用”的状态往往会持续一段时间,不会那么快就恢复过来。所以我们不需要像第一步中识别“不可用”那样,无时无刻的记录请求状况,而只需要在每隔一段时间之后去进行探测即可。所以,这里多了一个「间隔时间」的概念。这个间隔幅度可以是固定的,比如30秒。也可以是动态增加的,通过线性增长或者指数增长等方式。

同样包含「时间窗口」、「阈值」以及「百分比」。

后台-系统设置-扩展变量-手机广告位-内容正文底部
版权声明

本文仅代表作者观点,不代表Flashempire闪客帝国立场。
本文系作者授权Flashempire闪客帝国发表,未经许可,不得转载。

分享:

扫一扫二维码

扫一扫在手机阅读、分享本文

评论

留言与评论(共有 0 条评论)
   
验证码:

相关推荐