GitHub 把 99.99999% 的仓库搬进 Azure：为 AI 编程代理的读写洪峰铺路

作者：陈一帆

10 月 21 日 GitHub 工程博客披露，过去一年里平台 99.99999% 的仓库已在自有数据中心和 Azure 各存一份副本，Azure 承接约一半 Git 流量。剩下 0.00001% 是最忙的仓库，卡在 25 毫秒的跨区往返上，官方用「按引用法定人数」和对象存储来收尾。

10 月 21 日，GitHub 工程团队在官方博客交代了一件事：过去一年里，平台上 99.99999% 的 Git 仓库已经在自有数据中心和 Azure 各存了一份副本，Azure 现在承接大约一半的 Git 流量。剩下 0.00001% 是全平台最忙的那批仓库，卡在一个约 25 毫秒的跨区往返上；官方给出的解法是把写一致性的范围从整个仓库缩到单个分支，并让对象存储接管读取扩容。这是两周前的发文，不是新消息，但信息量值得单独拎出来说。

时间线官方只给了片段：第一份仓库副本在 2025 年 8 月落进 Azure 的 Central US 区域，如今多数仓库的 5 个副本里有 2 个在 Azure。剩下部分没有完整时间表，但迁移逻辑写得很清楚——流量跟着数据走。Spokes 会把请求优先路由到同区域同可用区的副本，副本每搬一个，能从 Azure 服务的比例就涨一截，最后一个副本到位后旧区域就不再收请求。

为什么非要搬？博文提到三个硬约束：代理带来的流量暴涨、自有数据中心及周边地区电力容量的天花板、以及物理供应链限制。按官方说法，迁移开始时把可能的扩容全算上，时间只够「安全地搬」，不够「慢慢地搬」。另一个判断是排序：换存储架构和换托管平台同时做风险太大，所以先搬数据，再改架构。

那 0.00001% 卡在哪。现有机制里，一次写只要多数副本提交就算成功，但系统会等所有健康副本响应（有超时），而每次写期间握着仓库级的锁。于是最慢的健康副本决定了每次写的延迟，也决定了吞吐上限。Azure 副本离数据中心约 1000 英里，单次往返约 25 毫秒，而一次写要走好几个往返——已经贴着吞吐上限的仓库，每 push 一次就落后一点。

新做法的关键是把法定人数的粒度从仓库缩到引用（ref）。Git 的一致性要求本来就作用在单个引用上：服务端接受一次更新后，客户端不该再看到更旧的值。但不同引用的更新通常互不依赖，各推各的分支时没必要排队。改成按引用串行后，只有写同一个分支的请求才互相等待，其余可以同时在飞。内部用真实流量形态测试，不同引用的写入吞吐稳定提升 3–4 倍，延迟更低。第三方每周纪要也把这一条作为该文的核心记下来。

读取侧的思路是解耦。多数仓库的读远多于写，官方给的比例是每 1 次写对应 100 到 1000 次读，而现在读写抢同一批副本资源。第一步是让对象存储以「虚拟副本」的身份加入写 quorum——它是个特殊的成员，不服务读，只把写入流进 Azure Blob Storage，一次写只有在对象存储里落盘后才算确认。这会加一点延迟，但按引用串行让它不至于变成吞吐瓶颈；它还会把落在不同引用上的事务合并成一次网络 I/O，忙仓库不必为每次写付一次往返。有了这层，读副本可以按需拉起、不加入 quorum，从 Blob 预热缓存、后台对账。内部压测时，压测工具先撞到自己的上限，而不是架构的上限。

背景数字能解释急迫感。本系列前一篇（10 月 6 日）给出：2025 年 9 月到 2026 年 8 月，月度 Git 事件从 2182 亿涨到 4733 亿；今年 9 月单月提交 73.8 亿次，是去年同期的五倍多；push 同比增长 4.9 倍；8 月最忙的单个仓库被请求约 10 亿次。代理的工作方式是紧循环里反复 clone、fetch、push，人感觉不到的那点延迟，对它就是节流阀。

后续进展也有：上周 GitHub Universe 的官方总结确认，Azure 多区部署迁移预计明年初完成，今年平台新增 400 万 CPU 核、160PB 高速存储和 50Tb/s 网络容量。不过边界同样清楚——博文自己说，写入吞吐仍是下一个待解瓶颈，每个写还要等持有完整仓库副本的副本们，终态方案留到了系列收官篇。对普通用户，官方没给 clone 速度之类的可感知指标；独立观察者 Nesbitt 的纪要里另记了一条：流量异常高峰期，未认证的公共仓库 HTTPS clone/fetch 可能被要求登录。

我自己的看法：这次值得注意的不是「搬上云」这个动作，而是把一致性单位切小这一手——同一个思路在别的高并发系统里也常见，落在一个跑了十几年的 Git 服务上才是难点。至于是不是能让代理随便刷仓库，还要看收官篇给出什么，目前跑通的是前半程。

转载说明

本文根据以下公开资料整理，原文及配图出处见下方。

• [S1] The bridge to agent-scale Git infrastructure
• [S2] The bridge to agent-scale Git infrastructure
• [S3] Building Git infrastructure for agent-scale development
• [S4] This Week in Source Control: 28 October 2026
• [S5] GitHub Universe 2026: Evolving every layer of the stack
• 配图 1：来源：The GitHub Blog（图片署名见原文） · 图片出处
• 配图 2：来源：The GitHub Blog（图片署名见原文） · 图片出处
• 配图 3：来源：The GitHub Blog（图片署名见原文） · 图片出处
• 配图 4：来源：The GitHub Blog（图片署名见原文） · 图片出处