当您拥有大型代码库时，依赖项链可能会变得非常深。 即使是简单的二进制文件也常常依赖于数万个 build 目标。在这种规模下，在单台机器上以合理的时间完成构建根本是不可能的：没有任何构建系统可以绕过机器硬件所受的基本物理定律。唯一可行的办法是使用支持分布式构建的构建系统，其中系统执行的工作单元分布在任意数量且可扩缩的机器上。假设我们已将系统的工作分解为足够小的单元（稍后会详细介绍），这样我们就可以根据愿意支付的费用，尽可能快速地完成任何大小的 build。这种可伸缩性是我们通过定义基于制品的构建系统一直努力实现的目标。
远程缓存
最简单的分布式 build 类型是仅利用 远程缓存的 build，如图 1 所示。
图 1. 显示远程缓存的分布式 build
执行 build 的每个系统（包括开发者工作站和持续集成系统）都共享对通用远程缓存服务的引用。此服务可以是快速的本地短期存储系统（如 Redis），也可以是云服务（如 Google Cloud Storage）。每当用户需要构建制品（无论是直接构建还是作为依赖项构建）时，系统都会先检查远程缓存，看看该制品是否已存在于其中。如果是，则可以下载该制品，而不是构建它。如果不是，系统会自行构建该制品，并将结果上传回缓存。这意味着，不经常更改的低级别依赖项可以构建一次并跨用户共享，而无需由每个用户重新构建。在 Google，许多制品都是从缓存中提供的，而不是从头开始构建的，这大大降低了运行构建系统的成本。
为了使远程缓存系统正常运行，构建系统必须保证 build 完全可重现。也就是说，对于任何 build 目标，都必须能够确定该目标的输入集，以便相同的输入集在任何机器上都能生成完全相同的输出。这是确保下载制品的結果与自行构建制品的結果相同的方法。请注意，这要求缓存中的每个制品都以其目标及其输入的哈希为键，这样不同的工程师就可以同时对同一目标进行不同的修改，而远程缓存会存储所有生成的制品并适当地提供它们，而不会发生冲突。
当然，为了从远程缓存中获得任何好处，下载制品的速度需要比构建制品的速度更快。情况并非总是如此，尤其是当缓存服务器远离执行 build 的机器时。Google 的网络和构建系统经过精心调整，能够快速共享构建结果。
远程执行
远程缓存不是真正的分布式 build。如果缓存丢失，或者您进行了需要重新构建所有内容的低级别更改，您仍然需要在本地机器上执行整个 build。真正的目标是支持远程执行，其中执行 build 的实际工作可以分布在任意数量的工作器上。图 2 描绘了一个远程执行系统。
图 2. 远程执行系统
在每台用户机器上运行的 build 工具（用户可以是人类工程师，也可以是自动 build 系统）都会向中央 build 主机发送请求。 build 主机会将请求分解为组件操作，并安排在可扩缩的工作器池中执行这些操作。每个工作器都会使用用户指定的输入执行要求其执行的操作，并写出生成的制品。这些制品在执行需要它们的其他机器之间共享，直到生成最终输出并将其发送给用户。
实现此类系统最棘手的部分是管理工作器、主机和用户本地机器之间的通信。工作器可能依赖于其他工作器生成的中间制品，并且最终输出需要发送回用户的本地机器。为此，我们可以基于前面介绍的分布式缓存，让每个工作器将其结果写入缓存并从缓存中读取其依赖项。主机阻止工作器继续执行，直到它们依赖的所有内容都已完成，在这种情况下，它们将能够从缓存中读取其输入。最终产品也会被缓存，从而允许本地机器下载它。请注意，我们还需要一种单独的方法来导出用户源代码树中的本地更改，以便工作器可以在构建之前应用这些更改。
为了使此方法正常运行，前面介绍的基于制品的 build 系统的所有部分都需要协同工作。build 环境必须完全自描述，以便我们无需人工干预即可启动工作器。build 流程本身必须完全自包含，因为每个步骤都可能在不同的机器上执行。输出必须完全确定，以便每个工作器都可以信任从其他工作器收到的结果。对于基于任务的系统来说，提供此类保证非常困难，这使得在基于任务的系统之上构建可靠的远程执行系统几乎不可能。
Google 的分布式 build
自 2008 年以来，Google 一直使用分布式构建系统，该系统同时采用远程缓存和远程执行，如图 3 所示。
图 3. Google 的分布式构建系统
Google 的远程缓存称为 ObjFS。它由一个后端组成，该后端将构建输出存储在分布在我们生产机器群中的 Bigtable 中，以及一个前端 FUSE 守护程序（名为 objfsd），该守护程序在每台开发者的机器上运行。FUSE 守护程序允许工程师浏览 build 输出，就像它们是存储在工作站上的普通文件一样，但文件内容仅针对用户直接请求的少数文件按需下载。按需提供文件内容大大减少了网络和磁盘使用量，与我们将所有 build 输出存储在开发者的本地磁盘上相比，该系统能够以两倍的速度进行构建。
Google 的远程执行系统称为 Forge。Blaze（Bazel 的内部等效项）中的 Forge 客户端（称为 Distributor）会向在我们的数据中心内运行的作业（称为 Scheduler）发送每个操作的请求。Scheduler 会维护操作结果的缓存，如果系统中的任何其他用户已创建该操作，则允许其立即返回响应。否则，它会将操作放入队列中。大量执行器作业会不断从此队列中读取操作、执行这些操作，并将结果直接存储在 ObjFS Bigtable 中。执行器可以将这些结果用于未来的操作，或者最终用户可以通过 objfsd 下载这些结果。
最终结果是一个可扩缩的系统，可高效支持 Google 执行的所有 build。Google 的 build 规模确实非常庞大：Google 每天运行数百万个 build，执行数百万个测试用例，并从数十亿行源代码中生成 PB 级的 build 输出。这样的系统不仅让我们的工程师能够快速构建复杂的代码库，还允许我们实现大量依赖于我们的 build 的自动化工具和系统。