微服务的“皇帝新衣”：为什么我们其实更需要模块化单体？

一个反直觉的论断

微服务架构自提出以来，迅速成为互联网公司的“标准配置”。 技术大会上到处是新服务、新部署、新弹性的故事，仿佛不拆分微服务就是落伍。 但现实是，许多团队在经历了分布式系统带来的大量“惊喜”后，开始偷偷怀念曾经的单体应用。 我并非要全盘否定微服务，而是想指出一个被过度营销掩盖的事实：微服务真正的价值不在于技术，而在于组织边界的清晰化；而如果组织并没有准备好为每个边界付出成本，微服务反而是一种比模块化单体更昂贵、更脆弱的架构选择。

模块化单体：被忽略的黄金地带

我们不妨把架构看作一个连续谱系：一端是巨石单体（Monolith），另一端是极致微服务。 而夹在中间的模块化单体（Modular Monolith）往往被大多数团队忽略。 模块化单体依然是一个可独立部署的进程，但内部通过强模块边界和清晰接口进行划分。 它既保留了单体在调用、数据一致性、测试和运维上的简单性，又能让不同团队负责不同的模块，在代码层面实现“逻辑分离”。

相比之下，微服务将“分离”提升到了物理层面，每个服务独立进程、独立数据库、独立部署。 这种物理隔离带来的是高韧性和独立伸缩，但同时也带来了网络分区、分布式事务、跨服务调用链追踪、多副本一致性等复杂性。 模块化单体则将这些复杂性控制在进程内部，用接口和模块边界来模拟服务边界，在没有规模压力和独立弹性需求时，它是远比微服务高效的方案。 很多公司（如Amazon的Prime Video团队）甚至在反思后从部分微服务退回模块化单体，因为他们发现过度拆分导致了性能和质量问题。

微服务的隐形账单：分布式的代价，往往被低估

微服务的拥护者常强调“故障隔离”和“独立扩展”，但他们很少提及完整账单：每个服务都需要独立构建流水线、配置管理、日志收集、监控告警、服务发现、熔断限流等基础设施。 在一个中等规模系统中，若拆成20个服务，运维复杂度不是线性增长，而是指数级增长。 例如，一次简单的跨服务查询，需要经过5个服务，任何一个超时或失败都可能拖垮整个链路；而定位一个性能瓶颈，往往要追踪十几个服务节点的trace。 更关键的是数据一致性。

在单体架构中，一个事务可以轻松跨越多个表；在微服务中，每个服务拥有自己的数据库，跨服务一致性需要Saga、分布式事务补偿等机制， 而这些机制不仅难以正确实现，还会显著降低系统吞吐量。 我见过太多团队在微服务中拼命用“最终一致性”来掩盖业务上的强一致需求，结果是业务逻辑复杂度远超预期，Bug数量激增。 这种代价在系统规模未达到真正需要微服务的量级时，完全是得不偿失的。

全新观点：微服务应该由组织架构驱动，且需有“拆分负债务”意识

我提出的独立观点是：微服务不是技术选择，而是组织管理工具。 康威定律早已指出，系统架构等于组织的沟通结构。 如果你有一个高效、紧密协作的小型团队（比如不超过两个披萨团队），那么单体或模块化单体是最契合的架构。 只有当你拥有多个独立负责不同业务域的团队，且团队之间的沟通成本远高于服务之间的网络调用成本时，微服务才真正变得划算。

此外，我建议所有团队在拆分微服务之前，先问自己：是否具备应对分布式系统复杂性的工程能力？是否已经有明确的业务边界和领域模型？ 如果没有，那么应该从模块化单体起步，将其作为微服务的“预演”。 更务实的是，将微服务视为一种“有期限的技术负债务”来管理：每拆出一个服务，就必须为该服务建立自治的运维能力和数据所有权，否则就是为未来埋下炸弹。 换句话说，拆服务不是目的，拆团队才是目的；如果你没有团队可以拆，那就不要拆服务。

结语：技术选择是务实主义，而非赶时髦

微服务不是万能的银弹，也不是洪水猛兽。 它是一把需要匹配使用场景的刀：当你的组织规模和业务复杂度达到一定水平时，它可以帮助你隔离风险、独立伸缩、提升迭代速度；但如果你仅为追赶潮流而使用它，你得到的只会是分布式环境的噩梦。 我主张架构师和开发者摒弃“非此即彼”的二元思维，用模块化单体作为默认起点，在必要且条件成熟时再演进到微服务，同时保留“演进”的勇气和“回退”的能力。 毕竟，最好的架构是适合你团队和业务的架构，而不是写在PPT里最时髦的架构。