微服务并没有消失，只是褪去神话光环，从 “万能银弹” 回归成一种特定场景才适合的架构方案。前几年全网狂热，现在讨论变少，本质是行业走完了技术炒作周期，看清了它的代价与边界。

1. 理想很美好，现实 “微服务税” 很重

宣传里：独立部署、灵活扩容、团队解耦、迭代飞快。 实际落地会支付一笔巨大隐性成本，业内叫微服务税：

1. 运维复杂度爆炸要配套网关、注册中心、配置中心、熔断限流、全链路追踪、分布式日志、多套 CI/CD 流水线。原本维护 1 个应用，变成维护几十套服务实例。小团队人力直接被基础设施消耗，业务开发效率反而下降。 很多中小公司拆完之后变成分布式单体：业务改动依然要多个服务一起改、一起发布，拿到分布式全部麻烦，却得不到独立发布的好处。
2. 网络与故障更难处理单体是内存函数调用；微服务变成远程 RPC/HTTP，带来延迟、超时、重试、抖动。故障不再是简单宕机，而是链式雪崩：某一个服务变慢，拖垮整条调用链。排查故障需要跨几十份日志追踪链路，排障难度成倍上升。
3. 数据一致性大坑单体用本地事务轻松搞定的业务（下单、扣库存、扣余额），微服务变成分布式事务。TCC、Saga 等方案都要大量额外开发，性能损耗大，很难做到完美一致性，业务要大量处理补偿、异常兜底逻辑。
4. 硬件与人力成本飙升同等业务下，微服务资源开销往往是单体 3‑6 倍，云账单大幅上涨，还需要专门平台运维团队支撑。很多企业复盘发现收益覆盖不住成本。

典型案例：亚马逊 Prime Video 把一部分微服务合并回单体，成本直接下降 90%，响应速度提升十多倍。

2. 过去很多项目属于盲目跟风

早年大厂分享 Netflix、亚马逊微服务成功案例，很多团队无视自身规模直接照搬。

• 微服务真正收益条件：业务体量巨大、团队很多（几十上百人）、不同业务迭代节奏差异很大。
• 十几个人甚至几个人小团队，业务边界高度耦合，强行拆分只会自找麻烦，交付速度变慢、bug 变多。

行业现在达成共识：

小团队优先模块化单体，代码内部分模块，但一套部署；业务真正长大之后，再逐步向外拆出服务，而不是项目一开始就全套微服务上阵。

3. 舆论热度转移，技术本身还在大规模使用

你感觉 “不火”，更多是媒体、公众号不再疯狂炒作，但大型互联网、金融、电信核心系统依然大量跑微服务。只是发生几件变化：

1. 不再当成新概念吹：已经是成熟常规技术，不再是流量话题；
2. 架构思潮转向务实：“适合优先” 代替 “越分布式越高级”，模块化单体、粗粒度服务重新被重视；调研显示大量企业把过度细碎的小服务合并成更大粒度单元；
3. 能力下沉到云原生底座：服务治理、观测能力交给 K8s、服务网格、云厂商平台，业务开发不再天天讨论 “要不要做微服务”，而是直接使用底层能力；
4. 新热点抢占注意力：AI 应用、Agent、Serverless、低代码等新话题占据技术社区流量。

4. 总结一句话

不是微服务不行了，是大家终于明白：它不是所有项目的标准答案。

• ✅适合：业务规模大、多团队并行开发、不同模块扩缩容需求不一样；
• ❌不适合：小团队、业务简单、早期创业项目，过早拆分得不偿失。

架构趋势是按需演进：起步模块化单体，等业务规模、团队规模到位，再拆分微服务，而不是上来就追求最复杂架构。