AI Agent把GitHub逼到重构：一次“35倍性能提升”的架构课 - 蝈蝈俊
内容提要
GitHub因AI Agent高频提交改变了流量形态，被迫重构Git存储架构。旧架构的多副本强一致导致写放大；新架构将不可变Git对象写入对象存储，仅协调引用更新，写入性能最高提升35倍，单仓库可支持5000个并发Agent。核心启示是缩小一致性边界、读写解耦、持久性下沉、将维护移出热路径，并将容量规划从峰值转向持续高吞吐。
延伸解读
负载“形状”比峰值数字更关键
文章指出，GitHub旧架构并非被提交量本身压垮，而是被AI Agent带来的持续高吞吐、高并发、读写互相拖累的负载形状压垮。人类提交是离散低频的，Agent则在紧循环中频繁提交，使写入量激增、读扇出放大、维护成本复利累积。这提醒架构师：容量规划不能只做QPS外推，而要重新绘制读写路径和扇出图，识别新客户端是否改变了流量节奏。
缩小一致性边界是重构核心
GitHub新架构的关键不是换更快磁盘，而是把协调范围从“每次写入的完整流程”压缩到“仅引用更新”。因为Git对象不可变且按内容命名，可以并行写入对象存储，真正需要达成一致的只是分支指针移动。文章由此提炼出可迁移原则：能并行的不要协调，必须协调的尽量缩小。架构师应审视系统中哪些点必须串行、是否被过度扩大，以及不可变数据是否仍在走协调路径。
读写解耦与持久性下沉
旧架构用多副本同时解决读扩展和持久性，导致写放大：每次写都要等最慢副本，加副本反而拖慢写入。新架构将持久性交给对象存储、读服务交给轻量缓存Worker、写协调只围绕引用更新，三者独立扩展。同时，计算Worker故障被视为“缓存未命中”而非数据丢失。这提示读者检查：持久性、读服务、写协调能否分开扩展，以及监控和重试逻辑是否仍把缓存失效当数据事故处理。
原则可迁移，技术选型需谨慎
文章强调，可迁移的是原则而非Azure Blob这一具体选型。对象存储也有代价：网络延迟、缓存一致性、引用协调仍是瓶颈、迁移复杂度高。因此，读者应优先借鉴重新建模负载形状、缩小一致性边界、读写解耦、持久性下沉、维护移出热路径、关键路径最短化、规划指标升级、演进对使用者透明等思路，再结合自身条件评估技术方案，避免直接照搬配置。
Q&A
GitHub为什么被迫重构Git存储架构？
AI Agent改变了流量形状：提交频率从人类节奏变为机器节奏，导致写入量激增（提交量一年5倍）、读写严重耦合、维护成本复利累积，旧架构无法支撑持续高吞吐和高并发。
GitHub旧架构Spokes的主要瓶颈是什么？
每个仓库保存5个完整副本，写入需三阶段提交和法定数量确认，导致写放大；增加副本会拖慢写入；压缩和垃圾回收在实时请求路径上运行，干扰读写服务。
新架构Rubicon如何实现35倍写入性能提升？
将不可变Git对象（Blob、Tree、Commit）直接写入Azure Blob Storage，仅引用更新需要协调；持久性下沉到对象存储，读服务由轻量缓存Worker负责，维护交给后台Worker，读写独立扩展。
新架构中计算Worker故障为什么被视为缓存未命中？
因为数据持久性已下沉到可靠的对象存储层，计算Worker只负责缓存和服务读取，故障不会导致数据丢失，只需替换Worker即可，提高了运维弹性。
从GitHub重构中可以提炼出哪些可迁移的架构原则？
缩小一致性边界、读写解耦、持久性下沉、计算无状态化、维护移出热路径、关键路径最短化、容量规划从峰值转向持续高吞吐、演进对使用者透明。
AI Agent给代码托管平台带来的负载形状变化具体指什么？
Agent在紧密循环中工作，几乎每个动作都提交或打检查点，使提交从离散低频变为持续高频；每次推送又触发CI、部署等海量读取，形成读的扇出，读写相互拖累。
