微服务不是银弹：什么时候该拆、什么时候别拆

一、微服务到底解决了什么

微服务的核心卖点就三个：

• 独立部署：一个服务改了，不用全量发版，影响面小。
• 独立扩容：热点服务单独加机器，不用整系统跟着扩容。
• 技术异构：不同服务可以用不同语言、不同存储，各取所需。

听着很香，但每一条都附带代价。

二、代价很多人不愿提

最坑的一种结局叫**“分布式单体”**：代码拆成一堆服务，但彼此强耦合、一改联动八个，部署反而比单体还麻烦。这比不拆还惨。

三、什么时候"该拆"

满足下面大部分条件，再考虑拆：

• 团队已经有规模：不止一两个人在改，多个小组要并行开发，单体仓库开始频繁冲突。
• 确实有局部热点：某个模块 CPU/内存占用远高于其他，需要单独扩容（比如秒杀、推送）。
• 迭代节奏差异大：核心交易要稳、活动页要快，拆开能各自发版互不影响。
• 基建已经就位：有容器、有服务网格/注册中心、有统一日志监控。没这些就拆，是找死。

一句话：拆的前提是"组织和基建先到位"，不是"代码先到位"。

四、什么时候"先别拆"

这些情况，老老实实写单体（或者模块化单体）：

• 人和代码都还少：早期项目，需求天天变，单体改起来最快。
• 没有专职运维/平台：服务治理全靠人肉，拆了没人管。
• 模块间耦合极高：业务上本就强相关（比如订单和库存），硬拆只会增加分布式事务的麻烦。
• 只是为了"显得先进"：跟风上微服务，没有真实痛点，纯属自找麻烦。

我的建议：早期用模块化单体——代码在一个仓库里，但按业务边界划清模块、禁止跨模块乱调用。等哪天某个模块真的要独立部署/扩容了，再把它抽成服务，成本最低。

五、如果真要拆，从哪下刀

真到要拆的时候，别按"技术层"拆（用户服务、订单服务、支付服务这种按业务域拆是对的；按"controller 层/service 层"拆是错的）。几个原则：

• 按业务域拆，不是按技术层拆。
• 先理顺接口契约，服务间用清晰 API 通信，别共享数据库。
• 数据库跟着服务走，能拆库就拆库，共享库是耦合源头。
• 先做可观测，链路追踪、集中日志没上之前别大规模拆。

六、小结

微服务解决的是组织和规模问题，不是"让代码更好看"的问题。小团队、早期项目，单体（尤其模块化单体）往往是最优解；等人多了、热点明显了、基建齐了，再顺着业务域自然拆。别被"微服务=先进"的叙事带跑——合适的架构，是匹配你当前阶段的架构。