作者：Mohamed Habib · 日期：2026年6月17日 我们最初在一个 Azure 区域内以一台虚拟机开始了 OpenComputer。公司迅速发展，但 Azure 在该区域内无法进一步提高我们的计算配额，我们发现自己在一个固定的 CPU 池中继续增长。因此，我们不得不寻找其他方式来扩展。这篇文章讲述了我们所做的事情，使我们能够保持几乎无限地添加容量。我们将讨论如何将系统拆分为单元，边缘的全局注册表如何决定每个沙盒的所在位置，以及四个云服务提供商如何加起来提供一百万个 CPU。推文来自 Mohamed Habib (@motatoeshq)，2026年6月7日："我们如何将 opencomputer.dev 扩展到 100 万个沙盒"。查看链接：https://twitter.com/motatoeshq/status/2063679701873492299。 交互式架构图，分为四个阶段。阶段 1（1–100 个沙盒）：一个控制平面连接到一个工作节点。阶段 2（100–1K）：同一个控制平面在一个区域内调度三个工作节点。阶段 3（1K–10K）：控制平面加工作节点的单元成为一个单元，两个单元位于一个边缘终止层（Cloudflare Workers + D1 注册表）下，该层将每个创建请求路由到空间最大的单元并接收心跳响应。阶段 4（10K–100K+）：四个单元位于边缘层下，跨区域和云进行重复。现在添加容量是一个部署步骤。单击阶段按钮或输入要创建的沙盒数量，架构将动画匹配。我们的整个容量都位于一个 Azure 区域的配额内 沙盒是完整的虚拟机，虚拟机需要物理硬件，而云服务提供商按区域配给这些硬件。我们的问题始于配给，因此最好首先解释一下它的运作方式。云配额背后的原理 每个云服务提供商都通过区域容量对你进行限制，这基本上是指物理数据中心存在的地方，硬件有限，以及一长串想要使用它的客户。因此，服务提供商以配额的形式分配容量，按总 CPU 数量进行计量。配额从小开始，只有在您建立使用历史记录之后才能增长。工作协议是在一到两周内以大约 50% 的利用率运行您现有的配额，请求增加配额，并让使用数据来证明这一点。第一天请求 10,000 个 CPU，答案肯定是“否”。 我们早期达到了 300 个 CPU 的天花板 我们的第一个区域是 Azure US East 2，初始配额约为 300 个 CPU。计划是消耗它并请求更多，正如梯子通常运作的那样。但不幸的是，我们选择了全球最繁忙的数据中心之一，300 个 CPU 是那里的天花板，无论我们的使用历史如何。同时，新用户在固定的计算池中注册。 为什么迁移到另一个区域无法解决规模问题 明显的做法是迁移到一个较安静的区域或不同的云，并在那里收集更大的配额。我们还持有希望使用的 Azure 信用额度。但更深层次的问题是，迁移区域或云服务提供商只是重置了时钟。每个区域都有上限，服务提供商逐渐提高它，但一个单区域架构快速扩展时会在某个点达到天花板。此外，10K，100K 或 1M 个并发虚拟机的沙盒需求无法从一个数据中心进行物理服务。我们需要重新思考架构，以便添加任何云的区域成为一个部署步骤，而不是迁移项目。我们还必须拆解现有架构，以使这一切得以实现。 从单个控制平面开始 我们的第一版 OpenComputer 是一台虚拟机处理一切，并具有一个控制平面。第二版是我们在一个区域内扩展到多台虚拟机，由一个控制平面协调，处理一切：Web 界面、仪表盘、计费逻辑和虚拟机的实际编排，所有这些都在一个地方。一个控制平面（运行 Web 界面、仪表板、计费和编排）连接到三个工作节点，所有这些都位于一个 Azure 区域内，显示为虚线边框框。该设计大致可以舒适地支持千个沙盒。它假设所有计算都位于一个区域，并且编排虚拟机的组件也可以是运行围绕其进行的产品的组件。我们必须将这两个工作分开。 单元使容量成为可部署单元 我们从将控制平面缩减到单个工作（编排虚拟机）开始，并将其与它管理的工作节点打包成一个可部署到任意云区域的单元。该单元被称为“单元”。 控制平面缩小到一项工作 重新设计将控制平面精简到其所在区域内虚拟机的生命周期：将请求的沙盒调度到特定工作节点。跟踪每个虚拟机的所在位置和状态。将空闲虚拟机休眠到基于 S3 的存储中，并按需唤醒。当重新平衡调用时，将虚拟机从一个工作节点迁移到另一个工作节点。单元内的组件彼此了解，且不知晓单元外的任何信息。仪表盘、计费逻辑和所有面向用户的内容完全移出单元。单元是...