微服务从来不是万能解药

去年深秋在杭州跟一个做生鲜电商的CTO吃夜宵，冰啤酒碰杯的时候他说，团队拆了三个月微服务，现在线上故障比之前跑单体的时候多了三倍，头发掉了半头。

当初为什么要拆

说起来也不是他跟风。之前他们的系统就是一个近百万行代码的war包，所有功能挤在一块，大促的时候库存模块卡壳，整个应用都跟着僵死，用户点结算就转圈，半天出不了支付页。之前试过在代码层面做分层，但是耦合太死，改个商品标签的展示逻辑，要把整个应用停了发版，运维嫌麻烦，产品催进度，两边天天吵架。 后来连着听了几场行业分享，人家说大厂拆了微服务之后，弹性扩展特别灵活，大促的时候只需要给结算模块加几台机器，不用给整个集群扩容，算下来服务器成本能降三成。他当时算完账觉得划算，回来就拉着团队列拆分计划，三个月把原来的单体拆成了12个独立服务，配了统一网关，上了注册中心，当时还在团队内部做了上线庆祝，觉得终于跟上了先进架构的步伐。

拆到一半才发现的暗坑

刚开始跑起来确实顺。每个服务独立发版，改个评价模块的逻辑，再也不用惊动整个系统，产品那边的迭代速度都快了不少。 过了俩月问题开始冒头。 之前在单体里一个本地方法调用的事，现在要跨服务走HTTP请求，网络稍微抖一下，超时了，之前的本地事务直接失效——库存扣了，交易单没生成，用户付了钱找不到订单，客服一天接几十条投诉电话。还有最头疼的排障，之前单体查问题，搜个关键词十分钟就能定位到代码行，现在一个请求要跨三四个服务跳，没有全链路追踪的时候，根本不知道问题出在哪个节点。 他说现在想起来还心梗。大促前三天，支付组的同事改了个回调接口的参数格式，没跟交易组同步，上线之后所有支付回调都失败，当天直接损失小二十万，几个人在公司熬了个通宵才把问题修完。 很多人对微服务的成本估算，只算了拆分代码的工作量，根本没算过拆分之后带来的连锁支出。微服务的核心成本从来不是代码拆分本身，而是拆分之后带来的分布式系统复杂度。每个服务要单独配监控告警、单独做流量限流、单独写部署流水线，之前两个运维就能管的系统，现在要配四个专门的SRE，光配套的中间件license一年就要多花大几十万。

别为了拆而拆

后来他做了个挺”反潮流”的决定：把之前拆出去的评价、用户内容、营销活动几个服务，合并回原来的单体应用，只把最容易成为瓶颈的结算、库存两个模块，拆成独立服务部署。跨服务的同步调用全部改成异步消息队列传递，给核心链路补了全链路追踪的日志埋点。 跑了半年，线上故障量反而比之前全量微服务的时候少了70%，运维成本降了三分之一，大促的时候只需要给结算模块加两台机器，就能扛住平时三倍的流量。 说实话，很多人被网上的技术分享忽悠瘸了，觉得大厂用的架构就是行业标准答案，根本不看自己家的盘子多大。三个人的初创研发组，业务还在天天试错，上来就拆七八个微服务，每次发版要改七八个仓库，配七八条流水线，写个新功能要跨三个服务调接口，两周的活硬生生拖两个月，最后又哭着合并回单体的案例，我见过没有十个也有八个。 技术选型从来不是越复杂越好。如果你的单体应用跑着很稳，团队规模不大，不同模块的迭代节奏基本一致，大家坐一个办公室，改代码抬头就能对齐需求，真没必要凑微服务的热闹。反过来，如果你的单体已经臃肿到改一行代码就要全量回归，不同模块的迭代节奏完全错开，经常因为某个非核心模块的故障拖垮整个系统，那拆微服务才是划算的选择。 上次再跟那个CTO见面，他说现在最烦别人一上来就问”你们上微服务了吗”，好像没上就是技术落后。技术这东西，从来没有标准答案。能帮团队少熬点夜，能让业务跑的稳当，比啥都强。