北京
Uber 的工程师们最近干了一件挺狠的事：把自家大规模单体代码库的 Git 操作，整个搬到了一个叫 GitFarm 的共享服务上。效果立竿见影——客户端资源占用直接砍掉了 80% 以上。
以前，Uber 的自动化系统每天要在支持 Go、Java、Python、Web、Android 和 iOS 的单体代码库上调用数百万次 Git 操作。每个服务都得维护一份完整的代码库检出副本，读文件、验证变更、计算合并基础，全得自己来。克隆一次 Uber 的 Go 语言单体代码库，大约需要 15 分钟，还得搭上 6 个 CPU 核心、32 GB 内存和超过 40 GB 的磁盘空间。这套本地克隆加反复同步的老流程，成了实打实的基础设施瓶颈。
GitFarm 的思路很简单：别让每个服务都自己扛代码库，把 Git 操作集中起来做成服务。它不是一个新的源代码管理系统，而是一个中心化的 Git 客户端，替其他服务执行标准的 Git 命令。客户端不再需要本地克隆，通过高性能的 gRPC API 就能发起请求，网关负责认证和授权，然后把请求路由到后端集群，命令在隔离的、临时的沙箱里运行。
这套架构的关键在于“池化”。后端维护着裸代码库克隆，用推送式更新和定期抓取跟上游保持同步，同时维护着一批代码库检出和沙箱容器池。请求来了，GitFarm 直接把一个预热的检出挂载到空闲沙箱上，而不是从头创建克隆和执行环境。Uber 工程团队在 LinkedIn 上表示，完整的 Git 检出现在 500 毫秒内就能完成，以前 10 到 15 分钟的主机级冷启动时间直接归零。
多命令工作流也做了优化。GitFarm 通过双向 gRPC 流会话，支持在同一个检出上顺序执行多个命令。比如获取分支、计算合并基础、推送派生引用这一串操作，不用反复初始化代码库状态。客户端需要最新上游状态时可以显式执行 git fetch，能接受数据滞后的工作负载，直接用后端同步好的状态就行。
实际效果怎么样？Uber 透露了一个具体案例：某代码所有权服务迁移到 GitFarm 后，移除了跨六台主机的本地检出，CPU 消耗从 70 多个核心降到 16 个，内存从 400 GB 降到 32 GB，启动时间从 15 到 20 分钟缩短到不到一分钟。另一个合规审计服务，每小时处理 10000 到 20000 个事件，跨越 9000 个代码库，中位延迟从用 Buildkite 时的 110 到 160 秒，降到了用 GitFarm 时的 20 到 30 秒。
这套架构对编码智能体（AI coding agent）的工作负载也友好。Uber 的 Ashish Verma 在 LinkedIn 上指出，智能体会反复搜索、分支、差异比较、实验、重试和验证变更，而且是并发进行的，对 Git 基础设施的压力不小。GitFarm 这种即取即用的模式，正好接得住这种高频、并发的操作模式。
GitFarm 自 2025 年初投入生产环境适应以来，路线图上还有不少东西：流式 Git 输出、稀疏检出、裸工作空间、更长时间的会话、代码库镜像，以及 SubmitQueue 集成。对于代码库大到克隆一次都要等一顿饭时间的团队来说，这套思路确实值得盯着看。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
