总阅读量:次

⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 阮一峰的网络日志 「阮一峰」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

《ACM通信》有一篇论文《为什么 Google 要把几十亿行代码放在一个库？》，作者是谷歌基础设施小组的工程师。作者详细讲述了Google的代码为什么全部放在一个库里面。

img

一、概述

谷歌最早使用 CVS 进行代码管理，1999年改为 Perforce。那时是一台 Perforce 主机，加上各种缓存机。

当时，全公司的代码就在一个仓库里面，后来一直沿用这种做法。由于规模不断增长，Perforce 已经无法满足需求，谷歌就开始使用自己开发的版本管理系统 Piper。

Piper 架设在谷歌自己的分布式数据库系统（以前叫 Bigtable，现在改名 Spanner）之上，分布在全世界10个数据中心，保证世界各地的谷歌员工都有良好的访问速度。

目前，这个代码仓库包含10亿个文件、3500万次提交记录，大小为86TB，用户达到几万人。工作日每秒有50万次请求，高峰时80万次，大部分来自自动构建和测试系统。

谷歌90%以上的代码，放在 Piper 里面。对于那些开源的、需要外部协作的项目，代码放在 Git，主要是 Android 项目和 Chrome 项目。Git 的特点是，所有历史记录都会复制到用户的本地机器，所以不适合大型项目，必须拆分成更小的库。以 Android 为例，该项目一共包含800多个独立的仓库。

二、Piper 的设计

2.1 结构

整个仓库采用树状结构。每个团队有自己的目录。目录路径就是代码的命名空间。每个目录都有负责人（owner），他负责批准该目录的文件变动。

2.2 权限控制

Piper 支持文件级别的权限控制。99% 的代码对所有用户可见，只有少部分重要的配置文件和机密的关键业务，设有访问限制。

如果机密信息不小心放上了 Piper，文件可以被快速清除。并且，所有的读写都有日志，管理员能够查到谁读过这个文件。

2.3 工作流

Piper 的工作流（workflow）如下图。

img

开发者先创建文件的本地拷贝，这叫做”工作区”（workspace）。完成开发后，工作区的快照共享给其他开发者进行代码评审。只有通过了评审，代码才能合并到中央仓库。

2.4 客户端

大多数开发者通过一个叫做 CitC 的客户端，访问 Piper。开发者通过 CitC 浏览和同步 Piper 上的文件，但是编辑和修改是在自己工作区，里面只保存有变动的文件（一个工作区一般不超过10个文件）。CitC 带有云储存机制，每个工作区就是云上的一个目录。通过代码评审以后，这些文件才从 Citc 合并进 Piper。

2.5 主干开发

Google 采用”主干开发”（trunk-based development）。代码一般提交到主干的头部。这样保证了所有用户看到的都是同一份代码的最新版本。

“主干开发”避免了合并分支时的麻烦。谷歌一般不采用分支开发，分支只用来发布。大多数时候，发布分支是主干某个时点的快照。以后的除错和功能增强，都是提交到主干，必要时 cherry-pick 到发布分支。与主干长期并行的开发分支，在谷歌极少见。

由于不采用"分支开发"，谷歌引入新功能，一般在代码中使用开关控制。这避免了另起一个分支，也使得通过配置切换功能变得容易，一旦新功能发生故障，很容易切换回旧功能。等到新功能稳定，再彻底删除旧代码。谷歌有类似A/B测试的路由算法，评估代码的表现，由于存在配置开关，这种测试很容易实现。

2.6 代码评审

所有代码合并进仓库之前，都必须进行代码评审。大部分评审对所有人开放，任何谷歌员工都可以对代码提意见或者提交变动。

代码评审的依据是《Google 代码风格指南》。谷歌有一个叫做 Critique 的工具，可以查看每一行代码的历史演变。

2.7 自动测试

评审完成后，会自动运行测试。通过测试以后，代码就合并进了 Piper 仓库，整个过程不需要人工干预。

三、单一代码仓库的优点

（1）统一的版本

整个公司的代码，有统一的版本和路径，不存在找不到文件的最新版本这样的问题。

（2）广泛的代码共享和复用

任何人都可以浏览和使用全公司的代码，这大大促进了代码的共享和复用。

（3）简化的依赖管理

如果你是库文件或者 API 的作者，因为所有人的代码都在一个库里面，所以很容易找到依赖你的所有下游代码。

每当代码变动，所有依赖你的代码都会自动构建。如果有大量的构建失败，那么系统会自动撤销这次提交。这样也保证了所有代码依赖的都是最新版本，避免依赖不同的版本所导致的冲突。

另外，由于代码的边界很清楚，所以不会发生循环依赖。而且，API的作者也很容易发现，别人怎么使用他的API。

（4）原子性变动

由于每次代码变动所导致的影响，都在一个仓库里面，所以都属于原子性的变动。因此，很容易撤销，或者预先测试它所造成的影响。

为了防止错误提交，谷歌引入了”预提交”（即在提交之前，先分析一下依赖它的代码是否会构建失败）。

（5）大规模代码析构

单一代码仓库为查找和分析代码，提供了巨大的方便。

Google的静态分析引擎 Tricorder 定时运行，对代码进行分析。比如，C++ 11 标准公布以后，很容易找到所有需要改进的变量声明语句，进行性能优化。该引擎还对许多错误提供"一键修正"的功能，同时产出大量的统计数据。

此外，编译器团队也会对不同语言的所有代码进行分析，找出不合理的代码和过时的API。

单一代码仓库的缺点

单一代码仓库的主要缺点是，所有工具都必须自己写，因为市场上没有能够管理这种规模的代码仓库的软件。

总结

单一代码仓库，适合提倡透明开放的大型软件公司，不适合小公司和有大量私密代码的公司。

原文：http://m.cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext

文章目录
  1. 1. 一、概述
  2. 2. 二、Piper 的设计
  3. 3. 三、单一代码仓库的优点
  4. 4. 单一代码仓库的缺点
  5. 5. 总结