Caveat Configurator：当配置变成代码

在 Jane Street 配置系统时，我们面临两个要求：灵活和安全。我们在全球交易多种金融工具，使用的大多是内部开发的工具，因此每位工程师要负责许多系统。只需做少量修改就能复用通用系统，可能意味着我们可以迅速抓住机会，而不用从头构建新系统。

我们交易的也是自己的钱。小缺陷可能让我们错失机会，或无法在某个市场交易；紧密循环中的大缺陷则可能威胁整家公司。配置是一种让通用系统发挥更大作用、同时管理这些风险的方式。

2014 年，我和同事介绍了 ocaml_plugin，一个让动态加载 OCaml 代码更容易的库。我们可以将代码插入系统，以比以往配置架构更灵活的方式改变其行为。我们对它很有信心，于是在新的邮件系统实现中使用了它。

第一次在生产环境中简单使用插件，结果却是一场灾难。我想解释我们遇到了什么问题、为什么会选择插件，以及最终采用了哪些配置方法。

配置让我们不必每次重新编译、打包和部署应用，就能改变系统行为。它把提供给操作人员的决策与核心功能分开，也能为原作者没有预见到的情况提供应急手段。

以邮件服务器为例：它接受连接、接收消息、处理消息——例如添加邮件头或删除带病毒的附件——然后投递或转发。一个可能的设计是完全没有独立配置：直接修改应用，再重新构建和部署。

零配置并不荒唐。如果合理的默认值和方便的部署能满足需求，就可以避开这里讨论的许多问题。邮件系统通常需要在运行时做修改，但引入独立配置之前，值得先问一句：真的需要吗？

当我们把更多决策从应用核心移入配置，系统可能变得更灵活。走到极端，配置会处理几乎所有事情。无论边界画在哪里，这些选择都必须存在应用能读取的地方，例如文件或数据库。

常见的起点是纯数据：命令行参数、环境变量、键值文件，或者 YAML、JSON 和 S 表达式等格式。一个小型扁平文件很容易理解：如果它写着邮件服务器监听 25 端口，就没有隐藏逻辑需要解读。

简单数据也相对容易做版本管理。升级程序可以读取旧格式，并生成新版本应用所需的内部表示。缺点是表达能力有限：配置越来越复杂时，内容可能变得冗长、重复。

在类似 JSON 的邮件配置里，我们可以列出端口、日志目录和级别，再按发件人域名指定下一跳服务器及重试间隔。增加另一个域名时，可能需要重复端口和重试计划。我们可以把重复值提取为默认值，但有些字段有多种常见情况，找不到一个显然合适的默认值。

接下来很容易想到加入宏或变量。这能减少重复，却也开始形成一门临时拼凑的语言。另一种办法是有意识地设计领域专用语言，从一开始就选择结构和功能，而不是不断累加特殊情况。

DSL 让设计者掌握控制权，表达能力可以非常强。但语言设计耗时，即使对熟练的设计者来说也很困难。解析器或解释器也可能有缺陷，尤其在生产事故中，很难分辨问题来自语言还是应用。

即使借鉴了现有语言的特性，它的语义对其他人仍可能陌生。语法高亮、导航、补全和测试等工具需要开发或适配。有经验的邮件运维人员也必须学习这门新语言；凌晨两点出了问题，作者可能是唯一能接电话的人。

举个具体例子：Exim 的基础配置可以把邮件投递到以地址本地部分命名的文件，检查用户列表，并拒收未知用户的邮件。加入类似 Gmail 的加号地址后，收件人可以在地址中添加后缀，同时保留原来的投递目标。

即使这个功能并不复杂，如果允许每个用户自行启用，Exim 配置也会复杂不少。里面有嵌套花括号、特殊的后缀模式，以及引用和检查变量时的不同规则；顺序和作用域也很重要。示例或许能运行，但要写对需要花费真正的精力。

我们已经有表达复杂行为的工具：编程语言，以及熟悉的库和工作流程。在 OCaml 中，可以用发件人、收件人和正文对消息建模，再定义一个处理函数，返回已投递、带目标地址的转发，或者带错误信息的拒收。

要实现加号地址，处理函数可以按加号拆分地址的本地部分，检查用户偏好，然后拒收或投递。熟悉这门语言的人看到的是普通代码，而不是另一套 DSL 专属规则。许多语言都支持动态加载；ocaml_plugin 让它在 OCaml 中更方便。

起初，用 OCaml 取代较大的配置让内容更简洁易读。随后人们开始充分使用获得的能力：插件越来越多，问题也随之出现。代码几乎什么都能做，而配置生产服务的插件会在服务进程内运行，使用服务的用户身份和机器。

我们部署了一些系统：用户自行编写插件，应用开发者则独立开发核心程序。起初一切正常，直到我们需要修改并重新部署核心应用。我们对版本管理考虑不足：插件必须能针对特定应用版本链接的库进行编译。

如果库接口改变，而插件没有同步更新，它在运行时可能无法编译。我们确实因此放弃并重新启动过一些应用。独立的插件文件还需要考虑存放在哪里、如何部署和追踪，以及如何随应用一起更新。

令人意外的是，工具体验也很差。正常代码库之外的独立插件不会自动告诉编辑器依赖在哪里，因此跳转到定义等功能可能失效。把配置代码和其他代码区别对待，会破坏工具原有的假设。

当配置从 12、13 行的例子增长到 4,000 行 OCaml 时，这个问题更加突出——我们的实际邮件服务器配置就有这么长。到了这个规模，糟糕的开发流程已经不是小麻烦。

很多情况下，我们把边界移了回去：将插件与应用打包并一起部署，尽管仍通过 ocaml_plugin 加载。我们保留了核心与可配置行为之间清晰的分离，以及运行时的应急手段，但失去了原本希望获得的大部分独立配置优势。

我们走了两条大致不同的路。对一些应用，我们认定独立插件的灵活性并非必要，于是随应用一起交付插件。另一些地方，我们投入工具来编辑、做版本控制，以及变基和合并分散的插件修改，实际上重新构建了普通开发环境的一部分。

代码有明显优势：表达能力强，可以通过熟悉的抽象扩展，并有成熟工具。它还自带代码审查、测试和重构的文化。这些实践有助于质量和正确性，但人们不会自然而然地把它们用于配置文件。

一种替代方案是生成配置：编写代码产出有限的静态配置，再由应用读取这些数据。这样既能在编写配置时利用代码的表达能力，又能在加载前直观检查结果。

生成方案要求配置能以有限形式写下来；运行中的函数不能直接序列化成普通数据。磁盘格式仍需要版本管理，但升级数据格式比维持动态加载代码与应用全部依赖之间的兼容性要简单。

已经使用手写数据的系统可以改用生成器，而不一定需要修改应用：生成器输出相同的格式即可。这种方法也适用于第三方系统，因为生成器可以用任何语言编写，只要输出目标应用要求的格式。

在 Jane Street，一种选择是使用固定编译器和库版本的 OCaml 脚本；另一种是使用带代码审查、构建守护进程和测试的代码仓库。把生成的配置也提交进去，可以方便地检查变更，并在不重新运行生成器的情况下回滚。

我们的监控配置描述主机、服务、检查命令和计划。由于加载前就能看到生成的文件，操作人员可以检查实际设置。我们还可以生成包含解析后主机和检查项的 CSV，比较版本，准确看到哪些检查消失了，又增加了哪些主机和检查。

另一条路是直接解决插件问题。我们需要处理版本兼容、有缺陷的插件或顶层异常导致应用不稳定的风险、不一致的部署和文件管理，以及工具体验差等问题。Jane Street 为此构建了一个叫 plugd 的系统。

Plugd 将配置集中存放在仓库中，像应用代码一样管理。它只提供经过审查、编译和测试的版本，并让应用不必依赖插件文件的位置。它还提供在不同版本之间迁移补丁的工作流程，让旧版应用使用的插件也能保持更新。

这套基础设施花了不少功夫，但插件提供了配置生成无法提供的能力：运行时动态性。函数本身就可以是配置，因此行为不必受限于有限的静态文件。

决策树的第一步是问：是否需要运行时的计算灵活性？如果不需要，配置生成是很好的选择。如果需要，再问插件编写者是否必须与应用开发者解耦；如果不必，就把插件和应用一起打包部署。

如果独立插件不可或缺，而且稳定性很重要，就应该采用规范的版本管理和基础设施，而不是简单地使用插件。还要重新考虑是否真的需要插件：许多情况下，只要把应用组织好，就能实现核心与可配置功能之间吸引人的分离。

有人问 plugd 自身是如何配置的。我认为它更接近零配置：它有合理的默认值，并与代码审查系统和构建守护进程紧密集成，可以从中获得大量所需信息。

一位观众问到开发团队之外的研究人员和运维人员。编写插件的人必须懂 OCaml。虽然 Jane Street 的很多非工程师也能读写代码，但有时我们会刻意保留更简单的格式，让人不必学习编程语言就能打开和修改。

两种方法也可以结合：插件提供运行时动态能力，同时在插件内部定义一种更简单的配置格式。另一些情况下，交易员自己编写插件，熟悉应用核心的人再审查，帮助确保代码安全合理。

关于版本管理，有人问问题是否只是缺少版本控制。版本控制确实重要，配置文件默认也更容易漏掉版本控制；但更棘手的问题是插件与应用运行时可用的精确库版本之间的兼容性。

OCaml 插件会把编译器和依赖打包进应用。运行时，应用展开这些内容，针对这些依赖编译插件，然后动态加载结果。因此，如果插件依据另一个版本的库编写，就可能在应用加载时编译失败。

另一种做法是把应用作为库提供，让用户在其上构建一个小程序。我们广泛使用类似模式：代码库由一组库组成，其中一些提供启动已配置应用的函数。配置和使用库之间的界限并不总是十分清楚。

什么时候应该选择这种方式？答案部分取决于哪些功能已经打包，哪些留给用户。一位观众补充说，如果程序执行时必须改变行为，加载新插件就很重要；如果一切都在运行前设置好，差异可能主要体现在工具上。

有人问到沙箱隔离。我介绍了一些库，它们启动工作进程来构建插件，使失败的工作进程不会直接影响主进程。这需要大量配套代码，尚未成为我们的主要用法，但仍是一种选择。

所谓“好的”插件，是通过整个流程的插件：代码审查、编译和测试。构建守护进程为每个发布版本运行相关测试，plugd 在向应用提供插件之前，也会独立构建和测试插件。

观众问到构建和维护 plugd 需要多少人。演讲者估计，大部分工作约由一人完成，维护只需一部分人力；不过算上所有参与者，总开发投入仍然可观。

如果负责人不在怎么办？这是更普遍的运维问题。其他人对生产运行有足够了解，可以应对问题；代码审查也能让更多人了解变更。我们鼓励写文档，但实际情况参差不齐；对特别重要的系统，我们会确保几个人持续了解日常运行。

最后，有人问插件功能是否会逐渐迁入应用核心。我预计会发生这种情况，但一时想不起具体例子。