拆掉微服务后，成本降了90%

上周二，一个做电商的朋友发来一段话：

「我们花了两年把单体拆成12个微服务。现在又想合回去。我都不敢跟老板说。」

隔了几分钟，他补了一句：「你说这是不是倒退？」

这不是倒退。2026年Q1，CNCF的报告显示42%曾采用微服务的组织已经在做同一件事——把服务合并成更大的部署单元。Amazon Prime Video把视频质量监控从微服务改回单体，成本直降90%。Segment、InVision、Istio相继宣布了类似的架构回归。Neal Ford和Sam Newman公开称2026年是「单体的文艺复兴」。

这不是技术退步，这是一次集体纠偏。而这次纠偏里藏着一个架构师真正值钱的能力：知道什么时候不该拆。

你拆的不是微服务，是分布式单体

先看一个典型场景。

一个团队花了9个月把订单系统拆成5个服务：用户服务、商品服务、订单服务、库存服务、支付服务。架构图画出来很漂亮，每个服务独立部署、独立扩容，技术栈还能各不相同。

上线后第一个月，问题开始冒头。

改一个下单逻辑，需要同时改订单服务和库存服务。两个服务一起发布。一起回滚。一起加班排查。一个Bug从前端进来，经过网关→用户服务→订单服务→库存服务→支付服务，你要跨5个服务、查10个日志文件、拼凑3条分布式追踪链路才能还原调用链。

在单体架构下，一个IDE断点就能定位的问题，现在变成了刑侦级别的排查工作。

这种架构有一个专门的名字：分布式单体。服务在进程上是分离的，业务逻辑上却紧密耦合。你没能享受到单体的简单性，却完整背负了分布式系统的全套运维成本——Service Mesh、多套CI/CD流水线、分布式事务协调机制，一个没少。

Marvin Minsky说过一句话：「如果你不知道一个系统是如何工作的，给它加更多层不会让你更接近答案。」

分布式单体就是这句话的工程验证。

微服务解决的是什么问题

回到第一性原理。微服务最初要解决的底层矛盾不是「代码太多了拆开好维护」，而是两个具体到骨头的问题：

第一个是独立部署。 当你的团队超过50人，30个人同时往一个代码仓库提交代码，每一次发布都是一场协调灾难。微服务让你可以把系统按团队边界切开，每个小团队对自己那部分负责到底，上线不用看别人脸色。

第二个是独立扩容。 当你的系统某些模块的流量是其他模块的100倍——比如秒杀场景下的下单模块——你需要单独给这个模块加机器。单体做不到。

反面就是：如果你的团队只有8个人，所有模块的流量都很均匀，没有独立部署的痛，也没有独立扩容的需求——你把系统拆成12个微服务，是在解决一个不存在的问题。

这叫决策错配。用微服务去解决单体架构的维护问题，就像用推土机去给花盆松土。工具没错，选错了场景。

成本账：那些没人算的数字

Amazon Prime Video的案例不是孤例。他们监控服务从无服务器+微服务的分布式架构改回单体后，基础设施成本从每月数万美元降到了几千美元。

通用规则其实很简单：一个部署单元就有至少一份基础成本。拆得越碎，份数越多。

一个原本在单台4核8G机器上跑的Spring Boot应用，拆成20个微服务后，每个服务启动一个JVM就是500MB内存打底。20个服务光JVM就吃掉10GB。再加上Service Mesh的Sidecar——每个Pod一个Envoy代理又是200MB——基础设施成本翻10倍不在话下。

这还没算人的成本。

每次服务间通信都是网络RPC：序列化→网络传输→反序列化。单体内部是内存调用，延迟纳秒级。微服务间是毫秒级，差了一千倍。一个下单流程串行经过8个微服务，几毫秒变成几十毫秒，用户体验肉眼可见。

那些你在架构评审会上拍板的拆分决定，最后都会变成每月的云账单和用户的等待时间。

模块化单体：第三条路

2026年，模块化单体重新回到舞台中央。

它的思路简单到让人不安：逻辑上严格隔离，物理上统一部署。模块间通过进程内调用通信，延迟纳秒级。但代码组织上按领域边界拆开，每个模块有自己的目录、自己的数据库Schema、自己的团队Owner。

这和当年「把什么都揉在一起」的单体不是一回事。

当年那个单体的问题是没有边界。任何模块可以调用任何模块的任何方法，三个月后依赖关系变成一团毛线球。而模块化单体的边界是编译期强制检查的——模块A不能直接引用模块B的内部类，只能通过模块B暴露的公开接口交互。违反了就编译不过。

正是这个「编译期强制」让模块化单体从「乱炖」变成了「有规矩的分区」。

什么时候选模块化单体？看三个指标：

团队规模。 10人以下团队，拆微服务不是提效，是给每个人额外加一套分布式系统的认知负担。

业务耦合度。 如果你的业务改一个功能必然联动三五个模块，这些模块就该住在一起。物理隔离解决不了逻辑耦合，只会让逻辑耦合的代价从编译错误变成线上故障。

独立扩容的真实需求。 不是「将来可能要」，是「现在已经在某个模块上看到资源瓶颈」。为尚未出现的需求做架构储备，和囤积用不上的东西没有区别。

什么时候该拆

当然不是所有场景都该合回去。

如果你的某个模块流量已经开始呈现10倍以上的尖峰，独立扩容就是刚需。如果你的团队规模超过了15人，代码合并冲突每周都在消耗半天以上的协调时间，独立部署就是刚需。

判断标准不是「这个服务是不是够小」，也不是「这个服务是不是只做一件事」。那些都是手段。真正该问的问题是：拆开之后，卡住团队的核心约束有没有被解决？

如果拆分不能让你上线更快、扩容更独立、排查更精准，这个拆分的唯一作用就是让架构图更好看。

而架构图的好看，不值一套Service Mesh的运维成本。

大多数架构师的前半段职业生涯在学「怎么拆」。后半段在学「什么时候不该拆」。

2026年的这场微服务回归，不是否定微服务。是把微服务从「默认选项」拉回它本来的位置——一个在特定约束下有效的工具，而不是一种信仰。