微服务退潮：模块化单体回归，解耦是永恒的，物理拆分是可选的

越来越多团队从微服务回撤到模块化单体。这个转向不是技术倒退，是成本核算之后的结果。

微服务当年解决的是什么

核心是组织问题：多个团队并行开发同一个系统，代码库耦合导致发布互相阻塞。拆成服务，各自独立部署，发布节奏解耦。技术上的好处（独立扩缩容、技术栈自由）是附带收益。

现在为什么退

两个前提变了。一是团队规模。一个五到十人的团队，拆成八个服务，运维成本直接压过协作收益。二是基础设施成熟度。容器、服务网格、可观测性这套东西把微服务的运维门槛降下来了，但没降到零：链路追踪、分布式事务、跨服务数据一致性，仍然是持续的复杂度税。

三条判断标准

组织规模：能不能给每个服务配一个完整的所有权团队。做不到，拆了就是负担。

差异化扩展压力：有没有某个模块的负载特征与其余部分差异巨大，必须独立扩缩容。没有，就别拆。

工程能力：团队有没有能力处理分布式系统的一整套故障模式。没有，单体是更安全的选择。

模块化单体怎么做才不烂

关键在边界纪律，不是目录结构。模块之间只通过显式接口通信，不允许跨模块直接读表；每个模块拥有自己的数据，禁止跨模块 join；模块内部分层，模块之间单向依赖。

做到这三条，将来真要拆某个模块，切面是清晰的。做不到，所谓模块化只是一堆按文件夹分的意大利面。

一句话

解耦是永恒的，物理拆分是可选的。先解耦，再考虑拆不拆进程。

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

模块化单体回归不是技术倒退，是成本核算的结果。微服务当年解决的核心是组织问题，团队多了发布互相阻塞才拆；技术收益是附带的。判断标准就三条：能不能给每个服务配完整所有权团队、有没有差异化扩展压力、团队扛不扛得住分布式故障模式。解耦是永恒的，物理拆分是可选的。

团队规模那个前提才是关键。十个人八个服务，光把链路日志串起来就够一个人全职干。我们去年把六个服务并回两个模块化单体，发布次数没降，故障定位从四十分钟缩到五分钟。拆不拆看组织和运维能力，不看架构图好看。