微服务落地的一线踩坑实录

上周跟珠江路出来的老周喝酒，他拍着桌子骂了半小时微服务。

不是说微服务不好。是他被坑惨了。

一开始拆服务全是爽点

老周2019年在南京一家做生鲜电商的公司带技术团队，那时候还跑单体应用，所有代码塞在一个war包里，部署在河西的某IDC机房。每到618或者双十一，订单量一冲，整个系统卡得像蜗牛，改个库存计算的小bug，要全量停服半小时上线，回滚都怕牵一发动全身。

2021年行业里都在聊微服务，他们咬咬牙花了三个月，把原来的单体拆成了订单、库存、用户、营销、配送五个独立服务，每个服务单独部署，单独扩容。那时候真的爽。

改库存逻辑不用再碰订单的代码了，配送服务挂了也不会拖垮整个下单链路，上线不用全量停服，点一下发布按钮就搞定，团队那时候还觉得自己踩中了技术风口。

爽了半年，不对味了。

麻烦全是拆完之后冒出来的

第一个找上门的就是分布式事务的坑。之前单体里扣库存减优惠券，一个数据库事务就能搞定，现在两个服务跨网络调用，稍微抖一下，就出现库存扣了优惠券没核销的情况。老周说去年光用户白嫖满减券的损失，一个月就有十几万。

然后是雪崩的问题。之前方法调用直接拿返回值，现在跨服务走HTTP，一不小心没做超时控制，线程就全堵在调用的环节。去年双11凌晨，营销服务因为流量太大挂了，订单服务没做熔断，所有线程都卡在等营销服务的返回上，整个下单链路直接瘫痪，生鲜配送的页面白了四十分钟，客服电话被用户打爆，老周在写字楼里蹲到凌晨三点才把问题排查完。

还有运维的负担。之前单体就两台服务器，监控个CPU内存就能搞定，现在五个服务加配套的中间件，十几套环境，出了问题要跨好几个服务查日志，找调用链。团队里一半的开发时间，都花在排查跨服务的小问题上，写业务需求的时间反而被挤得没剩多少。

南京冬天的风从软件大道的写字楼灌进来，老周说那时候天天加班到十一二点，连吃碗鸭血粉丝汤的力气都没。

别为了拆而拆

踩了一年多的坑，老周他们慢慢摸出了门道。微服务从来不是什么必须要追的技术风口，更不是能解决所有问题的银弹。

他们后来把之前拆过的服务又合并了一部分，把用户和营销两个变更频率低、业务耦合高的服务合并回一个，只保留订单和库存两个核心、流量波动大的服务。现在团队的加班时间少了一半，出问题的概率也降了七成。

真要上微服务，先想清楚三件事。先说团队规模，不到20人的别瞎拆，单体的开发效率比拆完高十倍，之前他们12个开发，拆完之后一半人要维护中间件，写业务的人都凑不齐。再说监控能力，没有完善的链路追踪和日志体系之前别碰，拆完服务出了问题找不到根因，比单体难排查十倍。最后是服务边界，按业务域拆别按技术栈拆，之前他们把所有数据库操作抽成了独立的数据服务，最后这个服务成了新的超级单体，比原来的单体还难改。

老周现在跟同行聊微服务，第一句话就是先问对方团队多少人，有没有成熟的运维体系，没有的话趁早别折腾。上周他在珠江路的咖啡馆听见个刚毕业的小孩说要把自己的个人博客拆成微服务，差点把手里的冰美式喷出来。

没人想踩坑。

但坑就是明摆着在那。别看着别人拆服务拆得爽，就不管自己的家底往里面冲。