一次陪跑到凌晨两点的发版
周五晚上八点，运营提了个小需求：购物车的满减提示文案改两个字。老王估了半小时工作量，结果光等发布窗口就等了三天——购物车、订单、支付打包在同一个单体里，谁也不敢中途发版，统一挪到周五晚上动。上线之后全量回归，四个团队陪着改两个字的需求跑到了凌晨两点。
这不是个例。单体走到一定规模，会集体出现三个症状：发布互相卡——一个模块改动，全站回归；故障互相拖——一个模块内存泄漏，全站重启；协作互相等——几十个人改一个仓库，合并冲突天天有。三个症状指向同一个根源：部署边界和组织边界咬死了。
微服务到底解决什么问题
微服务的核心主张只有一句话：把一个部署单元拆成多个，让每个服务可以独立开发、独立测试、独立部署、独立扩容。它本质上是康威定律的工程化——按团队边界切系统边界，让每个小团队对自己那片服务从代码到运维全权负责。
它能换来四样东西：发布解耦，购物车一天发十次不影响支付；故障隔离，推荐服务挂了下单链路还能走；弹性扩容，大促只扩订单服务不扩全站；技术异构，新服务按需选型。注意，性能不在这个清单里——拆分之后多了网络与序列化开销，微服务不是性能方案，拆分前的性能问题拆完还在原地。
拆早了的账单：分布式单体
微服务的账单同样真实：进程内的方法调用变成网络调用，多了延迟、超时、重试三件套；本地事务变成分布式事务；排障从看一个日志文件变成穿八个服务的链路。团队三个人、代码两万行就急着上微服务，大概率拆出分布式单体：服务之间同步调用绕成环，部署上拆开了，耦合上一分没少——运维复杂度翻了十倍，改个需求照样跨四个仓库。
// 分布式单体的典型调用图：任何需求都绕一圈
OrderService -> ProductService -> InventoryService -> OrderService // 循环依赖
// 每条边都是一次网络调用：多一跳，就多一份超时、重试与排障成本三个信号与一条底线
什么时候真的该拆？看三个信号：发布排队——发版窗口成为瓶颈，回归成本高到不敢发；团队规模——单个模块的维护人数超过两个披萨能喂饱的规模；扩容错位——只想扩订单，却得整体扩容。三个信号出现两个，拆分才开始划算；一个都没有，老老实实留在单体里。
还有一条底线：先在单体里把模块边界画清楚，再拆服务。用多模块、包结构和接口层把业务边界隔离好，将来拆分就是把模块搬出去；边界没画清楚就拆，只是把一团乱麻切成几团乱麻，还要额外付网络的税。
下一篇：刀口怎么下
决定拆只是开始，按什么粒度切、数据归谁、边界怎么验收，才真正决定后悔程度。下一篇从一张互相绕圈的调用图说起，讲讲限界上下文与服务拆分的刀法。
评论 (0)