Git 大规模托管的挑战与解决方案:从 Spokes 到 Continuity 的演进之路
在现代软件开发的浪潮中,Git 已经成为不可或缺的版本控制工具。从最初 Linus Torvalds 为 Linux 内核开发而设计的分布式版本控制系统,到如今遍布全球的开源项目和企业级代码仓库,Git 的影响力早已超越了其最初的设想。然而,当我们试图将 Git 扩展到大规模场景时,却发现其分布式设计的天然优势,在服务器端却成为了一个噩梦般的挑战。本文将深入探讨 Git 大规模托管的技术难点,以及业界如何通过不同的架构设计来克服这些挑战,最终实现高并发、高可用的 Git 存储系统。## Git 的设计初衷与现实困境Git 的诞生源于 Linus Torvalds 对 BitKeeper 的不满。作为 Linux 内核的维护者,他需要一个能够支持极度分散的开发模式的版本控制系统。
Linux 内核的开发涉及成千上万的贡献者,每个人负责不同的子系统,而 BitKeeper 的商业许可证限制了这种开发模式。因此,Git 应运而生,并以其分布式、高效的特性迅速成为主流。然而,Git 的分布式设计在企业级应用中却暴露出了诸多问题。大多数企业并不需要完全分布式的开发模式,他们更倾向于集中式的代码托管服务。但即便如此,Git 的分布式特性仍然给服务器端的托管带来了巨大的挑战。Git 的核心设计理念是「所有仓库实例完全一致」,这意味着服务器端的仓库与开发者本地的仓库在结构上没有区别。
这种设计在本地开发场景中非常高效,但在服务器端,它却成为了一个巨大的负担。## Packfiles:Git 的核心存储机制Git 的存储机制基于 Packfiles,这是一种二进制序列化格式,用于压缩和存储代码和元数据(文件、提交、树结构等)。Packfiles 是 Git 存储和网络传输的基础构建块。当你推送或拉取数据时,传输的就是 Packfiles。这种设计在本地开发中表现优异,但在服务器端,它却成为了一个巨大的瓶颈。Packfiles 是大型二进制文件,必须存在于文件系统中才能被 Git 访问。
最简单的托管方式是使用 HTTP 服务器直接访问磁盘上的仓库,但这种方式的扩展性极低。理想情况下,我们希望仓库能够分布在多个磁盘和多台机器上,以实现并行操作和高可用性。然而,如何实现这一点呢?业界尝试了三种主要的扩展方法,按复杂度递增排列:分布式文件系统、分布式 Packfiles 和分布式 Git 本身。然而,这些方法都面临着巨大的挑战。## 分布式 Git 的尝试与失败### 尝试 1:分布式对象存储Git 是一个内容可寻址的数据存储系统。所有对象(blob、树、提交等)都通过其内容的 SHA-1 哈希值进行索引。
这种设计直观上适合分布式键值存储(键是 SHA-1,值是实际对象),并可能为仓库存储提供一种简洁的扩展方式。然而,这种方法实际上行不通。问题在于 Git 仓库的实际布局是一个有向无环图(DAG)。虽然你可以通过 SHA-1 查找任何对象,但即使是最简单的仓库操作,也需要逐步遍历这个 DAG。例如,要列出仓库的最近更改,你需要处理其提交记录。处理每个提交时,你会得到指向其根树的指针。
从该树中,你会得到指向每个文件和子树的指针。从原始提交中,你会得到指向其父提交(即历史上它之前的提交)的指针。关键在于,在这个遍历过程中的每一步,你都不知道下一个指针的值,直到你获取前一个指针的值。如果每次获取都需要往返一次分布式存储,成本会迅速飙升。这种对象级别的分布式 Git 方法曾多次尝试,但最终都在规模化面前败下阵来。最有希望的实现是由前导师 Shawn Pearce 在 Google 版本控制系统团队工作时尝试的。
他的方法是将对象存储在分布式哈希表中,这仅在使用 JGit(Git 的 Java 实现)时才可能实现。JGit 提供了足够的接口和工厂,可以抽象正常 Git 仓库的所有细节,包括用分布式哈希表替换其磁盘上的 Packfiles。虽然该系统可行,并且对于普通 Git 操作表现良好,但 Git 协议的限制(无论你如何在服务器上存储数据,都需要通过网络发送 Packfiles)使得 git clone 性能糟糕到足以放弃这种设计。### 尝试 2:分布式文件系统GitHub 的诞生正是为了解决 Git 托管的痛点。2008 年,GitHub 作为一家创业公司在旧金山成立,其标语「Git 仓库托管:不再是屁股痛」一针见血地指出了当时 Git 托管的尴尬现状。GitHub 的早期版本运行在一台强大的机器上,使用 Ruby 服务器和磁盘上的仓库副本。
虽然 Ruby 应用可以通过部署更多实例来扩展,但 Git 的存在使得扩展变得复杂。GitHub 的工程师最初尝试了最简单的方法:分布式文件系统。他们希望通过分布式文件系统来保持 Rails 应用不变,同时解决扩展问题。然而,这种方法很快就宣告失败。Git 对文件系统语义做出了许多假设(锁定、撕裂、读取、同步等),这些假设在开发者的本地磁盘上能保证良好的性能,但在网络文件系统上却表现糟糕。速度慢且 bug 多。
随后,他们尝试了在块级别复制文件系统的技术,包括短暂部署的 GFS 和较长期的 DRBD。这些技术最终都以失败告终,因为它们不仅操作复杂,而且性能低下。根本原因在于 Packfiles 的磁盘布局设计。我们已经看到,Git 的图形数据结构使得往返操作成本高昂。同样,Packfiles 的磁盘布局也面临类似问题。对象在 DAG 中的布局与它们在 Packfiles 中的物理存储之间没有关联。
生成 Packfiles 时使用的主要启发式算法是最小化其大小;对象随机分布在 Packfile 中,它们被压缩,更重要的是,它们很少被完整存储。大多数对象被存储为同一 Packfile 中另一个对象的增量。读取单个对象,在跟随图数据结构中的许多逻辑跳转后,还需要跟随磁盘格式中的物理跳转。这种在数千兆字节的数据中进行随机遍历的方式,对于每个 Git 操作来说都太过低效,无法在网络文件系统中正常工作(无论是文件级还是块级复制)。唯一不降低到爬行速度的方法是将整个文件缓存在本地。但在包含数十万个仓库的同一文件系统中,缓存是不可能的。
最终,GitHub 的工程师放弃了分布式文件系统的尝试,转而开发了一个 RPC 系统,使仓库能够驻留在专用文件服务器上,并更新 Rails 应用以远程执行所有操作。这提供了相当一部分水平扩展能力,但并未解决可用性问题,也不提升繁忙仓库的性能。毕竟,每个仓库仍然只存储在一台机器上。## Spokes:应用级复制的里程碑Spokes 是 GitHub 在 2013 年左右开发的系统,如今已成为行业标准。大多数 Git 托管服务都采用了 Spokes 方法的某种变体。Spokes 在多年来表现优异,主要得益于它做出了三个根本性选择,随着时间的推移被证明是最优的:1. 它不分发 Git 本身;而是在 Packfile 级别工作。
2. 它将所有数据存储为本地 NVMe 磁盘上的实际 Git 仓库。3. 它复制 Git 数据,但保持所有副本同步。由于 Packfiles 的随机读取模式,将普通 Git 仓库存储在 NVMe 驱动器上基本上是确保所有基本 Git 操作保持快速的必要条件。它们还使克隆高效,因为你不需要将数据转换为 Git 客户端期望的格式。它们还让你专注于在 Git 之上构建产品,而不是维护你自己的 Git 分支,使其能够操作你的奇怪仓库。保持所有数据副本的同步也至关重要。
Git 客户端非常不适应最终一致性。如果你的本地 Git 客户端推送了一个提交,但在立即拉取后无法读取它,这会引发混乱。如果你在 CI 流水线中跨越数百个运行器,其中三个在克隆仓库后找不到它们应该测试的提交,这同样糟糕。最终一致性的视图无论是在客户端还是后端都有许多尖锐的边缘。因此,Spokes 付出了极高的复杂性成本来确保系统始终完全一致。Spokes 是一个基于共识的分布式系统。
它通过在不同服务器上存储仓库的多个副本来工作。每当你推送新数据时,一个编排器会将你的推送扩展到所有实例,使每个仓库副本都能接收到一份副本。这种「扇出」通过经典的共识算法 3PC(三阶段提交)同步,以便只有当多数节点确认推送后,推送才会被接受。三阶段提交与 Git 无关。它是一种确保系统中所有节点同意提交或回滚事务的共识算法;它通过三次往返实现这一点。它与二阶段提交非常相似,但引入了额外的「预提交」阶段,以便在事务中间协调器离线时系统能够恢复。
在我们进一步讨论 Spokes 如何使用 3PC 之前,我们需要了解 Git 推送的工作原理。Git 推送有两个组成部分:Packfile 和引用事务。Packfile 是我们已经讨论过的,包含你推送到仓库的对象(blob、树和包含你更改的提交)。事务是通过更新指向你刚刚推送的提交的一个或多个引用(例如你正在工作的分支)来实际发布你的更改。这种分离在这里非常方便,因为推送的提交在引用指向它之前是不可见的(「可达」在 Git 行话中)。这意味着我们可以通过将 Packfiles 同时扇出到所有主机来实现推送的共识(这里不需要同步),然后对引用事务进行三阶段提交,这比 Packfile 小得多,同步起来也更快。
Git 本身支持准备引用事务:它可以锁定引用、验证现有值是否符合预期,然后在收到提交或中止事务的命令之前保持锁定。通过这种设计,我们确保每次推送都在所有副本上完全同步。读取操作(拉取、克隆)可以安全地路由到任何单个副本,因为每个副本始终是最新的。Spokes 的这种设计在过去 13 年中运行良好。当然,Spokes 并不完美 - - 没有系统是完美的。到 2026 年,人们使用 Git 仓库的方式发生了巨大变化,我们也从构建分布式系统的过程中学到了许多重要的经验教训。
时间和经验表明,Spokes 的哪些选择最终是最优的,哪些不是。事实证明,3PC 的水平扩展能力受限是一个关键缺陷。当 Spokes 首次发布时,每个仓库三个副本是最佳选择。你可以用三个副本轻松服务平均仓库,有足够的冗余在一台机器宕机时仍能接受推送。到 2026 年,情况大不相同。企业公司的平均仓库现在是一个巨大的单体仓库。
三个副本不足以服务此类仓库的流量,特别是在 CI 场景下。当然,Spokes 可以运行超过三个副本,除了规模化的尾部效应。三阶段提交在 Git 事务模型上非常优雅,但作为共识算法,它有一个根本限制:每个步骤的延迟受限于集群中最慢的服务器。你添加到集群中的副本越多,推送吞吐量就越差。这种可扩展性限制也适用于另一个方向。当代理以大规模方式处理 Git 仓库时,他们经常在单体仓库之外操作,通过创建大量小型仓库,其中许多是一次性的,大多数很少被触及。
Spokes 在此方面表现不佳,因为它仍然需要为每个仓库保留三个副本。三个大部分时间空闲的副本,无法缩减,因为那样系统将无法保持完全一致,可能导致数据丢失。有了三阶段提交,底线总是太高,上限太低。另一个缺陷,在事前无法预见,但在经历痛苦后变得显而易见,就是 Spokes 在大规模运维中可能很粗暴。由于磁盘上的仓库始终是共识的真实来源,每个仓库副本都非常重要。你必须将仓库视为宠物而非牲畜。
这意味着,首先,你需要知道每个仓库的位置。这增加了对外部数据库的依赖(及潜在的可用性问题),该数据库必须保留一个非常大的路由表,将每个仓库映射到其复制所在的每台机器。每个仓库还必须进行校验和计算,并不断更新该表中的校验和,以确保仓库在磁盘上保持有效。一旦仓库出现问题(相信我,糟糕的事情总是会发生 - - Git 在实践中可能非常挑剔),你必须检测到它并安排修复作业使其恢复健康状态。而且必须快速!因为,再说一次,磁盘上的仓库是真实来源。损坏的副本和缺失的副本一样糟糕。
如果三个副本中有两个损坏,系统将无法接受推送:没有法定人数。## Continuity:写前日志驱动的 Git 存储革命Continuity 是 Cursor 团队开发的 Git 存储系统,采用了一种非常明确的方法:学习 Spokes 做得好的一切,并修复多年来我们现在知道的问题。Continuity 是一个简单的系统(如果一个系统要易于操作,它必须简单)。其核心原语是写前日志(WAL),我们将其存储在 S3 兼容的对象存储中。在生产环境中,我们直接在 S3 上运行,但我们的设计使其可以部署在任何云上。当仓库接收到推送时,我们将推送作为 WAL 条目存储在 S3 中。
我们永远不会确认推送,直到它被完全持久化。每次推送都存储为单独的对象;我们同时将推送的 Packfile 写入磁盘并上传到 S3。然而,上传 WAL 条目并不会发布它。推送只有在我们成功准备其引用事务并在 WAL 索引文件中记录指向 WAL 条目的指针后才可见,WAL 索引文件本身也是存储中的一个对象。这迫使所有推送都必须是线性化的。我们尽量避免每次推送都进行单次 S3 写入,因为在繁忙的仓库中,这会根据 S3 PUT 操作的延迟对推送吞吐量设置硬限制。
通过精心调优的批处理实现,以及只需要与单个本地仓库同步引用事务而非多数副本的需求,我们拥有了一个系统,可以以磁盘允许的速度尽可能快地摄取推送。本地仓库副本当然是存储在非常快的 NVMe 驱动器上的普通 Git 仓库。我们采用了与 Spokes 相同的做法,因为我认为 Spokes 在这一点上完全正确。它允许我们重用 Git 社区的所有优秀开源工作,包括上游 Git 客户端及其许多性能优化。它让我们专注于开发新功能,而不是对 Git 做奇怪的操作。## 共识机制的革新我们已经看到,使 Spokes 集群难以操作的一个问题是跟踪每个仓库在每个服务器上的位置非常重要。
Continuity 的处理方式完全不同。每个仓库都在哪里?答案是「任何地方」。这并不重要!我们将仓库视为磁盘上的热缓存,但真实来源始终是 S3 中的写前日志。该系统是无状态的,没有路由表(也没有需要操作的关系数据库 - - #blessed)。如果访问主机上的仓库副本缺失,我们只需从 WAL 中实体化它。我们可以非常高效地做到这一点,当然我们不希望总是这样做,因为这会浪费资源。
在生产环境中,我们使用会合哈希将仓库 ID 映射到我们期望它所在的节点列表。我们需要的所有路由状态就是仓库 ID 和集群中当前健康节点的集合。但如果此状态不同步(例如,某个节点变得不健康),这完全没关系。我们只需在下一个节点上实体化仓库。那么共识呢?选举呢?哪个服务器是给定仓库的主服务器?这也不重要!没有状态,也没有共识。任何服务器都可以成为主服务器。
对写前日志的所有更新都通过 S3 上的原子比较-交换(CAS)操作进行同步,因此任何仓库实例都可以安全地接收推送。同样,像路由一样,让任意服务器充当主服务器并不是最有效的做法(这会导致 CAS 重试,延迟推送),因此在实践中,我们总是选择同一个服务器作为主服务器,即从会合哈希排名列表中排在第一位的服务器。但在角落情况 - - 例如部署、故障切换、网络抖动 - - 我们根本不在乎哪个服务器是主服务器。该系统被设计为在降级时始终正确,在健康时始终快速。## 复制机制的突破拥有 S3 中的写前日志为扩展开辟了无限可能。我们可以拥有字面意义上的任意数量的副本,因为 S3 的可扩展性无与伦比,所有副本都可以直接从那里赶上。
我们通过发送集群周围的八卦 UDP 数据包来执行乐观复制。这些数据包包含每个副本所需的所有元数据,以便在每次推送后直接从 S3 赶上。 「这太疯狂了,」我听到你从屏幕后面咕哝。 「UDP 不是可靠的传输。」当然不是。在分布式系统中,没有什么是可靠的!线路不可靠,路由不可靠,拓扑结构也不可靠。
但没关系:没关系。每个副本都知道它已赶上最后版本的 WAL 索引的 ETag。当你在副本上执行读取操作时,我们会用期望的 ETag 对 S3 进行有条件 GET。304 响应且无正文(方便的是,这是一个平均不到 10 毫秒的几乎瞬时操作,因为它是元数据仅 S3 操作)意味着我们是最新的,可以立即提供拉取或克隆。200 响应附带最新版本的 WAL 索引,我们用它来赶上后再提供读取。UDP 八卦数据报丢失,或因拓扑变化到达错误服务器又何妨。
所有副本上的所有读取都是完全一致的,因为它们是针对真实来源(即 S3)进行验证的。该系统被设计为在降级时始终正确,在健康时始终快速。这种设计的意义有两个方面。首先,由于系统始终一致,在其上构建基础设施变得微不足道。我们(我们的代理、Web 界面、客户端)总是看到仓库的全局一致视图。其次,由于系统在两个方向上都可扩展,每个仓库都能获得恰到好处的副本数量。
一个大型单体仓库可以部署在数百个副本上,为其 CI 作业提供所有负载。数百万个由代理创建的微小仓库,每个只需要一个副本即可;我们不需要更多来确保可用性,因为 S3 是真实来源。实际上,一个空闲的仓库甚至不需要那么多:当副本一段时间没有收到流量时,我们会从节点磁盘上垃圾回收它,并在下次拉取到来时从 WAL 中再次实体化它。## 压缩机制的优化写前日志需要定期压缩。你不能让日志无限增长:完整恢复会重放每个条目,因此条目越多,成本就越高。巧合的是,普通 Git 仓库也需要定期压缩,尽管 Git 不是基于 WAL。
我们已经看到,Git 存储的基本单元是 Packfile。每次你推送到仓库的远程副本,或拉取到本地副本时,都会创建一个新的 Packfile。这不会无限扩展:每个 Packfile 都有自己的附带索引,允许 Git 高效查找其中包含的对象,但这种查找仅在每个 Packfile 基础上才是高效的。如果你正在查找特定对象,并且仓库有 100 个 Packfile,你需要打开每个 Packfile 的索引并查找对象,直到在其中一个 Packfile 中找到它。一个高效的操作如果需要执行数百或数千次,就不再高效。现代 Git 已经变得非常擅长规避这个问题;它现在支持多 Packfile 索引和增量几何压缩。
但最终你必须硬着头皮进行仓库磁盘上的压缩。从历史上看,这对 Spokes 等系统一直是一个持续的可用性问题,因为压缩是一个非常耗 CPU 的操作,即使是渐进式压缩也是如此,而且必须在系统的所有副本上执行。意外在同一仓库的两个或更多 Spokes 节点上触发维护操作很容易导致仓库故障转移。在 Continuity 中,我们摊销了压缩成本。只有主节点进行压缩,压缩结果同时适用于磁盘上的仓库和 WAL。由于所有副本都跟随 WAL,它们也跟随压缩事件。
副本不进行压缩;它们只是从 S3 下载已经压缩的 Packfiles,以带宽换取 CPU。## 规模化的终极挑战复制和压缩是决定 Git 存储系统在负载下表现如何的两个关键因素。正如我们刚刚看到的,它们本质上是相互关联的:仓库每秒摄入的推送越多,读取性能就越差,因为每次推送的 Packfiles 必须被压缩,以保持 Git 操作的高效。如果你复制这些推送,压缩必须在每个副本上独立执行或进行复制。Continuity 的 WAL 优先设计提供了完全一致的水平扩展:你可以部署任意数量的副本,只读 Git 操作的吞吐量会随着副本数量线性增长。由于集群中的所有副本都完全一致,这使我们能够扩展 Git 协议(克隆、拉取)和 Origin 在仓库之上执行的所有 RPC 操作(Web UI 交互、REST API、我们所有的代理接口等)。
我们已经对包含多达 100 个副本的合成压力测试进行了运行,并看到读取操作的一致线性扩展,而推送吞吐量没有任何回归。集群的推送吞吐量取决于我们能以多快的延迟更新 S3 上的 WAL。使用 S3 Standard,我们可以在压缩和将压缩后的数据复制到所有其他节点的同时,维持高达每秒 120 次推送。我们还在 S3 Express One Zone 上部署了高性能集群,该区域的 PUT 操作延迟更低。在那里,我们可以摄入超过每秒 300 次推送,实际上受限于 Git 压缩磁盘数据的速度。我们正在研究创新的方法来布局这些磁盘数据,以减少压缩的影响:我们的目标是继续优化 Git 仓库摄入代码的速度,而不放松我们对耐用性和一致性保证的严格要求。
## WAL 作为真实来源的哲学S3 是一项伟大的技术。整个由 S3 API 开创的 blob 存储概念已证明是大型数据存储系统的强大构建块,这当然也适用于 Git 仓库托管。这里介绍的设计在许多方面都是新颖的,但它并不是第一个将 Packfiles 存储为 blob 的系统。Azure DevOps(微软自己的 GitHub 竞争对手)有一个非常成功的 Git 存储系统,它将 Packfiles 存储在 blob 存储中,其引用存储在关系数据库(MS SQL Server)中。这样的系统有许多权衡。关系数据库在大型引用事务上扩展良好。
但随后你需要操作一个关系数据库。我们坚信 Git 数据的一致性比任何其他考虑都重要。正是这一点使我们决定设计一个基于 WAL 的系统,不依赖于外部数据库。在生产环境中,Git 仓库可能出现许多问题。静态数据损坏、压缩期间的 bug、推送期间的竞态条件。这是一个充满角落情况的大集合。
大多数这些问题都在 Git 上游中被解决。但并非全部。没有系统是没有 bug 的,即使是那些开源且广泛部署的系统也不例外。我们的一致性模型确保我们跟踪发生在仓库上的每一个基本操作。我们永远不会确认推送,直到它被完全持久化到 WAL。我们使所有推送线性化。
我们访问的每个仓库的每个视图始终完全一致。由于每次推送都在 WAL 中,我们可以查看仓库曾经处于的每种状态。我们拥有所有推送的完整溯源数据,也拥有所有压缩的溯源数据。我们可以回滚和快进每个副本。我们不需要与任何外部数据库同步状态,无论是仅存储引用的数据库,还是存储所有对象数据的数据库。当(而不是如果)我们在 Git 中遇到 bug,我们可以精确地确定发生了什么并回滚它。
除了 Git 中已经存在的 bug,我们还引入了很少的新 bug,因为在这一切过程中,所有 Git 操作都是在磁盘上的普通 Git 仓库上执行的,使用现成的工具。## Origin:面向未来的 Git 托管平台我们深刻意识到托管某人的源代码有多重要。我相信每个阅读并理解这篇文章的人都同样意识到这一点。如果开发者无法推送或拉取其 Git 仓库,一家公司可能会陷入停顿。五分钟 CI 系统停机的生产力成本难以用金钱衡量,但无论如何衡量,都是一个巨大的数字。代理从根本上改变了我们处理软件的方式,并在许多方面使这种情况变得更糟。
更多的代码、更多的 PR、更多的 CI 运行。版本控制是这一切的核心,也是最难在一夜之间改变的东西。我们在 Cursor 内部已经面临这些困难数月之久,并投入了大量思考和精力来构建一个平台,既能解决我们的问题,也希望能为我们的客户解决这些问题。我们当前的重点是提供最顺畅的途径,实现更高的可靠性、更好的性能和更强的扩展能力,并使迁移尽可能无痛。Origin 不是一个实验;它是数十年构建这些系统的经验积累,来自深刻理解这些挑战规模的人。我们拥有经过验证的工程和运维哲学,并致力于随着版本控制生态的演变继续发展它。
我们希望您能信任我们的平台和我们的愿景。 。
