智能体流量逼 GitHub 搬家:99.99999% 的仓库已在 Azure 有副本,最后一批卡在 25 毫秒往返,写入锁从整仓改成按分支

GitHub 工程博客 10 月 21 日披露,过去一年 Git 流量呈指数增长,自有数据中心及所在地区的电力容量到了硬上限,加上硬件供应链受限,公司把 Git 存储迁往 Azure:首个仓库副本 2025 年 8 月落地 Azure 美国中部区域,如今 99.99999% 的仓库同时存在于自有机房和 Azure,多数仓库 5 个副本中有 2 个在 Azure,Azure 承担约一半 Git 流量。剩下的是平台上最繁忙的一批仓库,原因是 Azure 区域距原机房约 1000 英里、单次往返约 25 毫秒,而原有写入仲裁对整个仓库加锁、要等最慢的健康副本。GitHub 正把写入串行化的范围从整仓改为单个引用(分支 / 标签),内部测试中写不同引用的吞吐提升 3–4 倍;同时把 Azure Blob 存储变成仲裁里的「虚拟副本」,让读取可以按需扩容。

为什么现在搬、为什么搬得急

GitHub 工程博客 10 月 21 日发文,把 Git 存储迁移的原因直接归到「智能体转向」:过去一年 Git 流量呈指数增长,自有数据中心及所在地区的电力容量到了硬上限,硬件供应链也受限。按 GitHub 的说法,迁移开始时剩余的扩容空间「够安全地搬,但不够慢慢搬」。

进度是:首个仓库副本 2025 年 8 月落地 Azure 美国中部区域;如今 99.99999% 的仓库同时存在于自有机房和 Azure,多数仓库的 5 个副本里有 2 个在 Azure,Azure 承担约一半 Git 流量,这段时间的新增流量基本由 Azure 吸收。仓库所有者不需要做任何操作。

最后那 0.00001% 卡在哪

没搬过去的恰恰是平台上最繁忙的仓库。GitHub 的存储层 Spokes 用多数派仲裁提交写入,但会等所有健康副本响应(直到超时),而且每次写入在提交前持有整个仓库的锁。于是最慢的那个副本决定了每次写入的延迟和整个仓库的吞吐上限。Azure 区域离原机房约 1000 英里,单次往返约 25 毫秒,一次写入要往返好几次,本来就接近上限的仓库加上这段延迟,推送只会越排越长。

解法是缩小串行化的范围:Git 的一致性只要求同一个引用(分支或标签)不出现回退,不同引用的更新大多互不相干。GitHub 正把仲裁从整仓改为按引用,只有写同一引用的操作才需要互相等待。智能体和开发者各推各的分支是常态,内部用真实流量测试,写不同引用的吞吐稳定提升 3–4 倍,延迟也更低。

读写分开扩容

另一半改造针对读:多数仓库每写一次要读 100 到 1000 次,但读写目前挤在同一批副本上。GitHub 把 Azure Blob 存储做成仲裁中的一个「虚拟写副本」,写入落到对象存储才算确认;之后可以按需拉起任意数量的「虚拟读副本」,从对象存储预热缓存就开始接读流量,不加入仲裁。内部压测里,压测工具先撞到了自己的上限。

GitHub 也承认写入吞吐的天花板仍在仲裁本身,终态设计会在 10 月 28–29 日的 GitHub Universe 和系列最后一篇里公布。对用户来说,这组数字说明的问题比迁移本身更值得记住:智能体带来的不是多几个用户,而是把一家托管平台的写入模型和机房电力一起推到了极限。

via: GitHub Blog:The bridge to agent-scale Git infrastructure