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

阿里技术

于 2024-06-05 13:57:47 发布

阅读量1k

点赞数 10

文章标签：架构 java 大数据 Master-Worker Master

本文链接：https://blog.csdn.net/AlibabaTech1024/article/details/139470525

版权

作者：石超

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 更容易做分批灰度发布。