2001年的亚马逊还是一团代码巨石。一个功能上线要协调全公司，部署回滚能折腾到凌晨三点。工程师们受够了，于是贝佐斯下了道死命令：所有团队必须通过API通信，不遵守就滚蛋。

这场「 API强制令 」催生了微服务神话。Netflix、Uber纷纷跟进，拆服务成了技术正确的代名词。到2015年，一个典型的硅谷公司能有2000多个微服务，监控仪表盘比业务代码还厚。

然后事情开始荒诞起来。AWS CTO Werner Vogels去年在re:Invent上摊牌：「 我们有些团队花了18个月才把五个服务合成一个。 」当年教人拆服务的祖师爷，现在教人合回去。不是微服务错了，是很多人根本没搞懂自己业务的边界在哪就动了刀。

Serverless也没好到哪去。冷启动 latency 能吃掉你省下的所有运维成本，调试的时候日志散落在十几个云服务里，像在玩解谜游戏。2022年Stack Overflow调研显示，43%用了Serverless的团队考虑过迁回容器——不是因为技术差，是因为账单和排查时间不可预测。

Monolítico、微服务、Serverless，本质上是用不同姿势解决同一道题：多少人能同时碰代码而不互相踩脚。小公司学Netflix拆服务，就像穿43码鞋的人硬挤进37码——不是鞋的问题，是脚的大小搞错了。一位前Uber工程师在博客吐槽：他们最赚钱的业务线，核心交易引擎至今还是Ruby单体，因为重写风险比维护成本更高。

现在流行一种说法叫「 模块化单体 」——代码在一个仓库，但内部边界清晰。听起来像和稀泥？GitLab 2023年架构白皮书里写得很直白：他们的主代码库仍是单体，只是用组件约束强行隔离。没有运维凌晨被叫醒，也没有分布式事务的噩梦。架构师圈子里有个黑色幽默：微服务是技术债的延期付款，利息是on-call轮值。