构建更优软件以更好地构建软件

我们管理着负责交付Quip和Slack Canvas后端的构建流水线。一年前，我们正在追寻令人兴奋的想法，以帮助工程师更快地交付更好的代码。但我们面临一个巨大的问题：构建耗时60分钟。构建速度如此之慢，导致整个流水线敏捷性下降，反馈到工程师那里也过晚。

我们通过结合现代高性能构建工具（Bazel）与经典软件工程原则解决了这个问题。以下是我们是如何做到的。

思考构建（与代码）性能

想象一个简单的应用程序。它有一个提供API和数据存储的后端服务器，以及一个呈现用户界面的前端。像许多现代应用程序一样，前端和后端是解耦的；它们可以独立开发和交付。

这个构建的依赖图如下所示：

我们用箭头表示构建元素（如源文件和可部署工件）之间的依赖关系，形成一个有向无环图。这里，我们的后端依赖于一组Python文件，这意味着每当Python文件更改时，我们都需要重新构建后端。同样，当TypeScript文件更改时，我们需要重新构建前端——但Python文件更改时则不需要。

将构建建模为由明确定义的工作单元组成的图，让我们可以应用与加速应用代码相同类型的性能优化：

• 减少工作量。存储已完成的高成本工作结果，以便只执行一次，用内存换取时间。
• 分担负载。将正在进行的工作分散到更多的计算资源上并行执行，以更快完成，用计算资源换取时间。

缓存与并行化

这些技术对大多数工程师来说都很熟悉，从代码角度思考有助于巩固它们如何应用于构建系统。以这个Python示例为例：

1
2

def factorial(n):
    return n * factorial(n-1) if n else 1

计算阶乘可能非常昂贵。如果需要经常计算，运行速度会很慢。但直觉上，我们知道一个数的阶乘不会改变。这意味着我们可以应用策略1来缓存该函数的结果。这样，对于任何给定的输入，它只需要运行一次。

1
2
3

@functools.cache
def factorial(n):
    return n * factorial(n-1) if n else 1

缓存存储我们的输入（n）并将其映射到相应的输出（factorial()的返回值）。n是缓存键：它类似于构建图中的源文件，函数的输出对应于构建的工件。

细化我们的直觉，我们可以说这个函数需要具备几个特定属性才能使缓存生效。它需要是封闭的：只使用显式给定的输入来产生特定的输出值。它需要是幂等的：任何给定输入集的输出总是相同的。否则，缓存就是不健全的，会产生相当令人惊讶的效果。

一旦有了缓存，我们希望最大化命中率：即调用factorial()时从缓存中获得答案的次数比例，而不是通过计算。我们定义工作单元的方式有助于保持高命中率。

为了说明这个想法，让我们看一段更复杂的代码：

1
2
3
4
5

@functools.cache
def process_images(
  images: list[Image],
  transforms: list[Transform]
) -> list[Image]: ..

这个函数附加了缓存，但缓存效果不佳。该函数接受两个输入集合：一个图像列表和一个要应用于每个图像的变换列表。如果调用者更改了其中任何一个输入，比如在列表中添加一个Image，他们也就更改了缓存键。这意味着我们无法在缓存中找到结果，必须从头开始做所有工作。

换句话说，这个缓存粒度不够细，因此命中率很低。更有效的代码可能如下所示：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

def process_images(
  images: list[Image],
  transforms: list[Transform]
) -> list[Image]:
  new_images = []
  for image in images:
    new_image = image
    for transform in transforms:
       new_image = process_image(new_image, transform)
    new_images.append(new_image)

  return new_images

@functools.cache
def process_image(image: Image, transform: Transform) -> Image:
  ...

我们将缓存移动到一个更小的工作单元——将单个变换应用于单个图像——并相应地使用更小的缓存键。我们仍然可以保留更高级别的API；只是不在那里缓存。当调用者使用一组输入调用更高级别的API时，我们可以通过仅处理我们以前未见过的Image和Transform组合来满足该请求。其他所有内容都来自缓存。我们的缓存命中率和性能都应该得到提升。

缓存帮助我们减少工作量。现在让我们看看如何分担负载。如果我们将图像处理分散到多个CPU核心上的线程中呢？

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

def process_images_threaded(
  images: list[Image],
  transforms: list[Transform]
) -> list[Image]:
  with ThreadPoolExecutor() as executor:
    futures = []
    for image in images:
      futures.append(executor.submit(process_images, [image], transforms))

    # 返回顺序任意的图像！
    return [future.result() for future in futures.as_completed(futures)]

让我们弄清楚能够并行运行工作所需的特性，同时也注意一些关键的注意事项。

• 与缓存类似，我们需要严格且完整地定义要并行化的工作的输入和输出。
• 我们需要能够跨某种边界移动这些输入和输出。这里是一个线程边界，但也可能是进程边界或到其他计算节点的网络边界。
• 我们并行运行的工作单元可能以任意顺序完成或失败。我们的代码必须管理这些结果，并清楚地记录它提供的保证。在这里，我们注意到图像可能不按相同顺序返回的警告。这是否可接受取决于API。

工作单元的粒度也在我们能够有效并行化的程度上发挥作用，尽管其中涉及很多细微差别。如果我们的工作单元数量少但规模大，我们就无法将它们分散到尽可能多的计算资源上。任务大小和数量之间的正确权衡因问题而异，但这是我们在设计API时需要考虑的问题。

过渡到构建性能

如果你是软件工程师，你可能已经多次应用这些技术来提高代码性能。让我们将这些原则和直觉应用到构建系统中。

在Bazel构建中，你定义构成有向无环图的目标。每个目标都有三个关键要素：

1. 作为此构建步骤依赖项或输入的文件。
2. 作为此构建步骤输出的文件。
3. 将输入转换为输出的命令。

（实际情况更复杂一些，但就目前而言，这足以理解要点。）

让我们回到最初的那个示例应用程序。

Bazel目标定义可能类似于以下伪代码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

python_build(
    name = "backend",
    srcs = ["core/http.py", "lib/options.py", "data/access.py"],
    outs = ["backend.tgz"],
    cmd = "python build.py", 
)
ts_build(
    name = "frontend",
    srcs = ["cms/cms.ts", "collab/bridge.ts", "editing/find.ts"],
    outs = ["frontend.tgz"],
    cmd = "npm build"
)

你可以将构建目标视为定义（但不调用！）一个函数。注意到从上面的Python示例中延续下来的一些主题吗？我们详尽地定义了每个构建步骤的输入（srcs）和输出（outs）。我们可以将目标的srcs（以及构建它们的任何目标的传递性srcs，我们稍后会看到更多）视为我们希望缓存的函数的输入。

因为Bazel在沙盒中构建，所以将输入转换为输出的cmds只能触及我们声明的输入文件。而且由于我们的输入和输出只是磁盘上的文件，我们解决了跨边界移动它们的问题：直接复制即可！最后，我们必须向Bazel做出承诺：我们的构建步骤的cmds实际上是幂等且封闭的。

当我们做到这些时，我们就免费获得了一些非凡的能力：

• Bazel自动缓存构建操作的结果。当目标的输入未更改时，使用缓存的输出——无需构建成本！
• Bazel将构建操作分散到我们允许的尽可能多的CPU核心上，甚至分散到构建集群中的多台机器上。
• Bazel仅执行我们所需输出工件必需的那些操作。换句话说，我们总是为所需的输出运行最少量必需的工作。

就像在我们的代码示例中一样，当我们拥有一个由幂等、封闭且粒度适中的构建单元组成的明确定义的依赖图时，我们将从Bazel的魔力中获得最大收益。这些品质使得Bazel的原生缓存和并行化能够提供巨大的速度提升。

理论讲得够多了。让我们深入探讨实际问题。

为什么Quip和Canvas更难

关键在于：Quip和Canvas比我们之前看的简单示例要复杂得多。这是我们为了理解构建如何工作而绘制的真实图表。不用担心阅读所有细节——我们将使用一个示意图来探讨问题及其解决方案。

当我们分析图表时，发现了一些关键缺陷，这意味着我们没有获得从Bazel获得速度提升所需的特性：

• 有向无环依赖图 → 图没有明确定义，实际上包含循环！
• 幂等、封闭、大小合适的工作单元。→ 构建执行单元非常庞大，并非全部都是幂等的，并且封闭性是一个挑战，因为许多构建步骤会改变工作目录。
• 保持缓存命中率高的细粒度缓存键。→ 我们的构建相互关联性太强，导致缓存命中率为零。想象一下，我们尝试调用的每个缓存“函数”都有100个参数，其中总有2-3个会改变。

如果我们一开始就把Bazel用于构建，那将是无效的。命中率为零的情况下，Bazel的高级缓存管理无济于事，Bazel的并行化相比构建代码中已有的临时并行化也几乎不会有任何提升。为了获得Bazel的魔力，我们首先需要做一些工程工作。

分离关注点

我们的后端代码和构建代码深深地交织在一起。在没有类似Bazel的构建系统的情况下，我们默认使用应用内框架来编排构建图中的各个步骤。我们使用Python的多进程策略和核心代码库中内置的异步例程来管理并行化。Python业务逻辑汇集了Protobuf编译并构建了Python和Cython工件。最后，由更多Python脚本编排的tsc和webpack等工具将TypeScript和Less转换为Slack Canvas和Quip桌面及Web应用程序使用的独特前端捆绑格式。

当我们开始解开这个戈尔迪之结时，我们聚焦于后端和构建代码的结合如何扭曲了前端构建的图。以下是该图更易于理解的表现形式。

请注意，在我们的前端捆绑包“之上”的依赖树是多么庞大。它不仅包括它们的TypeScript源代码和构建过程，还包括整个已构建的Python后端！这些Python源代码和工件是每个前端捆绑包的传递性源文件。这意味着，不仅是TypeScript更改，每一个Python更改都会改变前端的缓存键（我们之前提到的百个参数之一），导致需要昂贵的完全重建。

这个构建问题的关键在于Python应用程序和TypeScript构建之间的依赖边。

这条边平均每次构建花费我们35分钟——超过总成本的一半！——因为每次更改都会导致完整的后端和前端重建，而前端重建尤其昂贵。

在处理这个问题的过程中，我们意识到性能成本不仅仅是构建问题。它是我们在整个应用程序（后端、前端和构建代码）中普遍未能分离关注点的一个症状。我们存在耦合：

• 后端和前端之间
• Python和TypeScript基础设施及工具链之间
• 构建系统和应用程序代码之间

除了在数量上使构建性能变差之外，这些耦合还在我们的软件开发生命周期中产生了质的影响。工程师无法推理他们后端更改的爆炸半径，因为它也可能破坏前端。或者构建系统。或者两者都破坏。而且因为我们的构建需要一个小时，我们无法通过在拉取请求级别运行构建来给他们早期警告。缺乏健康信号，以及推理潜在后果的困难，意味着我们太频繁地破坏构建和主分支，而这不是工程师的过错。

一旦我们通过关注点分离的视角理解了问题，就变得很清楚，仅靠构建系统的更改我们无法成功。我们必须干净利落地切断前端和后端、Python和TypeScript、应用程序和构建之间的依赖关系。这意味着我们必须投入比原计划多得多的时间。

在几个月的时间里，我们煞费苦心地梳理了每个构建步骤的实际要求。我们用Starlark（Bazel用于构建定义的语言）重写了Python构建编排代码。Starlark是一种故意受限的语言，其限制旨在确保构建满足Bazel生效的所有要求。在Starlark中构建帮助我们强制执行与应用程序代码的完全分离。在需要保留Python脚本的地方，我们重写了它们，去除了除了Python标准库之外的所有依赖：没有指向我们后端代码的链接，也没有额外的构建依赖。我们省略了所有并行化代码，因为Bazel会为我们处理。我们将在下面思考分层时重新审视这个范式。

原始构建代码的复杂性使得定义“正确”行为具有挑战性。我们的构建代码大多没有测试。唯一正确的标准是现有构建系统在特定配置下产生的结果。为了让我们自己放心，并给工程师灌输信心，我们构建了一个用Rust编写的工具，用于比较现有流程产生的工件与我们新代码产生的工件。我们利用差异来指导我们找到新逻辑不完全正确的地方，并迭代，再迭代。

当我们最终能够绘制出一个新的构建图时，这项工作得到了回报：

我们已经切断了那三个关键耦合，并且排除了Python更改可能破坏构建或改变前端输出的任何担忧。我们的构建逻辑与它们构建的单元一起位于BUILD.bazel文件中，具有定义良好的Starlark API以及构建代码和应用程序代码之间的清晰分离。我们的缓存命中率大幅上升，因为Python更改不再构成TypeScript构建的缓存键的一部分。

这项工作的结果是构建时间的大幅减少：如果前端被缓存，我们可以在短短25分钟内构建整个应用程序。这是一个很大的改进，但仍然不够！

通过分层设计组合性

一旦我们切断了后端←→前端的耦合，我们更仔细地查看了前端构建。为什么它需要35分钟？当我们梳理构建脚本时，发现了更多关注点分离的挑战。

我们的前端构建器非常努力地追求性能。它接受一大组输入（TypeScript源代码、LESS和CSS源代码，以及由环境变量和命令行选项控制的各种旋钮和开关），计算需要进行的构建活动，将这些活动并行化到一组工作进程上，并将输出整理成可部署的JavaScript捆绑包和CSS资源。以下是构建图这一部分的草图。

就像我们在这个项目中发现的许多情况一样，这个策略代表了编写时一系列合理的权衡：在缺乏更大构建框架的情况下，这是加速构建一部分的务实尝试。而且它比不并行化相同工作要快！

这个实现有两个关键挑战。

1. 就像我们上面的process_image()示例一样，我们的可缓存单元太大了。我们接受所有源文件并生成所有捆绑包。如果只有一个输入文件更改了呢？这会改变缓存键，我们必须重建所有内容。或者，如果我们想只构建一个捆绑包，以满足构建过程中其他地方的需求呢？我们运气不好；我们必须依赖整个构建过程。
2. 我们正在跨进程并行化工作，这是好的——除非我们可以跨机器并行化，那些拥有更多CPU核心的机器。如果我们有这些可用资源，我们无法在这里使用它们。而且我们实际上让Bazel在其核心功能——并行化独立的构建步骤——上效果变差：Bazel和脚本的工作进程在争夺同一组资源。脚本甚至可能正在并行化Bazel已经知道不需要的工作！

在这两个方面，我们都很难以新的方式组合构建功能：无论是不同形式的编排多个捆绑包构建，还是不同的并行化策略。这是一个分层违规。

如果我们像这里一样，绘制从操作系统到应用层的能力层级，我们可以看到构建器的边界跨越了层级。它结合了业务逻辑、任务编排框架的重要部分以及并行化。我们真正想要的只是顶层——逻辑——这样我们就可以在新的编排上下文中重新组合它。我们最终得到了一个工作编排器（构建器）嵌套在另一个工作编排器（Bazel）中，两个层级争夺同一资源池的份额。

为了更有效，我们真的只需要做得更少。我们删除了大量代码。新版本的前端构建器要简单得多。它不进行并行化。它的“API”接口小得多。它接受一组源文件，并构建一个输出捆绑包，TypeScript和CSS被独立处理。

这个新的构建器高度可缓存且高度可并行化。每个输出工件都可以独立缓存，仅以其直接输入为键。捆绑包的TypeScript构建和CSS构建可以并行运行，既可以彼此并行，也可以与其他捆绑包的构建并行。我们的Bazel逻辑可以决定范围（一个捆绑包？两个？全部？），而不是试图管理所有捆绑包的构建。

再次看到与我们示例process_images() API的共鸣了吗？我们创建了细粒度、可组合的工作单元，这极大地提高了我们并行化和缓存的能力。我们还分离了业务逻辑及其编排的关注点，使得我们能够在新的Bazel构建中重新组合逻辑。

这个改变给我们带来了一些非常好的结果：

• 因为捆绑包构建以及TypeScript和CSS构建可以彼此独立缓存，我们的缓存命中率上升了。
• 只要有足够的资源，Bazel可以同时并行化所有捆绑包构建和CSS编译步骤。这为我们带来了完全重建时间的显著减少。

作为额外的好处，我们不再运行自己的并行化代码。我们已经将该责任委托给Bazel。我们的构建脚本只有一个关注点：编译前端捆绑包的商业逻辑。这对可维护性来说是一个胜利。

成果与心得

我们使构建速度大大加快。更快的构建带来工程师更短的周期时间、更快的事件解决和更频繁的发布。将这些原则应用到我们的整个构建图之后，我们得到的构建比开始时快了多达六倍。

从定性的角度来看，我们得出的关键原则是：软件工程原则适用于整个系统。而整个系统不仅仅是我们的应用程序代码。它还包括我们的构建代码、我们的发布流水线、为开发和生产环境设置的策略，以及这些组件之间的相互关系。

所以，以下是我们对你的建议，无论你是编写应用程序代码、构建代码、发布代码，还是全部：分离关注点。思考整个系统。为组合性而设计。当你这样做时，应用程序的每个方面都会变得更强健——而且，作为一个愉快的副作用，你的构建也会运行得更快。