为什么团队正在回归模块化单体
微服务曾一度被视为金标准。而现在，许多团队正在回归模块化单体。
到 2026 年，趋势正在发生转变。团队已经厌倦了分布式系统的高昂成本。他们并不是要回到那种混乱、纠缠不清的单体架构，而是正在构建更整洁、模块化的版本。
为什么会发生这种情况？
微服务带来了隐藏成本：
- 当单个请求跨越五个服务和三个队列时，调试时间会长得多。
- 云账单不断上升，因为每个服务都需要自己的开销和资源。
- 小型团队难以管理数十个部署流水线和监控工具。
- 分布式数据库之间的数据一致性成了一场噩梦。
模块化单体让你兼得两者的优点。它拥有单一的代码库和单一的部署。然而，它使用了严格的内部边界。每个模块拥有自己的逻辑和数据。你既能获得微服务的组织结构，又无需承担巨大的运维开销。
使用此指南来选择你的架构：
- 团队规模少于 50 名工程师：使用模块化单体。
- 需要扩展特定部分（如支付）：使用模块化单体，但将该特定服务提取出来。
- 100 名以上工程师且有大量独立需求：使用微服务。
- 已经在用微服务且正在亏钱：使用绞杀者模式 (Strangler pattern) 进行整合。
现实中的公司已经在这样做。Shopify 使用模块化方法来管理数百万商家。Amazon Prime Video 将特定的工作负载从微服务移回单体，从而降低了 90% 的基础设施成本。
规则很简单：从模块化开始。只有当你的数据和流量需求迫使你这样做时，才提取服务。不要盲目追随热点，要根据你的需求来做。
通过以下问题检查你的系统：
- 你的云账单增长速度是否快于用户增长速度？
- 你花在调试服务上的时间是否比构建功能的时间还多？
- 你的团队是否少于 100 名工程师？
如果你的回答是“是”，那么模块化单体可能会为你节省时间和金钱。