微服务拆分的时机与陷阱：什么时候该拆，什么时候别拆
去年，一个创业公司的技术负责人请我吃饭，满脸写着焦虑：“我们准备把单体应用拆成微服务，老板觉得这样才‘先进’，但我总感觉哪里不对。”
我问他：“你们现在多少人？”
“后端六个。”
“线上有多少用户？”
“两万。”
“多久发一次版？”
“两周一次，还算稳定。”
我放下筷子说：“你们现在拆微服务，大概率是给自己挖坑。”
他愣住了：“为什么？不是都说微服务是趋势吗？”
这是很多人对微服务的误解：以为拆了就是先进，不拆就是落后。但现实往往相反——拆错了，比不拆更痛苦。
01 微服务不是银弹，是手术刀
先讲清楚一件事：微服务本身不是目的，解决单体应用的问题才是目的。
单体应用有什么问题？部署慢、牵一发而动全身、团队协作困难、某个模块出问题整个系统都挂。如果你的单体没这些问题，拆它干嘛？
微服务是手术刀，不是锤子。锤子看什么都像钉子，手术刀只在需要的时候才动。
反常识观点：大部分团队，根本没到需要拆微服务的阶段。 10个人以下的团队，拆完以后，光运维就能把所有人累垮。
02 什么时候该拆？
三个信号，满足两个以上再考虑动手。
信号一：团队规模大了，代码冲突频繁
当你发现每次发版，git合并都要花半天时间，改一行代码能和三个人冲突，说明团队已经大到在一个代码库里施展不开了。这个时候拆，是为了解放团队。
信号二：部署频率被单体拖累
想发一个模块的更新，但因为其他模块也在改，得等所有人测完才能发。本来一天能发三次，现在一周发一次。这个时候拆，是为了让每个团队独立交付。
信号三：模块边界已经清晰
你闭着眼睛都能说出“订单模块”和“用户模块”之间怎么交互，依赖关系清清楚楚。这个时候拆，是水到渠成。
如果这三个信号一个都没有，拆了大概率是自找麻烦。
03 什么时候别拆？
比“什么时候该拆”更重要的，是“什么时候千万别拆”。
场景一：团队少于10人
微服务最大的成本不是代码，是运维。每个服务要搭监控、搭日志、搭CI/CD、搭服务发现。10个人的团队，拆成5个微服务，运维工作量翻三倍，哪还有精力写业务？
场景二：业务还在快速试错期
如果你连产品方向都没确定，今天做这个明天改那个，拆出来的边界明天就变了。别拆，让单体替你扛着，等业务稳定了再说。
场景三：数据一致性要求极高
微服务最头疼的是分布式事务。如果业务需要强一致性（比如金融、账务），拆完以后要处理跨服务的最终一致性，复杂度直线上升。除非万不得已，别碰。
场景四：团队没做过微服务
新手上路，第一个项目就上微服务，大概率是给自己挖坑。最好先用单体跑通，再慢慢拆。拆错了可以合回去，但拆的时候手忙脚乱，业务可等不起。
04 拆分的代价，你算过吗？
很多人只看到微服务的好处，没算过要付出的代价。
代价一：网络延迟
原来一个函数调用，现在变成跨网络RPC。原来几十毫秒能搞定，现在可能几百毫秒。如果依赖链长了，延迟成倍增加。
代价二：分布式事务
原来数据库事务能搞定一切，现在得用Saga、TCC、最终一致性。代码量翻倍，调试难度翻倍，数据对不上账的时候恨不得把代码全删了。
代价三：运维复杂度
以前监控一个应用，现在监控十几个。日志散落在各处，查个问题要翻好几个服务。以前发一次版搞定，现在要协调多个服务按顺序发。
代价四：调试地狱
本地跑一个单体，断点一打就能调试。现在要本地起十几个服务，内存不够，环境配不全。线上出问题，得在调用链里追半天。
有家电商公司，拆了两年微服务，最后运维负责人跟我说：“以前单体的时候，我们三个人管系统；现在十几个人管几十个服务，问题没少，人多了三倍。”
05 边界怎么划？划错了比不拆还惨
如果你决定要拆，最核心的问题是：怎么划边界？
原则很简单：按业务能力划，不按技术层次划。
订单、用户、商品、库存，这是业务边界。
前端、后端、数据库，这是技术层次。按技术层次拆，等于没拆。
边界划错最典型的症状：一个需求改完，要同时改三四个服务。这说明你把本来该在一起的功能拆散了。这时候，不是微服务，是“微单体”。
一个真实案例：某公司把“订单”和“物流”拆成两个服务，结果每次发版，两个服务都得一起改、一起发。拆了等于没拆，反而多了网络调用和事务问题。后来又把两个服务合回去了。
拆分的目的是让变化隔离，不是让变化扩散。 如果拆完以后，改一个需求要动更多代码，说明划错了。
06 一个真实案例：拆了两年，还不如不拆
一个SaaS公司，两年前开始拆微服务。老板觉得“微服务是趋势”，技术负责人也想着“为以后规模扩张做准备”。
拆了两年，结果：
服务从1个变成18个
运维从2个人变成6个人
每次发版要协调5个服务，经常发到半夜
线上出问题，查日志要翻好几个系统，平均修复时间从20分钟变成2小时
老板问“什么时候能拆完”，没人敢回答
后来他们做了个决定：把几个经常一起变更的服务合并回去。合并完，服务数量减到8个，运维压力降了一半，发版效率反而提高了。
技术负责人后来跟我说：“拆微服务最怕的，不是拆得慢，是拆完了才发现，其实没必要拆。”
写在最后
微服务是个好东西，但它不是免费的午餐。拆之前，先问自己几个问题：
你们团队多大？10人以下，别拆。
业务稳定吗？还在试错期，别拆。
数据一致性要求高吗？很高，别拆。
有人做过微服务吗？没有，别拆。
微服务不是目标，解决业务问题才是。如果你的单体跑得好好的，别为了“先进”去拆它。拆错了，比不拆更痛苦。
那家拆了两年又合回去的公司，现在活得挺好。技术负责人说了一句话我记了很久：
“以前觉得不拆就是落后，现在觉得，合适才是先进。”
你的系统，现在合适吗？
