编译丨诺亚

出品 | 51CTO技术栈（微信号：blog51cto）

写在前面：大约在2013年，愚公移山谷歌的谷歌谷歌源代码控制系统每天为超过25000名开发者提供服务 ，所有这些服务都来自于藏身于楼梯角落的版历版本一台服务器。

1.故事开端：一切从单一Perforce服务器开始

2011年，时年数亿时任谷歌Perforce管理团队技术主管的行代新的系统Dan Bloch发表了一篇题为《依然全在一服务器上：大规模下的Perforce（Still All On One Server: Perforce at Scale）》的论文。该论文详细阐述了谷歌的迁移源代码控制系统 ，即便每天为“超过12000名用户”提供服务，到全仍旧只依赖位于主校区43号楼楼梯下方的控制一台单一Perforce服务器 。

截至2011年，免费模板愚公移山这台单一服务器已经在谷歌的谷歌谷歌历史中连续运行了十一年之久 。它见证了初创时期的版历版本谷歌 ，并成功扩展以支持如今的时年数亿上市公司谷歌 。事实上，行代新的系统就在那时，迁移一位幸运的到全谷歌工程师刚刚完成了第2000万次变更请求。服务器依旧稳定运行，每日执行“1100万至1200万条命令”。

在论文中，Bloch描述了一些成功实现服务器扩展的举措。源码库然而，实际情况并非如此乐观 。

如今的谷歌早已脱胎换骨，不再是那个初出茅庐的小企业 。随着实力的壮大  ，谷歌投入重金，装配了一系列业界顶尖的硬件设施。然而，即便坐拥如此强大的硬件支持 ，其服务器仍时常面临严峻考验，服务器租用承载的压力不容小觑。在CPU利用率触顶的高峰时段，系统偶尔会遭遇TCP连接中断的困扰。为防患于未然 ，确保万无一失，谷歌始终保持一台热备份服务器随时待命，与此同时，一支由八名专业管理员构成的精干队伍全天候值守 ，随时准备采取应急措施
，力保源代码控制服务器的平稳运行，避免任何可能影响谷歌日常运作的香港云服务器意外发生 。

多年来 ，谷歌内部一直意识到这是一个潜在风险 ，工程师们也在寻找替代方案 。但在谷歌这样的规模——“地球上最繁忙的单一Perforce服务器，以及任何源代码控制系统中最大的存储库之一”——并没有明确的替代选择。

遥想当年，Linus之所以在2005年创建git，就是因为他找不到任何能够有效应对Linux内核仓库庞大体量的解决方案。建站模板

在谷歌于2011年发布《依然全在一服务器上：大规模下的Perforce》论文后的几年里 ，这家科技巨头公开披露了其单一仓库中惊人的代码变更规模。具体到2014年，谷歌的单一仓库每周会经历约1500万行代码的变化，涉及大约25万个文件的修改。

为帮助你直观感受这一数字的震撼 ，不妨将其类比为每周都要从零开始重构整个2014版的Linux内核——而这距离Linus首次直面内核管理挑战 ，已过去了整整九年
。云计算

2.少有人走的路：坚持单一仓库的决策，孤注一掷选择Piper

自2008年起，谷歌的工程师们就开始考虑对这台单一服务器的替代方案。

他们一度考虑过拆分单一仓库的想法 ，但最终否决了这一方案——事后看来，这是一个重大的、具有行业变革意义的决定 ，因为它为未来几十年大规模处理代码复杂性设定了标准。

此后数年间，谷歌发明并引领了许多大型单一仓库工具的发展 ，并显著影响了单一仓库文化的普及
。（例如，可以参阅其2016年的论文
，《为何谷歌将数十亿行代码存储在单一仓库中》。）

然而，当时继续坚持单一仓库的决策并不是一个显而易见的选择 。直到这一刻
，谷歌的单一仓库架构相对自然地发展起来；这是第一次迫使组织必须明确承诺采用这一架构。这一决定与当时Git社区盛行的观点形成了鲜明对比：人们应该拥有“更多且更小的仓库” ，部分原因在于克隆庞大单一仓库所带来的高昂成本（后来 ，谷歌通过SourceFS和云客户端（Clients in the Cloud
，简称CitC）等工具解决了这个问题）。如果谷歌选择了遵循常规，而不是明确肯定对单一仓库架构的承诺，今天的局面可能大相径庭。

谷歌也曾短暂考虑过从Perforce迁移到SVN ，认为SVN或许能够满足他们所需的规模。然而，当工程师们发现没有清晰的迁移路径时，这一设想并未成功 。

最终 ，如同Linus在2005年所做的一样，唯一的前进道路似乎就是创造全新的东西。

这套新系统被称为Piper（源自某些工程师对飞机的喜爱，同时也是“Piper is Piper expanded recursively”的缩写） ，至今仍在使用中。

3.迁移：耗时四年的“移山”之旅

一旦工程师们确定了替代方案的大致形态（Piper将采用分布式设计 ，并“基于标准的谷歌基础设施构建，最初是Bigtable”），接下来的任务便是实际创建并实施这套新方案。待Piper部署完毕后，他们还需将所有流量切换到新系统，并迁移整个谷歌单一仓库。

这一努力耗时超过四年之久。

乍看之下，这个时间跨度令人震惊，但在长达十一年的时间里，Perforce已深深植根于谷歌的软件生态系统之中
，几乎触及每一个工程层面 。

迁移开始时
 ，已有300种工具依赖于Perforce的API 。更为惊人的是，生产环境对于Perforce的依赖不断浮现。理想情况下，版本控制系统应当严格面向内部，即使崩溃也不应影响实时流量；然而Piper团队不断发现情况并非如此 。总体而言，执行迁移的工程师们必须极其谨慎，以免破坏谷歌终端用户体验。   

事态进一步复杂化的是，在2010年 ，Oracle因谷歌在Android操作系统中使用授权Java API接口而对其提起诉讼。直到2021年 ，该案才由最高法院作出最终裁决。

在这段过渡期中 ，谷歌的工程师团队深切忧虑着如何在不全面复刻原有接口的前提下 ，实现从Perforce API平滑过渡的难题。为了解决这一棘手挑战，他们转向了一个广受业界推崇的创新策略——净室设计（clean room design）方法 。

这一方案首先由技术文档撰写者精心制定详尽的规格说明，随后交由一群完全未接触过原生API的独立工程师团队，他们犹如一张白纸，从零开始，依据这份纯净的设计蓝图
，构建起全新的系统架构，确保了迁移过程的无缝衔接与原创性，巧妙规避了直接复制接口所带来的潜在法律与技术风险。

随着时间推移，项目基调发生了变化。起初 ，Piper是一个新颖酷炫的概念 ，工程师们对此充满热情 ，它可能是解决Perforce问题的关键。然而 ，随着时间流逝 ，他们的工作变得日益紧迫 。

在迁移过程中 ，谷歌的开发工作未曾停歇，几年间，Perforce上的负载持续增加，风险随之升高。Perforce API上出现了大量新开发，包括如今举足轻重的系统如Blaze（谷歌的构建系统，后开源为Bazel）和TAP（谷歌内部测试平台）。

这项决策之所以堪称大胆且不同寻常，不仅仅因为它耗费了工程师团队数年的辛勤规划与投入，更在于其成果性质的极端两极化——要么圆满达成
，所有心血瞬间开花结果；要么彻底落空，一切努力付诸东流，中途绝无半点折中收获。

考虑到维护源代码唯一权威版本的至关重要性 ，谷歌明白，除非Piper系统能全面替代现有方案 ，否则一切改进都将徒劳无功 。Piper的命运掌握在成败之间：要么它将完美接棒
，成为源代码控制的全新中枢；要么它将黯然退场 ，迫使谷歌重拾旧路 ，还将面对比以往更加艰巨的Perforce服务器困境
。

正因如此，当Piper项目组面临实现PAXOS算法的关键时刻 ，他们果断从Google Spanner团队中借调了相关领域的专家，即便Spanner自身尚未完全掌握PAXOS的运用 。这一举动彰显了谷歌内部资源共享与协同作战的强大机制，关键时刻能够跨部门调动顶尖人才，确保Piper项目顺利推进。

随着迁移进程的深入
，一个关键里程碑得以实现——提交操作已能顺畅地同步至Perforce与Piper双系统，确保数据的无缝过渡 。为了验证新系统的稳健性 ，Piper团队在特定区域内实施了小范围的部署测试 ，效果令人鼓舞。

然而，真正的挑战在于赢得25,000名谷歌工程师的心，引导他们跨越至Piper的崭新时代。这不仅是一场技术上的革新，更是人心的征途。Piper团队肩负重任
，尤其是面对那些资深工程师，他们亲自登门拜访 ，耐心沟通 ，逐一化解疑虑 ，力求每一位同事的理解与支持，从而扫清项目前行的最后障碍。   

在某个平凡的周六 ，已扩充至十人的Piper项目核心团队 ，齐聚于园区的会议室内。Jeff Dean ，现任Alphabet的首席科学家 ，亦亲临现场，他的到来不仅是对项目进度的实地考察，更像一股强心剂 ，鼓舞着团队士气
。

尽管Piper团队早已进行了周密的准备，演练了无数遍，编写了详尽的脚本 ，安排了多重监控，并制定了详实的应急指南
 ，但内心深处的担忧却难以抹去——这十位工程师肩上的担子，可能决定了谷歌的运营命运，一次不慎 ，或将引发不可预知的后果。

当迁移指令正式下达
，短短几分钟内
，源控制系统进入只读模式 ，一切仿佛凝固，只为那一瞬间的数据迁移铺平道路 。会议室里，众人屏息静待 ，空气中弥漫着一种既期待又忐忑的情绪，每个人的心跳声似乎都能清晰听见 ，共同见证着历史性的转折点。

然后……迁移顺利完成。

没有数据丢失；谷歌的生产实例未受影响。

就这样  ，历时多年的孤注一掷获得了回报。

4.尘埃落定 ：独属于谷歌的黄金年代

切换到Piper立即降低了谷歌的操作风险  ，摆脱了对单个过载Perforce服务器的依赖
。但随着时间推移
，迁移也通过源控制服务器现在支持的新流量规模解锁了一系列新系统 。

自2012年的迁移之后
，自动化提交的数量开始激增
。

在当今时代 ，提及谷歌的内部工具体系，人们往往会自然而然地将其与一家资源丰沛 、实力雄厚的巨型公司联系起来，想象中这是一家能够在充裕的时间与空间里，精心打磨出一系列前沿科技产品的巨无霸公司。

然而 ，追溯至2012年，谷歌从Perforce向Piper的迁移历程，却为我们揭开了一个截然不同的视角——彼时，正值谷歌上市后的第八个年头
，一个充满创业激情与大胆创新精神的黄金年代。在这段岁月里，谷歌展现出一股无畏挑战、勇攀高峰的拼搏劲头。Piper迁移项目的意义远不止于技术层面的革新
，它更深层次地折射出谷歌工程师文化的核心价值——创新
、协作与追求卓越。   

https://www.reddit.com/r/programming/comments/1dsf4z3/around_2013_googles_source_control_system_was/

https://graphite.dev/blog/google-perforce-to-piper-migration