从 90 多个微服务退回模块化单体：鹿特丹港的一次反向迁移

鹿特丹港的案例值得读：5 个团队维护 90 多个微服务，后来基于 DDD 与事件风暴，迁移到模块化单体架构，目的是驯服微服务过载。

过载是怎么发生的

微服务的好处写在教科书里：独立部署、技术异构、故障隔离。代价写在运维账单里：90 个服务的部署流水线、监控、日志、链路追踪、配置管理，乘起来是天文数字。

团队规模没跟上服务数量，就会出现「5 个团队管 90 个服务」，平均每个团队 18 个服务。每次跨服务改动要协调多个团队，发布变成排队。

模块化单体是什么

一个部署单元，内部按业务边界切成模块，模块之间通过明确接口通信，不共享数据库表。它保留了微服务的边界清晰，去掉了分布式带来的运维成本。

关键在「不共享表」这一条。共享表是单体腐化的起点，边界一破，模块化就是形式。

DDD 与事件风暴的作用

不是为了画图，是为了把边界找对。事件风暴把业务流程拆成领域事件，事件之间的归属关系自然划分出模块。这个过程比拍脑袋切分靠谱得多。

什么条件下该反向迁移

一，团队规模小于服务数量的十分之一；二，跨服务调用占请求量的大头；三，发布频率被协调成本压住。

要注意

模块化单体对代码纪律要求更高。没有编译期强制边界，只能靠架构测试（比如依赖方向检查）来守。守不住，半年就退化成大泥球。

结论

架构选型跟着团队规模走，别跟着技术潮流走。服务数量超过团队能维护的极限，就是该收的时候。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

5 个团队管 90 多个服务，平均每人管一堆，发布变成排队。架构选型应该跟团队规模走，服务数量超过能维护的极限就该收，别跟着潮流走。

五个团队管九十多个服务，这个比例必然出事。服务数量的上限应该跟团队数走，一个团队撑死维护七八个。模块化单体加 DDD 边界，本质是把分布式复杂度换回编译期约束，代价是不能单独扩缩容，多数业务量根本用不到那点弹性。