在过去一年中，随着 Git 流量呈指数级增长，GitHub 上几乎所有的 Git 仓库都同时存在于两个地方：GitHub 自有的数据中心和 Azure。最繁忙的仓库仍受制于单一因素：区域之间 25 毫秒的往返延迟。
在早前的一篇文章中，GitHub 阐述了其下一代存储架构背后的两项原则：尽量减少协调，以及将存储与计算解耦。本文探讨旧设计与新设计之间的衔接。对仲裁机制序列化写入方式的一项改变，使最繁忙的仓库得以迁入 Azure，而这一步同时也为不保存任何持久状态的副本打开了大门。
此次迁移的时机由智能体化转型所驱动：流量快速增长、GitHub 数据中心及周边区域的电力容量存在硬性上限，以及实体供应链的约束。剩余的容量足以让迁移安全完成，但不足以让迁移从容进行。由于 Git 操作属于 Tier 0 服务，GitHub 上几乎所有功能都依赖于它，因此数据必须率先迁移，架构则在数据抵达之后再逐步演进。首个仓库副本于 2025 年 8 月落地于 Azure 的美国中部区域。如今，大多数仓库的五个副本中已有两个位于 Azure，Azure 承载的 Git 流量约占一半。
其余 0.00001% 的仓库面临更棘手的问题。在当前架构中，写入操作需等待每一个健康副本响应，因此最慢的副本同时决定了延迟和吞吐量。目标 Azure 区域的副本距离约 1,000 英里，而每次写入都需要多次往返。解决之道在于尽量减少协调：Git 的一致性要求逐个作用于每个引用，而对不同引用的更新通常彼此独立，因此无需全部序列化。
来源: Hacker News · 由HeadlinesBriefing整理摘要