同事还在争论微服务拆不拆，我已经把单体跑成了利器

团队周会上，关于微服务拆分的争论又一次陷入僵局。正方搬出弹性伸缩和故障隔离，反方则列举分布式事务的泥潭和运维成本的黑洞。两拨人引经据典，从康威定律聊到领域驱动设计，会议纪要攒了十几页，代码仓库里的服务数量却一个没少——因为谁也不敢拍板。

而隔壁工位的老张，上个月刚把日活三十万的电商后台从微服务集群迁回单体。没有轰轰烈烈的重构宣言，他只是把四十多个 Spring Cloud 服务按业务边界重新打包成一个模块化单体，用 Gradle 多项目组织代码，内部通过清晰接口调用，对外仍然暴露 REST API。迁移完成后，服务器成本降了六成，接口平均延迟从 180ms 降到 45ms，发布流程从跨团队协调变成一条流水线十分钟搞定。老张端着保温杯说：“你们继续吵，我先跑为敬。”

这不是孤例。过去两年，从 Shopify 到 Stack Overflow，从亚马逊 Prime Video 到 Segment，一系列技术团队公开分享了从微服务回归单体的实践。这些案例并非否定微服务的价值，而是揭示了一个被忽视的真相：架构选择的本质不是技术先进性竞赛，而是对团队规模和业务阶段的匹配。当组织只有十几个人、业务边界尚未稳定时，强行拆分会把开发效率拖入分布式系统的复杂度深渊。

微服务的核心收益——独立部署、技术异构、团队自治——都建立在“组织规模足够大”的前提上。康威定律说系统架构会映射组织沟通结构，反过来也成立：如果组织本身只有两个 pizza 团队，却硬要拆出二十个服务，每个服务对应一个“虚拟团队”，那么跨服务协调成本会指数级上升。一次订单状态变更需要修改订单、库存、支付、通知四个服务，每个服务都要走一遍代码评审、测试、发布流程，原本半天的活拖成一周。更不用说分布式事务、链路追踪、服务发现这些基础设施的维护成本，对于没有专职中间件团队的公司而言，就是无底洞。

模块化单体恰恰能提供另一种解法。它把业务边界约束在代码层面：用包结构或模块划分明确上下文，模块间通过接口通信，禁止跨模块直接访问数据库。这种约束在编译期就能发现违规调用，比微服务间的 HTTP 调用更早暴露设计问题。同时，单体应用天然具备事务一致性和本地调试便利性，开发者可以在 IDE 里一键启动完整环境，断点从 Controller 一路跟到 DAO，不需要在多个进程间跳来跳去。

当然，模块化单体不是银弹。它的挑战在于纪律性：随着时间推移，模块边界容易腐蚀，开发者可能为了图方便绕过接口直接调用内部实现。解决这个问题需要工具支撑——比如用 ArchUnit 编写架构测试，在 CI 流水线中强制检查依赖规则；或者用 Spring Modulith 这类框架，自动检测模块间的非法引用。这些手段把架构约束从口头约定变成可执行的检查，让单体不至于退化成大泥球。

另一个关键点是部署策略。模块化单体虽然打包成一个制品，但可以通过特性开关和模块化加载实现灰度发布。例如将新功能封装在独立模块中，通过配置中心控制是否启用，配合蓝绿部署降低上线风险。当某个模块确实需要独立伸缩时，再把它拆成独立服务——这种“按需拆分”的路径比一开始就全量微服务化更务实。亚马逊 Prime Video 团队在 2023 年的分享中提到，他们将视频监控服务从微服务改回单体后，成本降低 90%，正是因为该服务的调用链路高度内聚，拆分成多个 Lambda 函数反而增加了网络开销和状态管理复杂度。

那么，什么情况下应该坚持单体？我的判断标准有三条：第一，团队规模小于 30 人，且没有跨地域协作需求；第二，业务领域边界仍在快速变化，频繁重构是常态；第三，缺乏专职的 SRE 或平台工程团队来维护服务网格、可观测性等基础设施。满足这三条时，模块化单体是更理性的起点。反之，当组织扩张到多个业务线独立作战、需要技术栈异构或独立伸缩时，再考虑渐进式拆分。

回到标题的场景。同事争论的焦点往往是“微服务是否先进”，却忽略了“当前阶段是否合适”。架构决策的输入变量从来不是技术潮流，而是团队认知负荷、交付频率和运维能力。把单体跑成利器，意味着你深刻理解它的边界，并用工程手段弥补短板：用模块化约束边界，用自动化测试保障质量，用 CI/CD 流水线实现快速交付。当别人还在争论拆不拆时，你已经用单体验证了业务假设，积累了领域认知，等真正需要拆分时，也有清晰的边界作为依据。

技术选型没有胜负，只有匹配。与其在会议室里争论架构的主义，不如在代码库里解决业务的问题。毕竟，用户不会因为你的服务数量多而下单，但会因为你的系统响应慢而离开。