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

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

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

▲点击图片可查看大图

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

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

一、熔断是什么

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

▲图片来源于网络,版权归原作者所有

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

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

二、熔断怎么做

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

然后,这四步走分别是:

  1. 定义一个识别是否处于“不可用”状态的策略
  2. 切断联系
  3. 定义一个识别是否处于“可用”状态的策略,并尝试探测
  4. 重新恢复正常

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

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

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

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

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

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

最终会形成这样这样的一段代码。

全局变量 errorcount = 0; //有个独立的线程每隔10秒(时间窗口)重置为0。
全局变量 isOpenCircuitBreaker = false;

//do some thing...

if(success){
    return success;
}
else{
    errorcount++;
    if(errorcount == 不可用阈值){
        isOpenCircuitBreaker = true;
    }
}

切断联系

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

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

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

这就是常说的「fail fast」机制。就是在前面提到的代码段之前增加下面的这段代码。

if(isOpenCircuitBreaker == true){
    return fail;
}

//do some thing...

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

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

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

  • 阈值。比如,在10秒内出现100次“调用成功”并且耗时都小于1秒。
  • 百分比。比如,在10秒内有95%请求“调用成功”并且98%的请求小于1秒。

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

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

这个用代码表述大致是这样。

全局变量 successCount = 0; 
//有个独立的线程每隔10秒(时间窗口)重置为0。
//并且将下面的isHalfOpen设为false。

全局变量 isHalfOpen = true;
//有个独立的线程每隔30秒(间隔时间)重置为true。

//do some thing...
if(success){
    if(isHalfOpen){
        successCount ++;
        if(successCount = 可用阈值){
            isOpenCircuitBreaker = false;
        }
    }
    
    return success;
}
else{
    errorcount++;
    if(errorcount == 不可用阈值){
        isOpenCircuitBreaker = true;
    }
}

另外,尝试探测本质上是一个“试错”,要控制下“试错成本”。所以我们不可能拿100%的流量去验证,一般会有以下两种方式:

  1. 放行一定比例的流量去验证。
  2. 如果在整个通信框架都是统一的情况下,还可以统一给每个系统增加一个专门用于验证程序健康状态检测的独立接口。这个接口额外可以多返回一些系统负载信息用于判断健康状态,如CPU、I/O的情况等。

重新恢复正常

一旦通过了衡量是否“可用”的验证,整个系统就恢复到了“正常”状态,此时需要重新开启识别“不可用”的策略。就这样,系统会形成一个循环。

▲点击图片可查看大图

这就是一个完整的熔断机制的面貌。了解了这些核心思想,用什么框架去实施就变得不是那么重要了,因为大部分都是换汤不换药。

上面聊到的这些可以说是主干部分,还有一些最佳实践可以让你在实施熔断的时候拿捏的更到位。

三、做熔断的最佳实践

什么场景最适合做熔断

一个事物在不同的场景里会发挥出不同的效果。以下是我能想到最适合熔断发挥更大优势的几个场景:

  • 所依赖的系统本身是一个共享系统,当前客户端只是其中的一个客户端。这是因为,如果其它客户端进行胡乱调用也会影响到你的调用。
  • 所以依赖的系统被部署在一个共享环境中(资源未做隔离),并不独占使用。比如,和某个高负荷的数据库在同一台服务器上。
  • 所依赖的系统是一个经常会迭代更新的服务。这点也意味着,越“敏捷”的系统越需要“熔断”。
  • 当前所在的系统流量大小是不确定的。比如,一个电商网站的流量波动会很大,你能抗住突增的流量不代表所依赖的后端系统也能抗住。这点也反映出了我们在软件设计中带着“面向怀疑”的心态的重要性。

做熔断时还要注意的一些地方

与所有事物一样,熔断也不是一个完美的事物,我们特别需要注意2个问题。

首先,如果所依赖的系统是多副本或者做了分区的,那么要注意其中个别节点的异常并不等于所有节点都存在异常,所以需要区别对待。

其次,熔断往往应作为最后的选择,我们应优先使用一些「降级」或者「限流」方案。因为“部分胜于无”,虽然无法提供完整的服务,但尽可能的降低影响是要持续去努力的。比如,抛弃非核心业务、给出友好提示等等,这部分内容我们会在后续的文章中展开。

四、总结

本文主要聊了熔断的作用以及做法,并且总结了一些我自己的最佳实践。

上面的这些代码示例中也可以看到,熔断代码所在的位置要么在实际方法之前,要么在实际方法之后。它非常适合AOP编程思想的发挥,所以我们平常用到的熔断框架都会基于AOP去做。

熔断只是一个保护壳,在周围出现异常的时候保全自身。但是从长远来看平时定期做好压力测试才能更好的防范于未然,降低触发熔断的次数。如果清楚的知道每个系统有几斤几两,在这个基础上再把「限流」和「降级」做好,这基本就将“高压”下触发熔断的概率降到最低了。

Question: 

你觉得还有什么时候需要熔断呢?欢迎给我留言交流哦。

相关文章:

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏vue+shiro

基于vue(element ui) + ssm + shiro 的权限框架

现在的Java世界,各种资源很丰富,不得不说,从分布式,服务化,orm,再到前端控制,权限等等玲琅满目,网上有句话说,语言框架迭代太快了,我学不动了,不如回去搬...

1K2
来自专栏田小康的专栏

腾讯云项目实践:App 性能监控方案

本文是一个依托腾讯云搭建App性能监控方案(APM)的栗子,篇幅不长,欢迎有兴趣的同学留言讨论哈 。

7820
来自专栏玉树芝兰

安装 Python 软件包遇错误,怎么办?

本文通过一个命令行转换 pdf 为词云的例子,给你讲讲 Python 软件包安装遇挫折时,怎么处理才更高效?

1582
来自专栏CSDN技术头条

《英雄联盟》支撑最高750万同时在线用户的聊天服务打造

【编者按】在2013年初马化腾被问及“过去两年腾讯在海外投资中最成功的案例是什么”时,他毫无疑问的回答:“投资美国的Riot Games,做出《英雄联盟》。”在...

27710
来自专栏CSDN技术头条

.NET技术+25台服务器怎样支撑世界第54大网站

【编者按】StackOverflow是一个IT技术问答网站,用户可以在网站上提交和回答问题。当下的StackOverflow已拥有400万个用户,4000万个回...

2637
来自专栏coding

程序员如何优雅使用mac

在折腾windows和linux一段时间内,饱经各种摧残的我,虽然掌握了一些不为人知的黑科技,终于对此感到厌倦,转投mac阵营。入手了2017款的Apple M...

1982
来自专栏张善友的专栏

让应用程序与您形影相随-PortableApps.com

作为一名 IT 专业人员,您可能会经常需要从一台计算机移到另一台计算机。当您这样做时,您可能会希望能拥有一组随时可用的标准应用程序、工具和文档。满足这些需求的一...

2165
来自专栏程序你好

为什么应该使用RESTful Web服务设计

你可能负责一个API。也许你正准备投入制作一个,并且很期待开始。但是要小心,因为好的API设计可能很难。

3633
来自专栏IT大咖说

Metrics:让微服务运行更透明

摘要 让微服务运行状态清晰可见。 Metrics是什么 直译是“度量”,不同的领域定义有所区别,在微服务领域中的定义: “对微服务的某个指标给予一个可量化程度的...

52112
来自专栏逸鹏说道

.NET技术+25台服务器怎样支撑世界第54大网站

英文原文:StackOverflow Update: 560M Pageviews A Month, 25 Servers, And It's All Abou...

3967

扫码关注云+社区

领取腾讯云代金券