这篇文章的核心观点很简单：微服务不是银弹，很多公司用它只是“转移复杂性”。
下面从来源、演化、成本三个角度展开。
微服务从哪来
大型互联网公司在特定阶段为了“控制复杂性”做了服务化拆分。
这在电商等高复杂业务上是合理的，但并不适用于所有团队。
管理复杂性的三件事
软件工程的主线一直是：
- 抽象
- 封装
- 复用
从函数、类、框架，到组件化与服务化，都是为了解决协作与演进问题。
从单体到服务化
单体变大后，往往会拆出独立系统（采购、库存、履约）。
服务化的好处：
- 团队边界清晰
- 依赖关系明确
- 业务责任可追溯
服务化的挑战
- 数据边界分裂，容易引入业务级不一致
- 版本前向兼容复杂
- 技术栈异构，重复实现成本高
这些问题可控，但需要投入工程治理。
微服务的过度拆分
当“服务”退化为“无业务语义的功能代码”，系统复杂度反而急剧上升：
- 职责归属不清
- 依赖网状增长
- 版本兼容成本爆炸
而维护成本往往比开发成本更高。
真实案例：缓存不一致
价格服务缓存 + 商品服务缓存，规则变更后需要多点失效，否则数据不一致。
本质问题：服务之间拥有状态，缓存层级叠加后，耦合度上升。
结论
微服务没有消除复杂性，只是把复杂性“切碎再分发”。如果没有强工程能力和清晰边界，复杂度会更大。
适用建议
- 小团队先单体，架构清晰再拆
- 拆分标准是业务边界，而不是技术偏好
- 服务数量越多，治理成本越高