之前写过：2013 年左右， 的源代码控制系统每天为超过 25,000 名开发人员提供服务，所有这些都来自隐藏在楼梯角落的服务器。
1.故事的开始：一切从一台服务器开始
2011年，时任谷歌管理团队技术总监的丹·布洛赫（Dan Bloch）发表了一篇题为《Still All On One: at Scale》的论文。该论文详细介绍了谷歌的源代码控制系统，尽管它每天为“超过 12,000 名用户”提供服务，但仍然依赖于位于主园区 43 号楼楼梯下的一台服务器。
截至 2011 年，这台服务器在 的历史上已经连续运行了 11 年。它见证了谷歌的早期发展，并成功扩展以支持今天的上市公司谷歌。事实上，就在那一刻，一位幸运的 工程师刚刚完成了第 2000 万个变更请求。服务器仍然稳定运行，每天执行“1100万到1200万条命令”。
在本文中，Bloch 描述了一些成功实现服务器扩展的举措。然而，实际情况却并不那么乐观。
如今的谷歌早已脱胎换骨，不再是刚刚起步的小企业。随着实力的增强，谷歌投入巨资安装了一系列业界领先的硬件设施。然而，即使有如此强大的硬件支持，其服务器仍然时不时面临严峻的挑战，所承受的压力也不容小觑。在CPU利用率高峰的高峰时段，系统偶尔会出现TCP连接中断的情况。为了将问题消灭在萌芽状态并确保万无一失，谷歌始终保持热备份服务器处于待命状态。同时，由8名专业管理员组成的精干团队全天候值班，随时准备采取紧急措施，确保源代码控制。服务器的平稳运行避免了任何可能影响日常运营的意外情况。
谷歌多年来一直意识到这是一个潜在风险，工程师们一直在寻找替代方案。但就 的规模而言——“地球上最繁忙的单一服务器，也是最大的源代码控制系统存储库之一”——没有明确的替代方案。
回想当年，Linus 之所以在 2005 年创建 git，是因为他找不到任何可以有效应对 Linux 内核仓库庞大规模的解决方案。
2011 年，谷歌发表了《Still All on One : At Scale》论文后的几年里，这家科技巨头公开披露了其单一存储库中代码更改的惊人规模。具体来说，截至2014年，的单一仓库每周都会经历约1500万行代码变更，涉及约25万个文件的修改。
为了帮助您理解这个数字所带来的震撼，可以将其视为每周从头开始重建整个 2014 版本的 Linux 内核——距离 Linus 首次面临内核管理挑战已有九年了。
2. 少有人走的路：坚持单一仓库决策并全力投资 Piper
自 2008 年以来， 工程师一直在考虑该单一服务器的替代方案。
他们曾短暂考虑过拆分单个存储库的想法，但最终拒绝了——事后看来，这是一个重大的、改变行业的决定，因为它为未来几十年大规模处理代码复杂性奠定了基础。设定标准。
在随后的几年里，谷歌发明并领导了许多大型单一仓库工具的开发，并极大地影响了单一仓库文化的流行。 （例如，参见他 2016 年的论文《Why of Lines of Code in a 》。）
然而，坚持使用单一仓库的决定在当时并不是一个显而易见的选择。到目前为止， 的单一仓库架构已经相对自然地发展起来。这是本组织第一次必须明确承诺通过它。这一决定与当时 Git 社区的流行观点形成鲜明对比：应该拥有“更多、更小的存储库”，部分原因是克隆一个巨大的单一存储库的成本很高（后来 采用了云客户端） （诸如 in the Cloud（简称 CitC）之类的工具解决了这个问题）。
也曾短暂考虑过迁移到 SVN，认为 SVN 或许能够满足他们所需要的规模。然而，当工程师发现没有明确的迁移路径时，这个想法并没有实现。
最终，正如 Linus 在 2005 年所做的那样，唯一的出路似乎就是创造一些全新的东西。
新系统被称为 Piper（源于一些工程师对飞机的喜爱，是“Piper is Piper”的缩写），至今仍在使用。
3. 移民：四年的“移山”之旅
一旦工程师弄清楚替代方案是什么样子（Piper 将采用分布式设计，并且“最初构建在标准的 基础设施上”），下一步就是实际创建和实施新的解决方案。 Piper部署完成后，他们还需要将所有流量切换到新系统，并迁移整个单仓库。
这项努力花了四年多的时间。
乍一看，这个时间跨度令人震惊，但在十一年的时间里，它已经深深嵌入谷歌的软件生态系统中，几乎触及工程的各个层面。
当迁移开始时，工具所依赖的 API 已经有 300 个。更令人惊讶的是生产环境对.理想情况下，版本控制系统应该严格面向内部，并且在崩溃时不应影响实时流量；然而，Piper 团队继续发现情况并非如此。总体而言，执行迁移的工程师必须非常小心，以避免破坏 最终用户体验。
更复杂的是，2010 年，谷歌因其在操作系统中使用许可接口而被起诉。直到2021年，最高法院才对此案作出最终判决。
在这个过渡时期， 的工程团队深深关心如何在不完全复制原有接口的情况下实现从 API 的平滑过渡。为了解决这一棘手的挑战，他们转向了业内广受推崇的创新策略——洁净室法。
这个解决方案首先由技术文档编写者精心制定了详细的规范，然后交给了从未接触过原生 API 的独立工程师团队。它们就像一张白纸，从零开始，基于这张纯粹的设计蓝图，构建了全新的系统架构，保证了迁移过程的无缝衔接和独创性，并巧妙地避免了直接迁移带来的潜在法律和技术风险。复制接口。
随着时间的推移，该项目的基调发生了变化。 Piper 最初是一个新的、很酷的概念，工程师们对此充满热情，并且它可能是解决问题的关键。然而，随着时间的推移，他们的工作变得越来越紧迫。
在迁移过程中， 的开发工作仍在继续。过去几年，互联网的负载不断增加，风险也相应增加。 API 上有了很多新的开发，包括现在重要的系统，例如 Blaze（ 的构建系统，后来开源为 Bazel）和 TAP（ 的内部测试平台）。
这个决定之所以大胆、不同寻常，不仅是因为它花费了工程团队数年的辛苦筹划和投入，更因为其结果的两极分化——要么是成功实现，要么是所有的努力瞬间就实现了；彻底失败，所有的努力都白费了，中间没有任何妥协。
鉴于维护源代码的单一权威版本至关重要， 明白，除非 Piper 系统能够完全取代现有解决方案，否则所有改进都将是徒劳的。 Piper的命运就在成功与失败之间：要么完美接管，成为新的源代码控制中心；要么成为新的源代码控制中心。否则它就会消失，迫使谷歌回到老路，面临比以前更困难的服务器困境。
正因为如此，当Piper项目组面临实施PAXOS算法的关键时刻时，尽管尚未完全掌握PAXOS的使用，但还是果断地从团队中借调了相关领域的专家。此举展示了谷歌强大的内部资源共享和协同运作机制，可以在关键时刻调动跨部门的顶尖人才，保证Piper项目的顺利进行。
随着迁移过程的进展，已经实现了一个关键的里程碑——提交操作可以平滑同步到Piper双系统，确保数据的无缝过渡。为了验证新系统的稳健性，Piper团队在特定区域实施了小规模部署测试，结果令人鼓舞。
然而，真正的挑战是赢得 25,000 名工程师的青睐并引导他们进入 Piper 的新时代。这不仅是一次技术创新，更是一次人心之旅。 Piper团队责任重大，尤其是高级工程师。他们亲自走访，耐心沟通，一一解决疑虑，争取每一位同事的理解和支持，从而扫清了项目进展的最后障碍。
一个普通的周六，已经扩充到十人的Piper项目核心团队齐聚园区会议室。现任首席科学家杰夫·迪恩也亲临现场。他的到来不仅是对项目进展的现场考察，更是对团队士气的鼓舞。
尽管Piper团队做了精心的准备，无数次的排练，编写了详细的脚本，布置了多重监控，制定了详细的应急指引，但他们内心深处的担忧却难以抹去——这十位工程师肩上的担子或许决定命运谷歌的运营至关重要，一个错误就可能导致不可预测的后果。
当迁移命令正式下达后，短短几分钟，源码控制系统就进入了只读模式，一切都仿佛凝固了，为数据迁移的那一刻做好了铺垫。会议室里，所有人都屏息等待。空气中弥漫着一种既期待又焦虑的情绪。仿佛每个人的心跳声都清晰可闻，共同见证了历史性的转折。
然后...迁移成功完成。
没有数据丢失； 的生产实例没有受到影响。
就这样，多年的拼命努力得到了回报。
4.尘埃落定：谷歌的黄金时代
改用 Piper 立即降低了 的运营风险，并消除了对单个超载服务器的依赖。但随着时间的推移，迁移还通过源控制服务器现在支持的新流量规模解锁了一系列新系统。
自 2012 年迁移以来，自动提交的数量呈爆炸式增长。
当今时代，当人们提到谷歌内部工具系统时，自然会联想到一个资源丰富、实力雄厚的巨头公司。他们想象这是一家能够用充裕的时间和空间精心打磨产品的公司。拥有一系列尖端技术产品的巨头公司。
然而，追溯到2012年，谷歌向Piper的迁移过程却为我们揭示了完全不同的视角——当时，谷歌已经上市第八年，是一家充满创业激情和大胆创新精神的公司。的黄金时代。这些年来，谷歌表现出了勇于挑战、攀登新高度的勇气。 Piper迁移项目的意义远远超出了技术创新。它更深刻地体现了工程文化的核心价值观——创新、协作和追求卓越。
参考链接：
