论构建可扩展的控制平面

# 构建可扩展的控制平面 来源：https://www.allthingsdistributed.com/2026/08/on-building-scalable-control-planes.html --- 2026年8月4日• 3756字 题图 *Zak van der Merwe（https://www.linkedin.com/in/zak-van-der-merwe-36a7b33a8/）在 AWS 的整个职业生涯都在构建控制平面。先是为 EC2，现在为 DSQL。从表面看，控制平面看起来相当无趣：它记录应该存在什么，并使其与实际存在的东西保持一致。没有人毕业时会梦想着构建一个控制平面，但 Zak 会第一个告诉你，如果你喜欢解决分布式系统中的难题，很少有比这更好的地方。在那里，许多难题汇聚在一起，而你所做的决定将决定一项服务能否在自身增长中存活。* *如果你一直在关注Marc Brooker（https://brooker.co.za/blog/2026/07/19/dsql-paper.html）和Marc Bowes（https://marc-bowes.com/）关于 DSQL 的文章，这是一篇很好的姊妹篇，它揭开帷幕，展示从一开始就以控制平面工程师为考量来设计数据库意味着什么。* *–W* --- ## 构建可扩展的控制平面 我在 AWS 工作了近十四年，几乎全部时间都在构建控制平面。这不是任何人会为自己规划的职业路径。没有人会从大学毕业时想：“我要把未来十年花在确保云服务的记账层保持可用上。”但我就在这里，而且我认为我仍然在这里的原因是，控制平面原来是许多有趣问题所在的地方，即使需要一段时间才能看清楚这一点。 在加入亚马逊之前，我在开普敦一家电信公司工作，那里大概有十台服务器，全都放在办公室后面的一个房间里，而且每一台都有自己的名字。你会 SSH 登录进去，和同事共享它们，如果出了问题，你可以走过去处理。那就是我对“运行基础设施”的全部心智模型。服务器是你逐台了解、刻意照料、并作为一个集合来推理的东西，因为数量少到可以装进脑子里。 我提到这一点，并不是因为这不是一个常见的背景，而是因为不到二十年前这种情况太普遍了，我认为这就是值得说出来的原因。也许你的版本是一个小型 Kubernetes 集群，或者几个 RDS 实例，你可以将整个系统可视化，可以给各个部分命名，当某部分故障时，你知道是哪个部分坏了。那种熟悉自己的基础设施的感觉让人安心，而这让故事的下一个部分真正难以描述，因为当我加入 EC2 时，那种感觉就完全消失了。 说实话，刚开始的时候，我并不真正理解 EC2 是如何运作的。我一直在试图将它映射回我所知道的东西。如果我启动一个实例，而底层服务器挂了，会发生什么？我的虚拟机会以某种方式被传送到另一台宿主机上吗？云是如何创造出硬件故障无关紧要这种错觉的？我无法将这一切与我所知的运行软件的知识相协调。 我在 EC2 的第一份工作是做机群健康检查，ping 每台服务器，试图判断它是否健康，而我所发现的与“魔法”恰恰相反。事情一直在失败。宿主机宕机、硬件行为异常、磁盘损坏。我看到了 EC2 的内幕，那里一片混乱。我的心智模型从“服务器是需要保护珍贵之物”变成了“一切随时都在着火”。 花了好一阵子才摆脱这种感觉，但最终我开始意识到，这些故障只是浩瀚的正常运行海洋中的微小水滴。系统只是运行在一个故障成为常态、统计上必然发生、而非紧急事件的规模上。而让系统在那个规模下无需人类对每个故障做出响应就能运行、让一切保持运转的，就是***控制平面***。 无论从哪个角度看，我在 AWS 的岁月都在构建控制平面上度过。每个 AWS 服务都有一个控制平面，我喜欢把它们看作我们不为人知的英雄。它们工作得越好，就越没有人注意到它们。它们是你无需给服务器命名的原因，也是当硬件故障时，你作为客户永远不必处理它的原因。我有机会为两个主要的 AWS 服务构建控制平面：EC2 和 DSQL。它们相隔近十年，然而构建其中一个所得到的艰难教训，直接导致了另一个的设计，这就是我今天想讲的故事。 ## 到底什么是控制平面？https://www.allthingsdistributed.com/2026/08/on-building-scalable-control-planes.html#what-is-a-control-plane-anyway 在这一点上，我可能应该更好地解释一下我所说的控制平面是什么意思，以及为什么我觉得它们有趣。我会以 EC2 为例，因为那是我学到大部分知识的地方。 我的理解是，每个服务都有一个数据平面和一个控制平面。数据平面是一组核心能力，是原始计算能力、硬件、网络。控制平面是这些能力与客户之间的管道。它把数据中心中物理存在的东西，以你能够实际消费并从中获得价值的格式呈现给你。没有控制平面，你就得回到 SSH 登录某处壁橱里命名服务器的方式。有了它，你可以通过一次 API 调用启动一千台机器，而无需考虑它们在哪里。 来自开普敦的 EC2 架构图（这就是我们在开普敦办公室可视化 EC2 架构的方式。大量使用笔、纸和便利贴。）EC2 涉及数千名工程师，以及多到任何人都无法全部记住的功能，然而控制平面，从概念上讲……其实很简单。被剥离到最简，EC2 让你在云端租用一台虚拟机（VM），而控制平面的工作就是为你创建和拆除这些 VM。 我喜欢用恒温器来类比，因为它不断测量温度，知道事物应该在什么状态，并且总是把系统推向正确的方向。这就是我们的控制平面所做的工作。它是一个持续循环，观察世界的状态，将其与应该成立的真理进行比较，并纠正差异。当你启动一个 VM 时，控制平面记录应该存在一个 VM，在正确的数据中心找到一台物理服务器，设置镜像，配置网络，然后启动它。之后，如果那台服务器因任何原因消失，控制平面会注意到并更新其记录以反映现实。它总是在协调“是什么”与“应该是什么”。 团队反复讨论、几乎到了口头禅程度的一件事是：无论控制平面发生什么，已经在运行的 VM 都需要继续工作。我们称之为静态稳定性，这听起来显而易见，因为正在运行的 VM 当然应该继续运行。但在大规模场景下，显而易见的事情最难保护，因为每一项新功能、每一次变更、每一个依赖都是意外违反这一保证的机会。维护它决定了是出现客户无法启动新资源的停机，还是所有一切都停下来的停机。两者都糟糕，但后者灾难性得多。EC2 是静态稳定的，这一事实在我早期给了我一些安慰。 EC2 团队在让“糟糕的日子”变得罕见方面做得非常出色。但理解糟糕的日子是什么样的，塑造了我对构建控制平面的大量认知。 ## 生活在控制平面内部https://www.allthingsdistributed.com/2026/08/on-building-scalable-control-planes.html#living-inside-the-control-plane 要理解糟糕的日子是如何开始的，了解控制平面如何存储状态会有所帮助。在 EC2 控制平面的核心是一个关系数据库。当客户调用 RunInstances API 启动一个 VM 时，最关键的事情是控制平面将一行写入其数据库：客户 X 现在拥有 VM Y。此时 API 才能安全返回。 实际上，单个`RunInstances`请求会触发微服务和宏服务之间成百上千次的内部 API 调用。其中许多服务拥有自己的数据库，记录自己的状态。多年来这已经变得多么复杂，再怎么夸张也不为过，但在所有这些复杂性的最底层，是一个 MySQL 数据库，而该数据库中的内容应该与现实匹配。 事情出错的最简单方式也是最可怕的。有时主数据库服务器直接宕机。我们的解决方案是热备，即一台持续从主库复制的备份服务器，理想情况下只落后几毫秒。当主库故障时，我们会切换到备库，这可以将停机限制在几秒内。团队是通过多年的运维实践赢得这一点的：构建工具、编写运行手册、训练值班工程师在压力下执行切换。但几秒的停机仍然意味着凌晨 3 点寻呼机被触发，并要求人类在信息不完整的情况下做决策。我们一直问自己，架构能否将人类完全移出这个循环。 更缓慢、更慢性的问题是确保我们的 MySQL 数据库能跟上业务增长。仔细想想这件事相当令人沮丧，因为数据平面承担了所有繁重的工作，比如下载 VM 镜像、配置网络、运行工作负载，而数据库只是跟踪存在什么。我们每启动一个实例，就意味着对数据库进行更多的插入、更新和读取，最终记账员跟不上工人的节奏。 于是我们引入了更多从主库复制的服务器，并将它们用作只读副本。许多 EC2 API 并不做任何改变，它们只是描述你当前资源的状态（你有多少 VM 等等）。我们将这些只读 API 的流量发送到新的只读副本，这极大地减轻了主数据库服务器的负载。这是任何试图扩展关系数据库的团队的标准做法。顺便说一句，这些只读副本构成的机群正是 EC2 API 最终一致性的原因，而且正如Marc Brooker所写（https://brooker.co.za/blog/2025/11/18/consistency.html），这给我们的客户带来了不幸的认知负担。这是我们希望在 DSQL 中做得更好的地方，稍后我们会谈到这一点。 只读副本为我们赢得了时间，但每次写入仍然要通过单一主服务器，最终我们不得不对数据库进行分片。第一阶段对客户是可见的：我们将每个 AWS 区域拆分为多个可用区（AZ），每个可用区拥有自己独立的控制平面和独立的 MySQL 数据库。这既有助于扩展，也有助于可用性，因为可用区独立故障，任何单一故障的爆炸半径都会缩小。它还成为了一个基础构建块，让 AWS 客户能够构建对单个 AZ 丢失具有弹性的架构。第二阶段是内部工作：我们将每个可用区拆分为所谓的“单元”。这两个项目都花了数年工程时间，因为它们需要跨多个服务进行变更。代码库中与数据库交互的每个位置都必须知道路由到哪个分片。按主键进行简单查找是直接的，但任何其他事情，比如跨不贴合分片边界的数据做连接，就会变得麻烦得多。即使是最简单的决策，在这个级别也会产生后果。你是按账户分片还是按资源分片？不同服务会根据访问模式做出不同选择，没有普遍正确的答案。 所有这些还存在一种人文成本，我认为我们谈论得不够。在早期，我们没有自动化来处理现代控制平面可以随手搞定的许多事情。当发现安全漏洞并且整个机群需要打补丁时，我们没有系统可以说“以安全速率更新每台主机”。我们实际上会召集整个团队，细分所有主机，分配班次。开普敦办公室的每个人都会得到一块。去更新你的每台主机，报告状态。这就是没有成熟控制平面时生活的样子，而且这种东西无法扩展。你可以用那种方式为几百台主机的机群打补丁。但你无法用那种方式为几百万台主机的机群打补丁。控制平面最终让人完全脱离了那个循环。 如果你经历过这样的演进过程，扩展悬崖、只读副本的权衡、总是比你想象中耗时的分片项目，你就会知道这是一条漫长而痛苦的道路，而且也是每个构建由关系数据库支撑的成功服务的团队最终都会走上的道路。 ## 寻找数据库的香格里拉https://www.allthingsdistributed.com/2026/08/on-building-scalable-control-planes.html#searching-for-database-xanadu 在 EC2 工作十年后，我对自己理想中的数据库形成了一些强烈的观点。它能随我的业务扩展，而无需什么英雄壮举。它高度可用，更新时无停机，也无需照看服务器。我理想的数据库让我能够利用关系数据模型的力量来对领域建模，并更高效地编写软件。 事实证明，在 2020 年代初，一群来自 AWS 数据库这边的经验丰富的工程师恰好也在思考如何构建这类数据库。这些工程师是 EC2 等服务的“移民”，亲身感受过运维关系数据库的痛苦。他们也在研究从 DynamoDB 等大规模无服务器数据库运维中吸取的教训，并设想如何将其应用到关系数据库上。 他们想对数据库做的事情，就像 EC2 以及真正意义上的 Lambda 对服务器所做的那样。如果你用“头节点”来运维传统数据库，那你就处于“带名字的服务器”的世界，就像我加入 EC2 之前那样。理想的数据库会让你免于思考“带名字的数据库”。相反，它会有一个控制平面*替你*处理所有这一切，让你只需将数据库看作一个始终可用的逻辑端点，在扩展和收缩时都能如此。 大约在 2021 年，这个项目真正开始加速。我们想出了一种似乎能实现理想数据库承诺的架构。我有机会加入团队，开始构建它的控制平面。这个服务后来在 2025 年以Amazon Aurora DSQL（https://aws.amazon.com/rds/aurora/dsql/）的形式正式发布。 让我们快速回顾一下 EC2 经历过的主要痛点，再看看 DSQL 上的生活有什么不同——特别是对控制平面构建者而言。 在 DSQL 中，没有一个服务器在运行你的数据库。DSQL 为每个连接启动一个 Firecracker 微型虚拟机，这意味着每个连接都有自己小型头节点。如果一个连接失败，只会影响那一个连接，而不是整个应用程序。没有人被寻呼，没有人需要决定切换。我不再管理备库，因为架构已经将人从这个痛苦的循环中完全移除了。 扩展读取是我们花了多年解决的另一个问题，需要手动添加副本并接受最终一致性作为代价。DSQL 会自动添加只读副本，事实上这正是我帮助构建的控制平面的主要工作之一。如果你的应用程序突然出现读流量高峰，DSQL 能处理它，而且读取始终是强一致的。在多年告诉客户“稍后再试”之后，这个特性仍然让我感到震撼。它从根本上简化了任何基于 DSQL 构建的控制平面的架构，也将认知税从