从 1 台 VM 到 100 万个沙箱：OpenComputer 的无限扩展之路

背景

OpenComputer 的起步非常典型：在 Azure 的一个区域（US East 2）中，使用单台虚拟机启动服务。随着公司的快速增长，他们很快遇到了云计算基础设施中常见的瓶颈——区域配额限制。

在云服务商（如 Azure、AWS、GCP）的体系中，物理硬件资源是有限的，且按区域进行配给。云厂商通常通过“配额”（Quota）来管理资源，初始配额较小，用户需要通过建立使用历史并维持约 50% 的利用率运行一到两周，才能申请增加配额。然而，OpenComputer 所在的 US East 2 是全球最繁忙的数据中心之一，300 个 CPU 的核心配额成为了不可逾越的天花板，无论其实际使用率如何。

面对这一困境，简单的迁移策略（如换到另一个区域或云厂商）只能重置时钟，无法解决根本问题。因为任何单一区域都有上限，且随着并发 VM 数量达到 10 万甚至 100 万级，单个数据中心在物理上也无法承载。因此，OpenComputer 必须彻底重构架构，将“添加容量”从一个需要审批的迁移项目，转变为简单的部署步骤。

核心内容

为了解决扩展性问题，OpenComputer 将系统拆分为“单元（Cells）”，并在边缘层建立了一个全局注册表来调度资源。以下是其架构演进的核心细节：

1. 控制平面的拆分与“单元（Cell）”的诞生

最初的架构中，控制平面（Control Plane）是单点的，负责 Web UI、仪表盘、计费逻辑以及 VM 的编排。这种设计在支撑约 1000 个沙箱时表现良好，但假设所有计算资源都位于同一区域，且编排组件与产品运行组件耦合在一起。

为了实现无限扩展，团队将控制平面精简为单一职责：仅负责 VM 的生命周期管理。他们将这个精简后的控制平面与其管理的 Worker 打包成一个可部署单元，称为“单元（Cell）”。

• 单元的职责：
  • 将请求的沙箱调度到特定的 Worker 上。
  • 追踪每个 VM 的位置和状态。
  • 将空闲 VM 休眠至基于 S3 的存储，并在需要时唤醒。
  • 在重新平衡时迁移 VM。
• 隔离性：单元内的组件互知，但对外部一无所知。仪表盘、计费逻辑等用户面向的功能被移出单元。
• 故障隔离：每个单元是故障隔离的最小单位，其标识符编码了其所在的服务器区域信息。每个单元拥有 5 到 10 个运行 QEMU VM 的 Worker。

2. 智能的 VM 放置策略

当收到创建请求（包含内存、CPU、磁盘和模板参数）时，控制平面不能简单地选择负载最低的 Worker。一个优秀的控制平面需要权衡以下因素：

• 资源适配：避免资源碎片化导致容量浪费。
• 模板热度：如果 Worker 上已有“温暖”的金子快照（Golden Snapshot），创建 VM 仅需约 200ms；若是冷启动则需数秒。
• 硬件差异：区分 ARM 与 amd64 架构。
• 软亲和性（Soft Affinity）：保持组织（Org）的沙箱靠近其缓存。
• 反亲和性（Anti-Affinity）：将付费工作负载与嘈杂的免费层级邻居隔离开来。

3. 云无关性与多云部署

“单元”的设计不假设任何特定的云提供商。由于使用的 Worker 形态在 AWS、Azure、GCP 和 OCI 中都有等效的实例类型，因此相同的单元可以无需修改地部署到任何云平台。这使得容量不再局限于“我们的 Azure 配额”，而是变成了“我们部署的所有单元的总和”。

4. 边缘层的全局注册表

由于存在多个独立的单元，需要一个外部组件来决定每个沙箱由哪个单元处理。这个职责由位于边缘（Edge）的全局注册表承担。

• 技术栈：基于 Cloudflare Workers、D1 数据库和 Durable Objects。
• 注册表功能：
  • 知道每个单元的存在、运行位置及剩余容量。
  • 被视为“控制平面的控制平面”。
• 请求路由流程：
  1. 创建请求到达最近的边缘位置。
  2. Cloudflare Worker 查询 D1 数据库，选择空闲容量最多的单元。
  3. 该单元的控制平面接管后续的所有操作。
• 性能权衡：创建请求虽然耗时（在边缘增加 50-100ms 用于认证、信用检查和单元选择），但由于创建操作本身罕见且昂贵，这一延迟是可以接受的。
• 高频操作优化：执行命令、文件读写、PTY 流量和销毁操作等高频请求，直接通过签名 JWT 认证的连接发送到单元控制平面，路径中不包含任何同步的 Cloudflare 查找，确保低延迟。

5. 心跳机制与计费

路由是边缘层的下游部分，而上游部分则是从每个运行中的 VM 返回的事件流。

• 秒级计费：每个运行中的 VM 每 10 秒发送一次“存活”心跳。这些心跳被聚合用于计费，确保按实际运行秒数收费。
• 状态推送：VM 的休眠、停止或迁移等生命周期事件通过事件流推送到注册表，确保路由决策基于最新的容量状态。
• 事件处理流程：
  1. 单元内的 Worker 将事件发布到 Redis Streams。
  2. 转发器通过 HTTPS 批量发送事件到 Cloudflare Ingest Worker。
  3. Ingest Worker 使用 HMAC 验证批次，利用 KV 存储基于事件 ID 去重。
  4. 事件被分发到注册表和计费对象。
  5. 事件设计为幂等的，即使 Cloudflare 不可达，也能保证数据一致性。

关键要点

• 配额瓶颈是物理性的：云厂商的区域配额限制是硬约束，单一区域无法支撑百万级并发 VM，必须通过多区域/多云架构解决。
• 架构解耦：将控制平面从 UI、计费等业务逻辑中剥离，仅保留 VM 生命周期管理，形成可独立部署的“单元（Cell）”。
• 单元即容量：每个单元是一个故障隔离的最小单位，包含 5-10 个 Worker。总容量等于所有部署单元之和，实现了云无关性。
• 边缘智能调度：利用 Cloudflare Workers 和 D1 数据库在边缘构建全局注册表，实现低延迟的沙箱路由决策。
• 读写分离策略：低频的创建请求经过边缘注册表路由，高频的执行/IO 请求直连单元，避免边缘成为性能瓶颈。
• 实时状态同步：通过心跳和事件流（Redis Streams -> Cloudflare Ingest -> Durable Objects）实现秒级计费和实时容量状态更新，确保调度准确性。

意义与影响

OpenComputer 的架构演进为高并发、多租户的虚拟化服务提供了极具参考价值的工程实践。

首先，它证明了**“云无关性”**在大规模扩展中的重要性。通过抽象出统一的“单元”概念，企业可以灵活利用 AWS、Azure、GCP 和 OCI 的混合资源，避免被单一云厂商锁定，并能利用不同区域的成本优势和容量差异。

其次，该架构展示了边缘计算在资源调度中的优势。将全局注册表置于边缘，不仅降低了路由决策的延迟，还利用了 Cloudflare 等边缘网络的高可用性和全球分布特性，使得系统能够轻松应对全球用户的请求。

最后，其细粒度的状态管理和计费机制（基于心跳和事件流）为实时计费提供了可靠基础，同时通过幂等设计和去重机制保证了系统的健壮性。这种从单点控制平面到分布式单元+边缘注册表的演进路径，为其他希望从初创规模扩展至百万级用户的技术公司提供了清晰的蓝图。