微服务落地那些没人说的糟心事

去年深秋在新街口附近的咖啡馆碰到老周的时候，他整个人裹着皱巴巴的冲锋衣，眼睛里全是红血丝。

他之前是那家做女装电商的技术负责人，去年跟风上了微服务架构，折腾了整整一年，现在整个人快被磨垮了。

说起来也可笑。

他们公司原来的单体系统跑了三年，去年618扛过每秒1200的订单峰值，从来没崩过。结果CTO去参加了个行业峰会，听人说微服务是未来架构方向，回来拍板要求全量拆分。

别被架构图骗了，微服务从来不是默认最优解

很多人对微服务的认知，还停留在宣传PPT上——拆成独立的小服务，每个服务单独部署，迭代更快，容错性更高，好像只要拆完，所有的技术问题都能自动解决。

真的。

根本不是那么回事。

微服务从来不是什么架构万能药，它只是特定场景下的一种技术选择而已。微服务的设计初衷，是给那种团队规模大、业务线复杂、单个系统已经到了几百人共同维护不动的大型公司用的。比如阿里、腾讯这种体量的业务，不拆的话，改一行代码要走几十人的代码评审，部署一次要停几个小时的机，那才真的要命。

但对小团队来说，这套东西的性价比低到离谱。

老周他们团队满打满算10个开发，当初拆完之后硬生生拆成了23个服务，平均每个服务分不到半个开发，现在光维护各个服务的版本依赖，就够大家喝一壶的。

拆完之后才发现的隐形账单

当初拍板拆的时候，没人算过这些账。

原来的单体应用，改个优惠券的计算规则，开发在本地跑个测试，半小时就能提测，一天就能上线。现在倒好，优惠券规则要动优惠券服务、订单服务、用户权益服务、库存校验服务，四个服务的代码要改，四个环境要部署，四个团队要联调。

老周说上次改个满减叠加的规则，光联调就花了三天。等所有测试走完准备上线的时候，才发现库存服务漏了个校验逻辑——用户领了券下单，到支付环节才提示库存不足，当天接了两百多单客诉，运营在群里把技术团队骂到抬不起头。

还有那些看不见的运维成本。

原来两个运维就能扛住所有的系统监控、部署、告警处理，现在因为服务拆得太碎，要专门搭链路追踪系统、日志聚合平台，每个服务还要单独配监控告警，拆服务的隐形成本，往往比你当初预估的高好几倍，光云资源的成本，每个月就多花了两万多。

哦对，还有告警。原来单体的时候，一天最多弹两三个告警，现在几十个服务，每天光半夜弹的告警就有十几条，很多时候都是服务之间的网络抖动，根本不是什么大问题，但开发还是得爬起来排查，就怕漏了真的故障。

真要上微服务，先摸清楚这几个前提

当然也不是说微服务就完全没用，要是你的业务真的到了单体扛不住的阶段，该拆还是得拆。但别脑子一热就跟着别人上，先把几个最实在的问题想清楚。

先算团队规模的账。要是整个研发团队加起来不到15个人，真没必要凑这个热闹。代码只要不是写得太烂，单体应用的维护成本低得多，迭代速度也快，完全够中小团队用。

再想清楚你要解决的核心问题。是单体已经频繁出现单点故障，某个模块一挂整个系统都用不了？还是团队大到几个人改同一份代码，天天出现合并冲突？如果都不是，只是觉得”别人都在用微服务，我们不用就落后了”，那趁早打住。

配套的基础设施得提前搭好。别等服务拆了十几个，连个统一的日志查询平台都没有，线上出了问题，开发要登七八台机器挨个翻日志，等你找到问题根源，用户都走光了。

老周他们后来也想通了。

上个月他们把拆得太碎的十几个小服务又合并回了单体，只把流量最大的订单模块单独拆了出去。现在上线周期从原来的两周缩到了两天，这个月做品类大促，系统稳得一批，老周上周还约我去南京大牌档吃盐水鸭，说终于不用天天凌晨爬起来看告警了。