简介

Bazel Google开源的，是一款与 Make、Maven 和 Gradle 类似的开源构建和测试工具。 它使用人类可读的高级构建语言。Bazel 支持多种语言的项目，可为多个平台构建输出。Bazel支持任意大小的构建目标，并支持跨多个代码库和大量用户的大型代码库。是Google主推的一种构建工具。

优劣势

优势

官方说明：

• 高级构建语言。Bazel 使用人类可读的抽象语言，在较高的语义级别描述项目的构建属性。与其他工具不同，Bazel 的运作涉及库、二进制文件、脚本和数据集的概念，可以避免将单个调用编写到编译器和链接器等工具的复杂性。

• Bazel 既快速又可靠。Bazel 会缓存之前完成的所有工作，并跟踪文件内容和 build 命令的更改。这样，Bazel 就会知道何时需要重新构建应用，并且只会重新构建。为了进一步加快构建速度，您可以将项目设置为以高度并行的方式进行构建。

• Bazel 是多平台的。Bazel 可在 Linux、macOS 和 Windows 上运行。Bazel 可以从同一项目为多个平台（包括桌面设备、服务器和移动设备）构建二进制文件和可部署软件包。

• Bazel 支持扩缩。在处理包含 10 万个以上源文件的构建时，Bazel 可保持敏捷性。它可以处理数以万计的多个代码库和用户群。

• Bazel 可扩展。它支持许多语言，您可以扩展 Bazel，以支持任何其他语言或框架。

其它人总结：

• 很方便地获取第三方依赖；

• 构建多语言的软件系统，One Tool，All Languages；

• 优秀的缓存和依赖计算，编译速度非常优异；

• DevOps部署云构建，可极大复用宝贵的计算资源；

快(Fast)

Bazel的构建过程很快，它集合了之前构建系统的加速的一些常见做法。包括：

1.增量编译。只重新编译必须的部分，即通过依赖分析，只编译修改过的部分及其影响的路径。

2. 并行编译。将没有依赖的部分进行并行执行，可以通过--jobs来指定并行流的个数，一般可以是你机器CPU的个数。遇到大项目马力全开时，Bazel能把你机器的CPU各个核都吃满。

3. 本地缓存+远程缓存。Bazel将构建过程视为函数式的，只要输入给定，那么输出就是一定的。而不会随着构建环境的不同而改变（当然这需要做一些限制），这样就可以分布式的缓存/复用不同模块，这点对于超大项目的速度提升极为明显。

4. 远程构建。默认情况下，Bazel 会在本地机器上执行构建和测试。通过 Bazel 构建的远程执行，您可以将构建和测试操作分散到多个机器（例如数据中心）。

可伸缩(scalable)

Bazel号称无论什么量级的项目都可以应对，无论是超大型单体项目monorepo、还是超多库的分布式项目multirepo。Bazel还可以很方便的集成CD/CI ，并在云端利用分布式环境进行构建。

它使用沙箱机制进行编译，即将所有编译依赖隔绝在一个沙箱中，比如编译golang项目时，不会依赖你本机的GOPATH，从而做到同样源码、跨环境编译、输出相同，即构建的确定性。

跨语言(multi-language)

如果一个项目不同模块使用不同的语言，利用Bazel可以使用一致的风格来管理项目外部依赖和内部依赖。典型的项目如 Ray。该项目使用C++构建Ray的核心调度组件、通过Python/Java来提供多语言的API，并将上述所有模块用单个repo进行管理。如此组织使其项目整合相当困难，但Bazel在此处理的游刃有余，大家可以去该repo一探究竟。

可扩展(extensible)

Bazel使用的语法是基于Python裁剪而成的一门语言：Startlark。其表达能力强大，往小了说，可以使用户自定义一些rules（类似一般语言中的函数）对构建逻辑进行复用；往大了说，可以支持第三方编写适配新的语言或平台的rules集，比如rules go。 Bazel并不原生支持构建golang工程，但通过引入rules go ，就能以比较一致的风格来管理golang工程。

劣势

• 隔离未遵循程惯例：从策略上看，Bazel从其他遗留库获取代码，这是必须的，否则Bazel自己完蛋了；其他库要想从Bazel获取，用户也必须使用Bazel，用户真的被强绑定了。

• 依赖于JVM。

安装

采取“使用二进制安装程序”，参考：https://bazel.build/install/ubuntu?hl=zh-cn#binary-installer

工程介绍

参考官方示例项目：git clone https://github.com/bazelbuild/examples

具体结构如下：

examples
└── cpp-tutorial
    ├──stage1
    │  ├── main
    │  │   ├── BUILD
    │  │   └── hello-world.cc
    │  └── WORKSPACE
    ├──stage2
    │  ├── main
    │  │   ├── BUILD
    │  │   ├── hello-world.cc
    │  │   ├── hello-greet.cc
    │  │   └── hello-greet.h
    │  └── WORKSPACE
    └──stage3
       ├── main
       │   ├── BUILD
       │   ├── hello-world.cc
       │   ├── hello-greet.cc
       │   └── hello-greet.h
       ├── lib
       │   ├── BUILD
       │   ├── hello-time.cc
       │   └── hello-time.h
       └── WORKSPACE

使用Bazel管理的项目一般包含以下几种Bazel相关的文件：WORKSPACE(同WORKSPACE.bazel)，BUILD(同BUILD.bazel)，.bzl 和 .bazelrc 等。

如何工作

当运行构建或者测试时，Bazel会：

1. 加载和目标相关的BUILD文件

2. 分析输入及其依赖，应用指定的构建规则，产生一个Action图。这个图表示需要构建的目标、目标之间的关系，以及为了构建目标需要执行的动作。Bazel依据此图来跟踪文件变动，并确定哪些目标需要重新构建

3. 针对输入执行构建动作，直到最终的构建输出产生出来

WORKSPACE文件--项目（工作区）

WORKSPACE文件用于将目录及其内容识别为 Bazel 工作区，它位于项目目录结构的根目录中。该文件可能为空，或可能定义加载 Bazel 工具和 rules 集，以及包含对构建输出所需的外部依赖项的引用。

BUILD文件--软件包

软件包指包含名为BUILD或BUILD.bazel的ef="https://bazel.build/concepts/build-files?hl=zh-cn">BUILD文件的目录。代码库中的主要代码组织单元是软件包。软件包是相关文件的集合，以及如何使用这些文件生成输出工件的规范。软件包中包含其目录中的所有文件及其下的所有子目录，但包含BUILD文件的文件除外。根据该定义，任何文件或目录都不得是两个不同软件包的一部分。

BUILD 文件包含 Bazel 的几种不同类型的指令。每个 BUILD 文件都需要至少一条规则作为一组指令，告诉 Bazel 如何构建所需的输出，例如可执行文件或库。BUILD 文件中的 build 规则的每个实例都称为一个目标target，并指向一组特定的源文件和依赖项。 目标还可以指向其他目标。

查看 stage3/lib/BUILD 文件：

cc_library(
    name = "hello-time",
    srcs = ["hello-time.cc"],
    hdrs = ["hello-time.h"],
    visibility = ["//main:__pkg__"],
)

在 stage3/main/BUILD 文件：

cc_library(
    name = "hello-greet",
    srcs = ["hello-greet.cc"],
    hdrs = ["hello-greet.h"],
)

cc_binary(
    name = "hello-world",
    srcs = ["hello-world.cc"],
    deps = [
        ":hello-greet",
        "//lib:hello-time",
    ],
)

在此示例中，hello-world 目标会实例化 Bazel 的内置 cc_binary rule。该规则指示 Bazel 从hello-world.cc 源文件和两个依赖项hello-greet和//lib:hello-time构建独立的可执行文件。

为使构建成功，您可以使用可见性属性让 lib/BUILD 中的 //lib:hello-time 目标明确显示给 main/BUILD 中的目标。这是因为默认情况下，目标仅对同一 BUILD 文件中的其他目标可见。Bazel 使用目标可见性来防止出现包含有实现细节的库泄露到公共 API 等问题。

target定义--目标

软件包是目标软件包的容器，在软件包的BUILD文件中定义。大多数目标是两种主要类型之一：文件和规则。如示例中的hello-world和hello-greet等。

文件进一步分为两种。源文件通常由用户编写并签入代码库。生成的文件（有时称为派生文件或输出文件）不会被签入，但是从源文件生成的。

第二种目标使用规则声明。每个规则实例都用于指定一组输入文件与一组输出文件之间的关系。规则的输入可以是源文件，但也可以是其他规则的输出。

.bzl文件

如果你的项目有一些复杂构造逻辑、或者一些需要复用的构造逻辑，那么可以将这些逻辑以函数形式保存在.bzl文件，供WORKSPACE或者BUILD文件调用。其语法跟Python类似。

.bazelrc文件

对于Bazel来说，如果某些构建动作都需要某个参数，就可以将其写在此配置中，从而省去每次敲命令都重复输入该参数。Bazel 会按以下顺序读取可选的 bazelrc 文件：

1. 系统级文件，位于 etc/bazel.bazelrc。

2. 位于 $workspace/tools/bazel.rc 的 Workspace rc 文件。

3. 主目录文件位于 $HOME/.bazelrc 中

此处列出的每个 bazelrc 文件都有一个对应的标志，可用于停用这些标志（例如 --nosystem_rc、--noworkspace_rc 和 --nohome_rc）。您还可以通过传递 --ignore_all_rc_files 启动选项让 Bazel 忽略所有 Bazelrcs。

构建

运行以下命令以切换到 stage3 目录：

cd stage3

运行以下命令：

bazel build //main:hello-world

在目标标签中，//main:部分是BUILD文件相对于工作区根目录的位置，hello-world是BUILD文件中的目标名称。

Bazel 会生成如下所示：

INFO: Found 1 target...
Target //main:hello-world up-to-date:
  bazel-bin/main/hello-world
INFO: Elapsed time: 0.167s, Critical Path: 0.00s

运行以下命令可删除输出文件，并可选择停止服务器。：

bazel clean

运行

执行二进制文件以获得最终的 Hello world 消息：

bazel-bin/main/hello-world

依赖图

• 生成依赖图：

INFO: Found 1 target...
Target //main:hello-world up-to-date:
  bazel-bin/main/hello-world
INFO: Elapsed time: 0.167s, Critical Path: 0.00s

• 将生成的输出图文字描述, 粘贴到 GraphViz, 生成的依赖图如下

构建原理

调度模型

传统构建系统有很多是基于任务的，例如 Ant，Maven，Gradle。用户可以自定义"任务"(Task），例如执行一段 shell 脚本。用户配置它们的依赖关系，构建系统则按照顺序调度。

​

基于 Task 的调度模型:这种模式对使用者很友好，他可以专注任务的定义，而不用关心复杂的调度逻辑。构建系统通常给予任务制定者极大的"权利"，比如 Gradle 允许用户用 Java 代码编写任务，原则上可以做任何事。

如果一个任务，在输入条件不变的情况下，永远输出相同的结果，我们就认为这个任务是"封闭"(Hermeticity) 的。构建系统可以利用封闭性提升构建效率，例如第二次构建时，跳过某些输入没变的 Task，这种方式也称为 增量构建。

不满足封闭性的任务，则会导致增量构建失效，例如 Task 访问某个互联网资源，或者 Task 在执行时依赖随机数或时间戳这样的动态特征，这些都会导致多次执行 Task 得到不同的结果。

Bazel 采用了不同的调度模型，它是基于目标Target【制品 (Artifact) 的】。Bazel 官方定义了一些规则 (rule)，用于构建某些特定产物，例如 c++ 的 library 或者 go 语言的 package，用户配置和调用这些规则。他仅仅需要告诉 Bazel 要构建什么 target，而由 Bazel 来决定如何构建它。

规则由官方和可信赖第三方维护，规则产生的任务，满足封闭性需求，这使得用户可以信赖系统的增量构建能力。

bazel基于 Target 的调度模型如下图所示：

​File 表示原始文件，Target 表示构建时生成的文件。当用户告诉 Bazel 要构建某个 Target 的时候，Bazel 会分析这个文件如何构建（构建动作定义为 Action，和其他构建系统的 Task 大同小异），如果 Target 依赖了其他 Target，Bazel 会进一步分析依赖的 Target 又是如何构建生成的，这样一层层分析下去，最终绘制出完整的执行计划。

并行编译

Bazel 精准的知道每个 Action 依赖哪些文件，这使得没有相互依赖关系的 Action 可以并行执行，而不用担心竞争问题。基于任务的构建系统则存在这样的问题：

​

基于任务的构建系统存在竞争问题:两个 Task 都会向同一个文件写一行字符串，这就造成两个 Task 的执行顺序会影响最终的结果。要想得到稳定的结果，就需要定义这两个 Task 之间的依赖关系。

Bazel 的 Action 由构建系统本身设计，更加安全，也不会出现类似的竞争问题。因此我们可以充分利用多核 CPU 的特性，让 Action 并行执行。

通常我们采用 CPU 逻辑核心数作为 Action 执行的并发度，如果开启了远端执行 (后面会提到)，则可以开启更高的并发度。

增量编译

对 Bazel 来说，每个 Target 的构建过程，都对应若干 Action 的执行。Action 的执行本质上就是"输入文件 + 编译命令 + 环境信息 = 输出文件"的过程。

​Action 的描述: 如果本地文件系统保留着上一次构建的 outputs，此时 Bazel 只需要分析 inputs, commands 和 envs 和上次相比有没有改变，没有改变就直接跳过该 Action 的执行。

这对于本地开发非常有用，如果你只修改了少量代码，Bazel 会自动分析哪些 Action 的 inputs 发生了变化，并只构建这些 Action，整体的构建时间会非常快。

不过增量构建并不是 Bazel 独有的能力，大部分的构建系统都具备。但对于几万个文件的大型工程，如果不修改一行代码，只有 Bazel 能在一秒以内构建完毕，其他系统都至少需要几十秒的时间，这简直就是 降维打击 了。

Bazel 是如何做到的呢？

首先，Bazel 采用了 Client/Server 架构，当用户键入 bazel build 命令时，调用的是 bazel 的 client 工具，而 client 会拉起 server，并通过 grpc 协议将请求 (buildRequest) 发送给它。由 server 负责配置的加载，ActionGraph 的生成和执行。

构建结束后，Server 并不会立即销毁，而 ActionGraph 也会一直保存在内存中。当用户第二次发起构建时，Bazel 会检测工作空间的哪些文件发生了改变，并更新 ActionGraph。如果没有文件改变，就会直接复用上一次的 ActionGraph 进行分析。

这个分析过程完全在内存中完成，所以如果整个工程无需重新构建，即便是几万个 Action，也能在一秒以内分析完毕。而其他系统，至少需要花费几十秒的时间来重新构建 ActionGraph。

远程缓存

增量构建极大的提升了本地研发的构建效率，但有些场合它的效果不是很好，例如 CI 环境通常采用“干净”的容器，此时没有上一次的构建数据，只能全量构建。

即使是本地研发，如果从远端同步代码时修改了全局参数，也会导致增量构建失效。

缓存 (Remote Cache) 与远程执行 (Remote Execution) 可以很好的解决这个问题。

前面聊到，Action 满足封闭性，即相同的 Action 信息一定产生相同的结果。因此可以建立 Action 到 ActionResult 的映射。为了便于索引，Bazel 把 Action 信息通过 sha256 哈希算法压缩成摘要 (Digest)，把 Digest 到 ActionResult 的映射存储在云端，就可以实现 Action 的跨构建共享。

​Action 共享示意图

这里的 Storage 是完全基于内容寻址的，即“一个 Digest 唯一对应一个 ActionResult”，内容寻址的好处是不容易污染存储空间，因为修改任何一行代码会计算出不同的 Digest，不用担心污染别人的 ActionResult。内容寻址的存储引擎，被称为Content Addressable Storage(CAS)，如果没有特别强调，本文后续使用简称 CAS 来表述。

CAS 里存放的任何文件，无论是 Action 的 Meta 信息还是编译产物二进制，都被称为 Blob。

为保证 CAS 的存储空间被有效利用，通常会使用 LRU 算法管理 CAS 里存储的 Blob，当存储空间写满时，最久没被访问的 Blob 就会被自动淘汰，这样就保证了空间里的 Blob 是最活跃的。

Bazel 将构建拆分为独立的步骤，这些步骤称为操作。每项操作都有输入、输出名称、命令行和环境变量。系统会为每个操作明确声明所需的输入和预期输出。

您可以将服务器设置为构建输出（即这些操作输出）的远程缓存。这些输出由输出文件名列表及其内容的哈希值组成。借助远程缓存，您可以重复使用其他用户的 build 中的构建输出，而不是在本地构建每个新输出。

远程构建

既然 ActionResult 可以被不同的 Bazel 任务共享，说明 ActionResult 和 Action 在哪里执行并没有关系。因此，Bazel 在构建时，可以把 Action 发送给另一台服务器执行，对方执行完，向 CAS 上传 ActionResult，然后本地再下载。

这种做法减少了本地执行 Action 的开销，使得我们设置更高的构建并发度。

Bazel 为 Remote Cache 和 Remote Execution 设计了专门的协议 Remote Execution API，用于规范协议的客户端和服务端的行为。

完整的流程如下图所示：

​可以看到，Client 和 Server 的直接交互是很少的，大部分情况还是和 CAS 交互，这部分采用了增量的设计，Client 先调用 findMissingBlobs 接口，该接口的请求参数是一堆 Blob Digest 列表，返回值是 CAS 缺失的 Digest 列表。这样 Client 只上传这些 Blob，可以减少网络传输的浪费。

Remote Execution API 是一套通用的远程执行协议，客户端部分由 Bazel 实现，服务端部分可自行定制。Bazel 团队开发两款开源实现，分别是 Bazel Remote(CAS) 和 Buildfarm (Remote Executoin & CAS)，除此之外也有 Buildbarn，Buildgrid 等开源实现以及 Engflow，Buildbuddy 这样的企业版。

企业版除了提供更稳定，弹性的远程执行服务外，通常还提供数据分析能力，用户可以根据自己的条件选择合适的开源软件或企业版服务。

外部依赖缓存 (repository_cache)

前面我们主要分析了基于 Action 的增量构建，缓存和远程执行机制。现在让我们看看 Bazel 是如何管理外部依赖的。

大部分项目都没法避免引入第三方的依赖项。构建系统通常提供了下载第三方依赖的能力。为了避免重复下载，Bazel 要求在声明外部依赖的时候，需要记录外部依赖的 hash，例如下面的这种形式：

Bazel 会将下载的依赖，以 CAS 的方式存储在内置的 repository_cache 目录下。你可以通过bazel info repository_cache 命令查看目录的位置。

Bazel 认为通过 checksum 机制，外部依赖应该是全局共享的，因此无论你的本地有多少个工程，哪怕使用的是不同的 Bazel 版本，都可以共享一份外部依赖。

除此之外，Bazel 也支持通过 1.0.0 这样的 SerVer 版本号来声明依赖，这是 Bazel6.0 版本加入的功能，也是官方推荐使用的，具体做法可以查看官网 相关部分。

如何高效使用 Bazel

Bazel 为了正确性和高性能，做了很多优秀的设计，那么我们如何正确的使用这些能力，让我们的构建性能“起飞”呢， 我们将从本地研发和 CI pipeline 两种场景进行分析。

本地研发

本地研发通常采用默认的 Bazel 配置即可，无需为增量构建和 repository_cache 做额外配置，Bazel 默认就处理的很好。

使用时应该信任 bazel 的增量构建机制，即便是从远端仓库同步了代码，也可以直接 build，无须先通过 bazel clean 清理环境。

至于 Remote Cache 和 Remote Execution，则需要结合网络状况和 Action 的执行开销，决定是否开启，参数是 --remote_cache 和 --remote_execution。

正确开启 bazel 的 remote 能力

正确开启 remote_cache 和 remote_execution 对构建效率有显著作用，但网络或 Action 特性，也可能导致收益不明显甚至劣化。

举个例子说明使用 remote_cache 的利弊：

我们假设 Action 的执行时间是 a，上传缓存和下载缓存的时间分别是 b 和 c， 缓存命中率是μ。如果不使用 remote cache，耗时恒定为 a，如果使用 remote cache， 命中缓存耗时是 c，不命中则是 a + b， 结合命中率，可以求出耗时的数学期望是 μc + (1 - μ)(a + b)。也就是说，只有 μc + (1 - μ)(a + b) < a才有收益。

例如 Action 执行时间是 500ms，上传产物时间是 200ms，下载产物时间是 100ms，缓存命中率是 30%， 代入到式子中：0.3 * (500 + 200 - 100)ms = 180ms

实践中，我们不一定能对 Action 做如此精细的数据分析，但可以根据网络状况大致估算。Bazel 提供了精细化的控制方式，可以控制某一种类型的 Action 是否启用 remote_cache，例如：

针对 CppLink 类型的 Action 禁用了 remote_cache 能力，其他类型则可以正常使用。甚至还可以通过 no-remote-cache-upload，设置为只禁止上传缓存，不禁止下载缓存。

对于缓存的精细化设置属于比较高级的功能，Bazel 暂时没有过多开放相关能力，相关的文档也不全。或许我们可以期待一下，未来能使用更方便的配置来管理。

缓存命中率调优

上面的例子可以看出，Action 的缓存命中率直接决定了 remote cache 的收益，如何优化缓存命中率呢？

前文介绍原理时，我们知道 Action 由 inputs 和 commands 组成，inputs 指执行 Action 所需的目录结构和文件内容。而 commands 包括了参数 (args), 执行路径 (workdir) 和环境变量 (envs)。

当缓存命中率不符合预期时，我们需要对 Action 的详情进行调试。

bazel 的 --execution_log_binary_file 参数可以把 Action 的详细信息打印到文件里。

对比两次构建的 Action 详情，就可以知道是什么参数发生了变化。

该参数导出的原始信息是二进制格式，有一些特殊字符，如下图所示：

​

可以借助 bazel 的 execution_log_parser 工具，把它变成更可读的形式：

该工具需要源码编译 bazel：

使用 parser 工具把 log 变成可读形式, 转换后的文件如下图所示：

​转换后的 execution_log

之后就可以用文本对比工具，对两次构建生成的 execution_log 进行对比。

CI pipeline

再来看到 CI 场景，如果你在公司里搭建了持续集成流水线，则需要考虑更多的东西。在公司内网的模式下，CI 的网络往往不再是瓶颈，我们应该完整的使用 Remote Cache 和 Remote Execution 的能力。

搭建 Remote Execution 服务

使用 Remote 能力的前提是部署支持 Remote Execution 协议的服务，一般来说，开源产品 buildfarm 或 buildbarn 就足够使用了，如果对性能和数据分析有更加极致的要求，可以考虑企业版产品或者基于 Remote Execution API 协议自研。

Remote Execution 服务的架构设计是一个很大，也很有趣的话题。篇幅关系，本文不过多深入细节，但提供几点设计要求可以参考：

Remote Execution 服务通常包括 scheduler 和 worker 组件，集群规模较小时，单 scheduler 可以调度所有 Action，而规模较大时，需要多 scheduler 协同，这是一个很大的挑战。

scheduler 的职责是把 Action 调度给 最合适 的 worker，并且分派的过程 越快越好。

如何衡量任务调度的好与坏，一方面尽量让 Action 均匀分布，避免排队时间过长，另一方面尽量利用 worker 的本地文件缓存，减少重复的文件下载。

不同客户端发来的相同 Action，可以考虑在服务端进行合并。

不同类型的 worker，需要根据系统的负载，进行弹性伸缩，以确保资源的高效利用。

客户端调度增强

除了 Remote Execution 服务，另一块需要注意的地方是客户端调度。不同于本地构建，CI 场景为了追求强隔离性，往往以实时运行 Docker Container 的方式提供构建环境。也就是说，构建环境不包含上一次构建的数据。

这种模式对于 Bazel 构建很不友好，不仅外部依赖要重新下载，而且增量编译功能也无法使用。但我们也有办法尽可能的加快构建速度。

CI 环可复用的要素

首先是使用 Remote Cache 和 Remote Execution 服务，在没有增量构建的场景下，Remote Cache 和 Remote Execution 提供的优化效果是非常夸张的，根据我的观察，提速普遍在 70% 以上，甚至能达到 90%。

其次是缓存本地数据，例如 trivas CI 这样的流水线编排系统，就支持对特定目录进行缓存。它的原理是把目录打包上传到对象存储，下次构建时再下载下来。我们可以将 Bazel 的 repository_cache 和 action_local_cache 相关的目录进行缓存，下次构建就可以直接复用。

如果条件允许的话，甚至可以要求流水线提供常驻容器，这样 Bazel 的进程都可以长期保留着，下次构建时，直接 Attach 到已有的容器上执行命令即可。这种方式有望在 CI pipeline 场景实现秒级构建，这是多么酷的一件事情啊！

不过，常驻容器对安全性也带来了一定的挑战，企业具体采用那种方案，也应该因实际情况而异。

总结

本文从原理方面介绍了 Bazel 高性能的原因，从实践方面针对本地研发和 CI pipeline 两种场景给出了建议。

Bazel 在设计时非常注重“增量”，“缓存”和“并行”，这是高性能的 基础。而 Bazel 官方推出并维护了不同语言的构建规则，也保证了构建过程时封闭，可靠的，这是高性能的 前提。除此之外，针对工作空间的完整 ActionGraph 的内存缓存机制 (skyframe)，使得 Bazel 对大型项目拥有秒级的构建速度，这也是其他主流构建系统远远达不到的。

在实际使用中，我们不仅需要深度了解 Bazel 的缓存和远程执行机制，也需要根据不同的场景配置不同的参数。本地场景需要关注网络和缓存命中率，以决定是否开启远端缓存和远端执行能力。CI 场景则需要关心流水线的调度能力，尽可能的提升数据的复用。

相关资料来源：

bazel官方中文文档 bazel官方中文文档网址2

Bazel学习笔记

如何评价 Google 开源的 Bazel ？

Bazel使用了解

编译构建工具-bazel

如何挖掘 Bazel 的极致性能