微服务的迷思与单体的平庸
过去十年，微服务几乎成了“先进架构”的代名词。Kubernetes、Service Mesh、分布式追踪……一套华丽的工具链掩盖了一个朴素的事实：绝大多数团队根本不具备微服务所需的基础设施能力和组织成熟度。与此同时，传统单体被贴上“技术债”、“难以扩展”的标签，仿佛只要拆分成微服务，所有问题就会自动消失。然而，现实是残酷的——根据多个行业报告，超过70%的微服务改造项目不仅没有提升研发效率，反而让交付速度变慢、故障率上升。我们陷入了非黑即白的二元对立：要么是巨石，要么是微粒。却忽略了一个长期存在、但从未被正名的中间态：模块化单体。它既保留单体的简单性，又借鉴微服务的边界意识，才是大多数团队真正需要的架构形态。
单体不是原罪，无序才是
很多人痛恨单体，其实是痛恨那种没有任何边界、任何模块都可以随意修改彼此数据的意大利面式代码。这种“混沌单体”才是万恶之源，与架构形态无关——即使拆成微服务，如果团队没有纪律，也会形成“分布式大泥球”。单体架构的真正优势在于：本地调试简单、事务一致性天然成立、部署无需编排、链路追踪无需跨服务。这些优势在业务复杂度和团队规模未达到临界点之前，是巨大的效率杠杆。而我们常见的问题是，团队在30人以下时就去追逐微服务，结果每个服务只有几百行代码，却要维护配置中心、网关、监控和CI流水线，成本远大于收益。单体本身没有罪，罪在无序的依赖关系和缺失的模块边界。如果我们能通过强制的模块封装、清晰的应用层划分和依赖规则检查，让单体保持整洁，它就能完美应对几年内的业务增长。
模块化单体：第三种路线的具体实践与对比
模块化单体的核心思想是：在一个部署单元内，通过代码级别的模块边界模拟服务的独立性。每个模块拥有自己的数据表（或Schema）、自己的领域逻辑和对外接口，模块之间只能通过公开的API（例如Java中的Module或Package）进行调用，禁止跨模块访问Repository或直接操作数据库。与微服务相比，模块化单体省去了网络通信的序列化和容错处理，保留了方法级调用的性能；与混沌单体相比，它强制了依赖方向，让架构清晰可见。当未来某个模块确实需要独立扩展（比如遭遇CPU密集性负载）时，可以将该模块无缝抽取为独立服务——因为边界已经存在，连接单元不再是神秘的内部实现，而是事先定义好的API契约。这种演进路径远比“从混沌单体直接拆微服务”要平滑得多。我并非完全否定微服务——在超大团队（多个独立业务线并行）、超大规模系统（日请求量亿级）或者特定弹性场景下，微服务确实有优势。但大多数互联网产品早期，业务每天都在变，模块化单体可以让你以最小成本支持业务探索，同时保留未来拆分的能力。
决策框架：不要被流行绑架，用事实选择架构
架构决策不应是审美或简历驱动，而应由系统属性、组织形态和市场阶段共同决定。我提出一个简单的三层判断：第一，看团队规模——少于10人，坚决使用模块化单体；10-50人，如果业务域清晰且协作边界明确，仍可保持模块化单体，但需要引入严格的上层治理；超过50人或者存在独立的跨地域团队，才考虑微服务。第二，看业务耦合度——如果核心业务是强一致性的交易场景（如库存扣减、账户余额），微服务会带来分布式事务的灾难，模块化单体是唯一理性选择；只有对一致性要求不高、天然支持最终一致性的场景（如内容流、评论系统）才适合服务化拆分。第三，看变更频率——如果产品还在快速迭代探索期，Monolith优先；如果业务已稳定且某模块需要独立扩容或独立创新，再考虑拆分。技术本质上是经济的载体，每次架构选择都应该问：它是否降低了试错成本？是否提升了单位人力的价值产出？盲目追逐微服务，本质上是把“未来的系统压力”提前透支为“当下的团队协作成本”。
结语：架构的尽头是克制
我们应当对“微服务”和“单体”这两个词都保持警惕——它们只是工具，不是信仰。模块化单体不是对落后的妥协，而是一种在复杂性和简单性之间刻意寻找平衡的成熟认知。它继承了单体几乎所有的优点，同时通过纪律和工程规范，逐步逼近微服务的可演进性。真正的架构师不是用炫目的技术堆砌来证明自己的价值，而是能够识别出在当前约束下，哪种形态能带来最长期的正收益。当你下次准备发起微服务改造时，不妨先问自己：是否已经尝试过模块化单体？如果还没有，请先给这个“被遗忘的第三种选择”一次机会。也许你会发现，你需要的不是更多服务，而是更清晰的边界。