把微服务收回一个进程：Firebolt这次重构值得学什么

一家做分析数据库的公司，正在把原本独立运行的元数据、身份和垃圾回收等能力收回数据库程序内部。这个动作很容易被概括成“微服务退潮”，但这样读，会错过它真正有用的部分。

2026年5月，Firebolt作者在SAO Workshop论文中介绍了这次重构。原系统围绕多租户托管服务组织，新的方向更重视自托管、不同环境下的部署，以及修改和验证系统的便利性。约束变了，原先有价值的服务边界开始产生新的代价。

论文是设计者对自身系统的说明，并非独立的成本评测。它没有提供足以证明所有企业都应合并服务的对照数据。可以借鉴的是判断方法：那些边界今天还在解决什么问题，又让团队多承担了什么工作？

先看它收回了什么

按论文描述，旧架构中，租户的计算引擎相互隔离，元数据、身份、垃圾回收等主要服务则跨租户共享。作者指出，这种组织方式便于团队分工，但跨服务协调和向其他环境交付系统都需要额外投入。

新的方向把若干子系统合入核心数据库程序，仍使用PostgreSQL保存元数据，也仍依赖对象存储。这里的“单体”指的是软件组织与交付方式，不能顺手画成一台机器，更不能理解为数据库、存储、调度都消失了。

模块与进程原本就是两条边界。模块规定谁可以调用什么接口、哪些状态由谁维护；进程则带来独立启动、资源分配和故障处理的机会。模块可以在同一进程里保持清楚的接口，多个进程也可能因为共享表、循环调用和同时发版而紧密耦合。

可以把部署包想成工具箱。几个工具原来分别装箱，现在收进一个有分格的大箱子，运输和清点更方便；分格是否保留，工具会不会互相碰坏，仍是另一项设计。合并部署若同时放弃内部约束，得到的只是一个更难修改的整体。

图1｜装进同一工具箱，也可以保留内部分格。图像仅比喻部署与模块边界；实际系统仍有外部依赖，不表示硬件数量或性能变化。

少一道网络调用，真正省下的可能是另一笔账

合并可以减少部分远程调用的序列化、网络往返和跨服务错误处理，但这不是可以直接承诺的性能收益。如果原来的耗时主要来自磁盘扫描或外部数据访问，减少内部调用未必改变用户等待；同一进程新增的资源竞争，也可能抵消部分收益。

更值得检查的是系统被复制到另一个环境时，需要带走多少运行条件。

每一个独立服务，都可能附带自己的启动配置、连接凭证、版本兼容关系、监控和升级顺序。它们单看不难，组合以后却会增加交付时需要同时成立的条件。对于需要反复部署到不同客户环境的软件，这笔成本可能比一次请求节省多少微秒更重要。Firebolt的案例正是在部署约束变化后，重新评估了这种组织方式。

再看日常修改。假设一个业务字段要经过三个服务才能完成处理，而且每次修改都要求三方同时发布。这个假设中的服务数量没有带来独立演进，反而增加了协议变更和发布协调。把相关逻辑收拢，可能缩小一次变更跨越的范围。

但“经常一起改”也需要辨别原因。有时是领域边界划错了，有时只是接口长期没有兼容策略。后一种情况未必需要合并进程；先增加兼容窗口、改变发布顺序，可能就能解决主要问题。把所有协调成本都归咎于微服务，会跳过更小的修复机会。

因此，评估时应挑一条真实变更和一次真实环境交付，数清需要协作的服务、等待的步骤，以及故障时必须一起排查的依赖。服务总数本身很难回答这些问题。

合并以后，哪些故障会一起发生

进程边界也不是白送的复杂度。一个独立服务可以有自己的内存上限和重启周期；收进同一进程以后，内存泄漏、崩溃或长时间停顿可能影响原来不会同时受影响的模块。减少网络故障的同时，故障传播方式也变了。

模块接口能够约束代码依赖，却不能天然提供进程级资源隔离。若计算任务经常耗尽内存，而控制接口必须保持响应，单靠“代码已经模块化”不足以解释为什么二者可以安全合并。也可以把模块保留在同一代码库中，按运行角色部署成不同实例，继续维持必要的资源与故障边界。

还有租户维度。把共享服务改成随租户部署的组件，可能缩小一次故障影响的租户范围，却增加实例、升级和容量管理的数量；继续共享外部元数据存储，则仍保留共同依赖。判断隔离能力，需要看最终部署，不能从“单体”或“微服务”的名称推出。

图2｜不同边界解决不同问题。模块规则、进程隔离和租户部署要分别检查，任一项不能代替另外两项。

如果一个组件确实有不同的扩缩节奏、独立发布需求或强隔离要求，保留进程边界有可验证的理由。反过来，几个组件长期共同发布、负载变化一致，主要麻烦又来自环境交付与协调，就值得试验更紧凑的部署。

试点不必从全系统合并开始。选一组关系清楚的组件，保留接口与状态归属，比较变更周期、环境搭建、尾部延迟和故障恢复；同时测试其中一个模块资源耗尽时会影响谁。若迁移涉及元数据结构变化，还要先验证旧版本如何继续读取或回退，不能只保留一个旧安装包就算有退路。

Firebolt这次重构提供了一个重新提问的机会。下次架构评审，不妨拿出最难交付的一组服务，逐条写明每个进程边界带来的独立能力。能证明隔离和演进价值的边界保留；只能证明历史上分过团队的边界，才是值得重新讨论的对象。