上周在GitHub Universe上，我们宣布了新的Git存储架构，能够每秒处理数千次写入，并按需扩展读取。通过内部测试，我们已经证明能够支持5,000个并发代理在存储库上工作，每秒向存储库发送7,200次推送，同时始终以低延迟提供读取流量。
这种新架构是GitHub支持数亿开发人员的代理开发的基础，在GitHub继续运行的同时，我们一直在GitHub下构建它。在过去的一年中，代理改变了GitHub上繁忙的存储库的样子。
在本系列的第一篇文章中，我们列出了下一代Git存储架构背后的两个原则：最小化协调，以及将存储与计算分离。在我们的上一篇文章中，我们介绍了桥接：将99.99999%的存储库迁移到Azure中，将写入仲裁范围限定为单个引用，并建立由Azure Blob存储支持的虚拟副本。
我们还留下了一个观察结果：只需要订购很少的写作。Git对象是不可变的，并按其内容命名，这意味着两个编写器可以同时存储它们，而无需就任何内容达成一致。推送中需要达成一致的部分是参考更新，相比之下，参考更新很小。
虚拟副本是围绕这一点构建的第一步，也是我们将存储库引入新架构的手段。其余的架构建立在这一观察之上。只有参考更新需要同意。这使得过去紧密耦合的Git基础设施部分（存储数据、服务请求和维护存储库）可以独立扩展。