为什么模块化单体正在回归？

微服务曾经是一种信仰。

2015 到 2020 年间，几乎所有技术大会都在讲 Netflix、Amazon、Google 的微服务故事。结论是：大公司用了，我们也应该用。于是无数团队把系统拆成十几个、几十个服务，仿佛服务数量本身就是工程成熟度的指标。

2026 年，钟摆正在回摆。不是回到混乱的大泥球，而是回到一种更克制的中间态：模块化单体。

发生了什么？

微服务被过度推销了。

Netflix、Amazon 采用微服务，是为了解决数百个工程团队、数亿用户带来的问题。这些问题对于一家 20 人的初创公司来说并不存在。但很多人忽略了这个前提，直接复制了答案。

结果是可预测的：

服务发现、分布式追踪、网络可靠性、数据一致性、部署编排——基础设施工作吞噬了大量本应用于产品的工程能力。
一个原本简单的功能，现在要跨多个服务协调部署。
调试生产问题意味着追踪几十个服务各自的日志和监控。

到了 2023 年前后，一些公司开始公开往回走。Amazon Prime Video 团队发布案例：将微服务整合为单体后，**成本降低 90%**。Shopify 则一直坚持自己的模块化单体路线，支撑数百万商家和每年数千亿美元的交易。

CNCF 2025 年调查显示，约 42% 最初采用微服务的组织已将至少部分服务重新整合为更大的部署单元。

模块化单体到底是什么？

模块化单体不是”不设计的单体”。它是一种刻意设计的架构：

单个可部署单元，内部由严格边界分隔的模块组成。

关键实践包括：

模块边界由代码强制执行：利用语言级别的访问控制，防止模块互相侵入内部实现。
每个模块暴露定义良好的 API：跨模块访问必须通过公开接口，而不是直接读数据库。
逻辑上分离数据所有权：每个模块拥有自己的表或 schema，即使物理上共享一个数据库。
在模块边界写集成测试：提前发现边界违规，文档化模块间契约。
独立监控每个模块：性能基线已经存在，未来需要拆分时，知道从哪里下手。

这样，你获得了微服务的大部分组织好处——清晰的边界、明确的接口、独立开发——但没有分布式系统的运维代价。

微服务什么时候仍然有用？

微服务不是错误，它只是被滥用了。它在三种场景下仍然是正确答案：

1. 真正需要独立缩放

如果系统的某一部分处理其他部分 100 倍的流量，并且资源画像完全不同，拆分是合理的。但”这部分流量更大”通常不足以成为理由——水平扩展整个单体往往就够了。

2. 独立团队需要独立部署

当组织规模大到多个团队在同一仓库里互相踩脚——合并冲突、部署协调、责任推诿——此时按团队边界拆分，是康威定律的合理应用。阈值通常在 20 到 50 名工程师之间。

3. 真正的技术异构需求

如果某个组件确实需要不同的语言、运行时或数据库，服务边界提供了选择最佳工具的灵活性。但这种需求比想象中稀少。

为什么是现在回归？

几个长期力量同时起作用：

1. 云成本压力

过去几年，企业开始认真审视云账单。运行几十个小服务、每个服务都有自己的负载均衡、日志、监控和 CI 流水线，成本并不低。合并后，很多固定开销消失了。

2. 微服务运维疲劳

团队花了太多时间在”让系统跑起来”，而不是”让产品更好”。分布式系统的复杂度不会消失，只会被转移。当转移成本超过收益时，回调就开始。

3. AI 让模块边界更容易维护

这是一个被低估的因素。AI 生成代码时，如果模块边界清晰、规则明确，它更不容易越界。反过来，如果团队内部有 lint 规则或路径限制，AI 可以更快地学习和遵循。维护模块化单体的”纪律成本”在下降。

4. 行业终于承认：分布式系统很难

这不是新发现，但经历了十年的实践后，更多人愿意公开承认：分布式的复杂性不是免费的。对于大多数团队，它是一笔不必要的债。

这意味着什么？

模块化单体的回归，本质上是一次**从”追随最佳实践”到”匹配自身约束”**的觉醒。

架构选择不应该基于时尚，而应该基于：

团队规模和组织结构
业务域的成熟度
可承受的运维复杂度
真正的缩放需求

一个部署单元不是罪。罪的是把不相关的代码混在一起，却又假装没有边界。

未来会怎样？

模块化单体很可能成为未来五年多数中型团队的默认起点。

它的真正价值不是”避免微服务”，而是保留选择权：

当你真正需要拆分时，模块边界就是天然的服务边界。
在你不需要拆分时，你避免了分布式系统的过早负担。

这种”可演进的架构”比”一开始就正确”更现实，也更符合大多数业务的实际生命周期。

给团队的一个实用问题

在决定微服务之前，先回答：

我们到底是在解决一个组织规模问题，还是在追逐一个技术理想？

如果是前者，微服务可能是合理的。如果是后者，模块化单体值得认真考虑。

参考与延伸阅读

本文更新了 /predictions 中关于模块化单体的预测判断。