先说结论
掘金今天有篇文章叫"微服务正在悄然消亡：这是一件美好的事"。
我同意。
不是微服务不好，是大多数团队根本不需要微服务。用了反而是在给自己挖坑。
我经历过两次微服务到回到单体的迁移，今天说说为什么。
先说微服务到底解决了什么问题
微服务的核心价值是独立部署和独立扩展。
当你有 50 个开发团队、日活千万级、不同模块的流量差异 10 倍以上时，微服务是合理的。每个团队独立部署自己的服务，互不干扰，按需扩容。
这个场景存在吗？存在。但全世界可能只有几百家公司真的需要。
大部分公司的实际情况是：
- 后端团队 3-10 个人
- 日活几千到几万
- 所有模块的流量差不多
- 数据库一个实例够用
这个体量用微服务，就像用卡车送外卖------不是送不了，是没必要。
微服务的真实代价
我之前的公司，3 个后端，拆了 12 个微服务。
听起来很"架构先进"，实际跑起来：
运维成本翻了 5 倍。
12 个服务意味着 12 套部署、12 套监控、12 套日志。原来一个 docker-compose up 就能跑的项目，变成了要维护 12 个 Dockerfile、12 套 CI/CD 配置。
3 个人的团队，每周花在运维上的时间从半天变成了两天。剩下一天半写业务代码，还要跨服务联调。
调试地狱。
一个用户请求要经过 4 个服务才能完成。出 bug 了，你要：
- 翻 4 个服务的日志
- 对齐时间戳
- 猜请求在哪一步出了问题
- 本地起 4 个服务复现
原来单体的时候，打个断点 5 分钟搞定的事，微服务下要花 2 小时。
数据一致性噩梦。
每个服务有自己的数据库。用户下单要同时写订单服务和库存服务。单体里一个事务搞定的事，微服务下要上分布式事务或者 Saga 模式。
分布式事务的复杂度，写过的人都知道。一个 Saga 有 6 个补偿步骤，任何一步失败都要回滚前面所有步骤。写完之后没人敢改，因为改了不知道哪里会炸。
回到单体不是倒退
第一次迁移回单体的时候，技术总监说了一句话我记到现在：
"我们花了一年拆微服务，又花了半年合回来。这一年半里，业务没进展，全在折腾架构了。"
合回来之后：
python
# 原来的微服务调用链
# user_service → order_service → inventory_service → payment_service
# 4次网络调用，4次序列化，3次重试逻辑
# 合回来之后
def create_order(user_id, items):
user = get_user(user_id) # 直接函数调用
order = create_order_record(user, items) # 同一个事务
update_inventory(items) # 同一个事务
process_payment(order) # 同一个事务
return order
# 0次网络调用，1个数据库事务，完事不是代码少了，是不需要的网络开销全部消失了。
一个请求从 4 次 RPC 变成 0 次 RPC，延迟从 200ms 降到 30ms。用户直接感知到"快了"。
什么时候真的需要微服务
说了这么多微服务的坏话，不是要全盘否定。
有几种场景，微服务确实是正确的选择：
- 团队规模超过 20 人------单体会变成合并冲突地狱
- 不同模块流量差异 10 倍以上------比如秒杀模块和后台管理
- 不同模块用不同技术栈------比如推荐用 Python、交易用 Java
- 有明确的安全隔离需求------支付模块必须独立部署
如果你的情况不在上面这几条里，老老实实用单体。
单体不丢人。用一个单体把业务跑起来，比用微服务把团队拖死强 10 倍。
我的两次迁移经历
第一次：被迫合并
3 个后端 12 个微服务，团队加班到崩盘，最后 CTO 拍板合并。花了 2 个月，把 12 个服务合成 3 个按业务域划分的服务（不是完全单体，是"大单体"------每个业务域一个服务）。
效果：运维成本降了 60%，开发效率提升明显，bug 数量下降------因为很多 bug 本来就是服务间通信导致的。
第二次：主动合并
换了家公司，入职发现又是 8 个微服务、4 个后端。这回我主动提了合并方案。
合回单体后，部署从 8 步变成 1 步，新人 onboarding 从 2 天变成 2 小时。
最明显的变化是：团队有时间写测试了。 以前光维护微服务基础设施就耗完了精力，合并之后省下来的时间用来补了测试覆盖率。
总结
微服务不是银弹，它是一种有明确适用场景的架构模式。
掘金那篇文章说"微服务正在悄然消亡"------我觉得不是消亡，是回归理性。
前几年微服务被吹过头了，什么体量的团队都在拆。现在大家发现拆了之后维护成本太高，开始合回来。这不是倒退，是纠错。
架构选择从来不是"先进 vs 落后"，是"合适 vs 不合适"。 3 个人的团队用单体不丢人，300 个人的团队用单体才需要考虑拆。
如果你现在正在纠结要不要拆微服务，问自己一个问题：
你的团队够大吗？你的流量够大吗？
两个都不是的话，别拆。把精力放在业务上。
数据出处：掘金首页 2026-08-17，"微服务正在悄然消亡"相关文章首页推荐。两次迁移经历来自个人实际工作经历。