微服务是近年来最火的后端架构概念，但并非所有团队都适合。这篇文章从实际案例出发，分析微服务的真正价值、隐藏成本，以及什么场景下才值得做微服务改造。

微服务不是银弹：那些年我们踩过的坑

2018年，某大厂轰轰烈烈搞微服务改造，200多人的团队拆分出80多个服务。三年后，这个团队悄悄把一半服务合并回了单体。

这不是个例。据我观察，至少有三成企业的微服务改造，最后变成了"微服务回滚"。

微服务是好东西，但它有一张隐藏的价目表。 看完这篇文章，你会知道：微服务到底解决什么问题、它会带来什么新问题、以及什么情况下值得拆、什么情况下宁可别拆。

为什么大家都在拆？

微服务为什么火？四个字：独立部署。

传统的单体应用，改一行代码要重新打包部署整个系统。一次部署，全员等待。微服务不一样——你只改用户服务？那就只部署用户服务，其他服务纹丝不动。

这听起来很美。但代价是什么呢？

服务治理的成本。

当你从3个服务变成30个服务，局面完全不同了：

每多一个组件，就多一个可能出故障的点。微服务架构的本质，是用运维复杂度换取部署灵活性。

微服务最坑的地方，不是上面那些组件，而是数据。

单体架构里，一次数据库事务解决所有问题。微服务架构里，一个业务操作可能涉及五六个服务，每个服务有自己的数据库。

用户下单，要扣库存服务、扣余额服务、创订单服务、开票服务。四个服务，四种状态，怎么保证一致性？

答案是：没法保证。至少没法像单体那样保证。

你只能选：

选最终一致性，就意味着你的系统要能容忍"中间状态"。订单创建了但库存还没扣，这段时间用户看到的是什么？如果用户取消订单，扣掉的款怎么退？

每一个"不一致窗口"，都是产品和运营要填的坑。

说了这么多微服务的坏话，不代表它一无是处。关键是看场景。

值得拆的情况：

团队规模大，超过20个工程师同时开发一个系统。单体应用的代码库，任何人改任何东西都可能影响到任何人，code review形同虚设。拆成服务后，团队自治，边界清晰。
技术栈需要异构。订单系统要Java的强类型安全，内容系统要Node.js的JSON处理能力，搜索服务要用Rust的性能——微服务让你各自选最适合的技术。
不同模块的访问量差异巨大。比如商品浏览是热点，库存扣减是冷门。你需要单独扩展热门服务，而不是连带着把整个系统扩容。

不值得拆的情况：

微服务是工具，不是信仰。

Netflix、Amazon这些公司把微服务玩得溜，是因为他们有成熟的DevOps团队、有完善的自动化基础设施、有多年积累的服务治理经验。他们拆服务的收益，远远大于治理的成本。

但如果你是一个几十人的团队，用着单体架构还能跑业务，先别急着拆。想清楚：

技术选型不是追风，是解题。 微服务解决的是分布式系统的部署和治理问题。如果你的问题不是这个，就别花这个成本。

当然，如果你已经踩过微服务的坑，欢迎来留言区吐槽。有些教训，文字不如经历来得深刻。