GitHub 发布新 Git 存储架构，支持数千智能体同时推送代码

GitHub 的全新 Git 存储架构在设计上支持数千个 agent 同时向单个仓库推送。以下是它的工作原理。

16 分钟

分享：

上周在 GitHub Universe 上，我们发布了全新的 Git 存储架构，每秒可处理数千次写入，读取能力可按需扩展。通过内部测试，我们已证明能够支持 5,000 个并发 agent 在同一个仓库上工作，每秒向一个仓库发送 7,200 次推送，同时以始终如一的低延迟处理读流量。这一新架构是 GitHub 支持数亿开发者进行 agentic 开发的基础，而我们一直在 GitHub 运行的同时于底层构建它。

在过去一年里，agent 改变了 GitHub 上繁忙仓库的面貌。在本系列的第一篇文章中，我们阐述了下一代 Git 存储架构背后的两条原则：最小化协调，以及将存储与计算解耦。在上一篇文章中，我们介绍了过渡的桥梁：将 99.99999% 的仓库迁移到 Azure，将写入 quorum 限定到单个 reference，以及搭建由 Azure Blob Storage 支持的 virtual replica。

我们还留下了一个观察：一次写入中真正需要排序的部分非常少。Git object 是不可变的，并以其内容命名，这意味着两个写入者可以同时存储它们而无需就任何事情达成一致。一次推送中需要达成一致的部分是 reference 更新，而相比之下 reference 更新非常小。Virtual replica 是围绕这一点进行构建的第一步，也是我们将仓库接入新架构的手段。

架构的其余部分就建立在这一观察之上。只有 reference 更新需要达成一致。这使得 Git 基础设施中过去紧密耦合的部分（存储数据、服务请求和维护仓库）可以独立扩展。对开发者而言，Git 仍然是 Git：他们以同样的方式 push、fetch 和 branch，同样的保护机制依然到位。下面，我们将逐一介绍设计背后的需求，跟随一个请求走完整个系统，并深入探讨其中的两个组件。

我们从两个维度来思考 GitHub 平台的规模：

如今，GitHub.com 上最繁忙的仓库每秒最多接收几十次写入，通常以短时突发形式出现。随着越来越多这类工作转移到并行、全天候运行的 agent 上，我们预计这些突发将在未来一年内变成持续速率。每次推送都会带来更多读取：CI 运行、部署系统拉取新提交，以及其他 agent 为获取上下文而 fetch 它。这种读取扇出对整体流量产生了巨大的放大效应，并随写入量而扩展。

我们已经在处于曲线顶端的仓库上看到了这一趋势的发展。下图展示了一个 GitHub 仓库从 3 月到 5 月的每日请求量，期间其流量增长了约 4 倍。此后它的增长一直保持指数级轨迹。

我们必须为一个 agent 驱动的开发以此速度持续加速的世界做好规划。我们没有按下一个增量来做规划，而是设定了至少两个数量级以上的扩展目标。对于单个仓库，这意味着新架构需要做到：

除此之外，系统还必须能够提升整体可靠性并在全球范围内扩展。

2026 年 5 月，紧接在最初的 Azure 迁移之后，我们开始着手设计一个能够满足这些需求的新方案。我们尝试了多种方法。在所有这些方法中，pack 数据都存放在 Azure Blob Storage 中，其中一些方案我们还尝试将 reference 状态也放在那里。下面我们会介绍发现的一些权衡，但最终我们确定了一个我们认为在最大化吞吐量的同时，保留了 GitHub 这样的平台所需的正确性、持久性、可用性和延迟保证的设计。我们称之为“Rubicon”，以此致敬整个行业随着 agentic 开发而跨过的不可回头之点。

让我们自上而下地走一遍 Rubicon。许多东西保持不变：来自 Git 客户端、API 和 Web UI 的请求到达 Spokes，它仍然负责路由和负载均衡，并提供 GitHub 其余部分用来读写仓库数据的内部 API。Spokes 还保持其作为放置与均衡服务的角色，维护水平扩展所需的分区、隔离和租户公平性。相比之下，Spokes 下方的数据平面是全新的。

Spokes 将每个请求路由到分配给该仓库的一小组 virtual replica 之一。Virtual replica 是一组一次性的计算节点，负责处理读取、写入或两者兼有。Virtual replica 的本地磁盘是一个缓存，可以随时重建。

Spokes 会尽可能将仓库的流量路由到相同的 virtual replica，以保持其缓存热度和低延迟，但正确性并不依赖于请求落在任何特定的 virtual replica 上。当一个 virtual replica 消失时，该仓库的其他 virtual replica 会继续服务，而替代者会随着流量到来填充其缓存。

当仓库变得繁忙时，我们会增加更多 virtual replica。另外，一组 compaction 节点在后台直接针对 Blob Storage 和 Ref-CAS 工作，合并每个仓库的 pack 并移除不可达的 object。这项工作从不在 virtual replica 上运行，这意味着它们的 CPU 和内存几乎可以完全专用于服务请求。

让我们从一次写入和一次读取的角度走一遍这个架构：

在新架构中，我们采取了许多不同的方法，从 virtual replica 上的软件栈，到如何针对不同用例（例如许多小仓库 vs. 一个大仓库）调整流量路由和工作负载调度。让我们深入探讨架构中的两个组件，并围绕两条设计原则讲述它们的故事。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）