当前位置:   article > 正文

Master-Worker 架构的灰度发布难题

Master-Worker 架构的灰度发布难题

作者:石超

Master-Worker 架构的灰度发布难题

一、前言

Master-Worker 架构是成熟的分布式系统设计模式,具有集中控制、资源利用率高、容错简单等优点。我们数据中心内的几乎所有分布式系统都采用了这样的架构。



我们曾经发生过级联故障,造成了整个集群范围的服务中断。这让我们反思到 Master-Worker 架构难以有效的分批灰度发布的问题。本文试图分析其中原因,并尝试提出几种解决方案。

二、Master-Worker 架构

Master-Worker 架构有时也被称为 Master-Server 架构 或 Master-Slave 架构。



在实践中,为了避免 Master 成为单点故障,Master 通常由多个节点用 Raft 组成的服务,以一主多从的形式出现。有时在一个 Raft 服务中,我们也用 Master 和 Slave 述语指代主和从节点。为了避免混淆,这里我们称为 Master 的“主节点”和“从节点”,主从节点统称为“一组 Master 节点”。



据系统的规模的不同,Master 节点通常能够管理数台至数万台 Worker 节点。



下面介绍几种常见的 Master-Worker 架构。第一种是经典的分布式系统架构,后两种是常见变种。其实它们都披着外衣而本质相的架构。

2.1 经典架构

根在有些系统中,用户总是需要访问 Master 才能得到服务。若 Master 故障,则整个集群服务中断。需要指出的是,这里说的故障不一定是程序崩溃,还包括性能下降、死锁等其他形式的功能失效。Raft 的高可用机制能很好处理如宕机、程序崩溃等明确的问题,却难以处理这些“半死不活”的问题。我们曾经遇到过部分线程失效而心跳线程仍然好好的活着的问题。墨菲定律说,只要可能发生的事,最终都会发生。在我们这样云计算数据中心规模和长时间的部署中,各种稀奇古怪的问题都会被撞见。

2.2 数据面和控制面分离

在数据面和控制面分离的设计中,用户直接和数据面的节点交互。有中心化部署的管控节点,负责负载均衡、宕机恢复、限流等集中工作。用户的请求路径不经过中心管控节点。中心管控节点和数据面节点构成 Master-Worker 架构。尽管数据面划分了多个集群,但中心管控同时连接了多个集群的数据面,同样有级联故障隐患。设想这样的场景:中心管控升级后,发送了新格式请求到数据节点。后者无法正确处理新格式的请求,产生 coredump。

2.3 有网络功能的基础组件库

程序倚赖的公共基础组件,如安全、运维、监控等,很多以 SDK 库的形式嵌入在服务进程中。SDK 作为客户端和公共组件服务的服务端通讯,或上报信息,或拉取配置。这样,SDK 和服务端也构建经典的 Master-Worker 架构。这些 SDK 尽管是旁路系统,但仍然有机会“兴风作浪”,像上面“数据面和控制面分离”一节那样引发数据节点的级联故障。公共服务通常被众多服务使用,一旦发生这样的问题,影响面积将更大。

三、灰度发布的难题

灰度发布是防范故障的最重要手段。典型的灰度发布是这样工作的:在一个集群中,依次升级每个节点,同时观察整个服务有单机异常或整体服务受损。一旦观测到服务受损,则立即中止发布。由于分布式系统自身具有自动恢复(failover)能力,除非是如 coredump 之类的明显问题,从服务整体角度观测需要一定时间。

3.1 分片架构

在普通服务中,这样的灰度发布机制能很好工作。考虑一个由多个节点组成的服务,分批发布,每批一个节点。每批之间观察请求成功率,若跌破阈值则中止发布。现在我们发布一个带 bug 的新版本。在完成第二批发布后,我们观察到系统请求成功率下跌超过阈值,因此中止发布。



这个模型比较简单,但足够说明问题。在实际中,自动恢复机制能掩盖错误。例如,网关服务能够将失败的请求发送至另外的节点重试。但我们仍然能通过蛛丝马迹发现故障。在前述例子中,我们能够通过网关重试率指标来识别到问题。

3.2 Master-Worker 架构

然而在 Master-Worker 架构中,灰度发布机制却不是总是有效。让我们看看在这样的系统中如何进行灰度发布,并分析它无效的原因。



假如现在有 A、B、C 三个 master 节点,其中 B 是主节点。灰度发布步骤如下:

1.升级 A 到新版本。

2.升级 C 到新版本。

3.主从切换,由新升级的 A 作为主节点。

4.升级 B 到新版本。



在执行每步时,我们同样要观察现有服务是否受损。一旦服务受损就立即中止发布。用这样的方法,看似做了灰度,其实第三步主从切换的有很大的风险。考虑假想的极端情况:A 的新版本增加了新的功能,在 A->Worker 心跳等广播类报文中增加新的请求字段。而 Worker 恰好无法处理这个新增字段,导致了死锁或程序崩溃。这样就会导致整个集群内大范围的服务中断。



灰度发布机制对防范此类问题无能为力。Master 的主节点的新代码,只有在第三步主从节换后才能运行起来。一旦新代码被运行起来,在 Master 这样重要的节点,对整个集群可能产生重大影响。这些影响是 0 或 1 的影响,而不是渐近式的影响。因此,在这样的架构无法有效实现灰度发布。

四、解决方案

解法一:Master 分片

在经典的 Master-Worker 架构中,Master 主节点是单体式的。我们可以将它的功能拆分成到多个分片,让每个分片能够单独地升级。这样,整个系统的发布变成渐近式的,给我们创造出了观察窗口。



这种方法能够防止 Master 服务自身出现重大故障。但如果 Master 和 Worker 仍然是高度互联的,无法避免故障沿网络传播至 Worker 所有节点,最终造成服务中断。此外,Master 承担的某些功能天然是集中式的,也就无法用这个方法拆分成多个分片。

解法二:分批推送

另一个思路是切断故障的快速传播途径。级联故障之所以发生,是因为 master 在升级到新版本后立即运行了新的代码路径,发送了新的 RPC 给 worker 节点,从而造成 worker 节点运行到了未经测试的代码路径。这个过程是立时发生,没有分批灰度的。我们可以在这里也引入分批灰度的机制。



这个方案也有短板。在复杂系统中 Master->Server 交互众多,很难针对每个交互都增加这样分批灰度的限制。实际中,分批机制一般只能覆盖到几个重点功能。

解法三:小而稳的 SDK 库

最后一个解法是为公共服务 SDK 库量身定制的。DNS 是最简单的带有网络功能的 SDK 库,它却很少出问题。究其原因,是因为它的功能足够简单。借鉴这个思路,我们可以把 SDK 库做得简单,控制代码量在一千行以内,经过充分测试,能做到近乎 bug-free。

据我所知,能做到这个标准最复杂的库是 sqlite,它有 15 万行代码,但分支覆盖率达到了恐怖的 100%。考虑到我们实际的工程水平,一千行代码是我们能做到的极限。如果 SDK 的功能复杂,无法精减,那么可以将部分逻辑拆分到本机部署的 agent。而 agent 总是比 SDK 更容易做分批灰度发布。

五、结语

防范集群范围的级联故联是分布式系统中的难题。本文提出了三种方法,但它们都有各自的局限。在写作本文时,我找了很多同事讨论,也在互联网上搜索,以及问 ChatGPT,但是都没有得到令人满意的答案。本文抛砖引玉,如果读者想到更好的方法,欢迎一起讨论。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/羊村懒王/article/detail/691027
推荐阅读
相关标签
  

闽ICP备14008679号