GitHub平台正面临Git操作密度的前所未有的增长，这主要由软件和AI智能体（AI Agents）的普及所推动，它们产生了密集且持续的修改与更新流。为了应对传统数据中心电力容量和供应链的物理限制，该公司公布了一项架构方案，迄今已将其99.99999%的代码仓库副本迁移至其自建数据中心与微软Azure（Microsoft Azure）云之间共同托管。
延迟瓶颈与全仓库锁定
GitHub解释称，平台上使用和修改最频繁的代码仓库——即剩下的微小部分（0.00001%）——此前面临着网络往返延迟这一技术障碍。当数据迁移到美国中部（Central US）的Azure区域时（该区域距平台的数据中心约一千英里），每次网络通信都会增加约25毫秒的往返延迟。
在同步与共识系统“Spokes”的旧架构中，任何新的写入操作都需要在整个仓库级别施加全面锁定（Repository-wide lock），直到所有副本（Replicas）做出响应。由于持有全局锁，网络延迟最高的副本决定了响应时间以及整个仓库吞吐量的上限，导致接收来自开发者和AI智能体高频代码推送的活跃仓库出现性能瓶颈。
基于单引用的共识机制
为了突破这一瓶颈，GitHub通过应用其第一条架构原则——“最小化协调并消除不必要的锁定”——重构了共识机制。现在，共识与锁定的范围不再是在更新期间锁定整个仓库，而是专门应用于单个引用（Per-reference serialization），例如分支（Branches）或标签（Tags）。
由于开发者或AI智能体执行的大多数并发写入操作针对的是不同分支，修改不再需要在单个队列中相互排队等待。该公司在实际负载下的内部测试显示，写入吞吐能力提高了3至4倍，且延迟显著降低。
存储与计算分离及对象存储普及
第二阶段包括应用第二条架构原则：“存储与计算能力解耦”（Decoupling storage from compute）。大多数Git仓库的特点是读操作密度远高于写操作，读写比通常在100:1到1000:1之间。在旧架构中，读写操作会争用相同的资源和内存。
为了解决这个问题，GitHub将对象存储（Azure Blob Storage）作为共识仲裁集中的虚拟成员引入，称为“虚拟写入副本”（Virtual Write Replica）。该副本作为一个临时管道，聚合事务并将修改持久流式传输到云存储中。一旦存储确认完成，平台就可以按需扩展并启动无限数量的“虚拟读取副本”（Virtual Read Replicas），这些副本在后台更新缓存，而不会影响数据写入速度或同步性能。
这对软件开发基础架构带来了哪些实际变化？
GitHub的这一工程转型反映了如何重新设计大规模分布式系统以承受基于AI的自动化工作负载，最显著的实际影响可概括如下：
- 提升吞吐上限：赋能AI智能体和开发者进行密集的并发代码推送，而不会在大型仓库上造成锁定（Lock）。
- 灵活扩展读取：能够独立增加读取服务器并为其分配缓存，无需执行繁重的共识流程。
- 核心平台连续性：在不中断服务或牺牲数据完整性的情况下，对每日执行超过1000亿次操作的“Spokes”系统内部组件进行升级。