7.1 微服务：重联编组

7.1 微服务：重联编组

新型列车第一款：微服务。它把一列超长的单体火车，改成一组短编组——每个编组可独立检修、独立发车、独立退役。这个模型过去十年被讲得天花乱坠，本节只做两件事：说清它到底解决什么问题，算清它向你要走什么代价。拆与不拆的判据，最后都会落到你团队的底盘能力上。

重联编组不是越碎越好

微服务的正确定义是：按业务边界划分的、可独立部署的服务单元，每个单元有自己的数据与生命周期，服务间走稳定契约通信。注意重点词是"独立部署"——代码拆得碎但还得一起发版，那叫分布式单体：拿到了分布式的全部麻烦，没拿到微服务的一样好处，是最差的形态。

它真正解决的是规模问题，而且是两种规模的耦合问题：

• 代码规模：单体长大后，一处改动要回归全车，发布窗口人人排队；
• 团队规模：几十人在一个代码库上协作，合并冲突与协调成本指数上升。

车站类比：单体是超长编组——任何一节车厢大修，整列车都得停轮；微服务是重联编组——短编组各自进出检修库，线路整体不中断。看两类部署的对比：

图 7-1：单体与微服务的发布与故障对比

拆与不拆：三个判据

判据不是技术时髦度，是三道硬门槛，全部达标才谈拆：

• 团队门槛：康威定律说系统结构会映射组织结构——单个服务应能被一个小组（十人以内量级）全权拥有。如果全公司只有六个人，拆八个服务意味着每人"拥有"一点二个服务，边界纯属自找；
• 部署门槛：存在真实的发布冲突——计费每周发三次而报表每月发一次，被迫绑在一起等窗口，这是拆分的正当理由；发布节奏本来就一致时，拆了只是增加成本；
• 故障隔离门槛：业务要求"报表挂了不能影响计费收款"这类隔离性时，独立部署单元才有意义；反之，单体加好监控与降级开关往往更省。

云梯的决策实录值得参考：v1 是刻意保留的单体——六个团队成员、发布节奏一致，拆了纯属自虐。到 v3，计费规则的变更频率是对账模块的四倍，且财务要求对账不因计费发版而停摆，两道门槛亮灯才拆；拆分顺序也克制——先拆变更最频繁的计费引擎，其余模块按需跟进。

拆完之后的纪律

微服务不是终点而是新约束的开始：契约即法律——接口版本化，变更先兼容后废弃；数据就近拥有——每个服务独占自己的存储，跨服务读取走接口而不是直连别人家的库；可观测先行——链路追踪、集中日志、按服务的监控看板在第一轮拆分前就位，否则排障就是盲人摸象。

⚠️ 最贵的失败模式是"按技术分层拆"：数据库一个服务、业务逻辑一个服务、界面一个服务。这是把三层的耦合换成了网络调用，没有换来业务边界的独立。正确的拆分线画在业务能力上——计费、对账、司机服务，而不是界面、逻辑、数据。

迁移路径：绞杀者模式

拆分最忌讳"停机重写"——旧系统照常跑、新系统另起炉灶、数据两头写，最后死在切换的那一夜。更稳的路径是绞杀者模式：新服务像藤蔓一样逐步包住旧系统——在旧单体前面架一层路由，按业务能力一段一段把流量切到新服务，切稳一段拆一段，旧代码逐步萎缩直至退役。云梯拆计费引擎走的正是这条路：先让新旧两版并行跑影子流量（新引擎只算不算，结果与旧版对账），对账差异清零后按仓库灰度切换，全程旧系统始终可回退。绞杀者的要诀是每一步切换都可逆——这与第 3.5 节发布纪律是同一条哲学，只是搬到了架构层面。

拆完之后的第一课：对账文化

分布式化之后，跨服务的数据一致性从"数据库事务"变成"业务对账"：订单服务说收了款、计费服务说记了账，两边说的一致吗？云梯为此建了每日对账任务——比对两侧的关键流水，差异进缺陷单走分级处置。这堂课的普适结论值得记下：微服务把强一致换成了最终一致，而最终一致的信任不是靠乐观，是靠一张每天跑的对账表。拆分方案评审时如果没有对账设计这一页，说明分布式的事务影响还没有被真正消化。

服务间通信的两种口吻

拆分之后，服务间说什么话、怎么说，是绕不开的第一课。同步调用（请求响应）像打电话——拨通才有答案，对方占线你就干等；异步消息（事件通知）像发电报——发完就走，收件方按自己的节奏处理。两者没有优劣，只有场合：计费查询要立刻给司机答案，用同步；订单完成要通知对账与报表，用异步——通知类场景异步天然抗抖动，下游故障不至于把上游拖垮。新人最常犯的错是把同步调用串成长链——一个请求跨五跳同步等待，任何一跳抖动，全链超时。经验法则：链上同步跳数控制在两三跳以内，再往后的事件传播交给消息。通信方式的选择，本质上是在为每一次故障划定影响半径。

分布式的问题清单：拆之前先自问

拆分评审会上，值得把分布式的代价问题一张张过掉：网络会失败——调用方超时与重试的口径定了没有；重试会重复——幂等设计在哪个层兜底；时钟会漂移——跨服务的先后顺序还能信吗；数据会分裂——跨服务查询与报表从哪里取数。每一问都答得上来，拆分才具备开工条件；答不上来的那一问，往往就是拆分后第一批线上事故的剧本。这份清单不是劝退，是把"分布式单体"的侥幸提前击碎——微服务的自由，只属于预先付清这些代价的团队。

两个高频疑问

问：服务数量有没有参考上限？ 有个朴素公式可以自查：服务数不应明显超过"能全权拥有服务的团队数"。六个团队养十四个服务，意味着多数服务处于"部分拥有"状态——值班不知道找谁、契约没人守、升级没人排期。服务不是资产越多越富，无人认领的服务是负资产。

问：拆分后接口改个字段为什么那么麻烦？ 因为接口已从"函数调用"升格为"公共契约"。正确的变更加版本双轨：新版接口并行发布，消费方按自己的节奏迁移，旧版在所有消费方迁完且过观察期后才下线——整个流程像列车改线，新线通车、旧线留运、最后拆除。觉得慢的人可以算另一笔账：没有这套流程的直接改字段，改坏一个没同步的消费方，故障排查要跨团队开好几天会。

本节要点回顾

• 微服务是按业务边界独立部署的单元；拆而不独立部署的分布式单体最糟。
• 它解决代码与团队双重规模问题，小团队拆碎服务是自找边界税。
• 拆分三判据：小组可全权拥有、存在真实发布冲突、业务需要故障隔离。
• 账单五条：一致性补偿、运维体量、联调成本、契约治理、排障链路。
• 拆分线画在业务能力上，绝不按技术分层拆。
• 云梯节奏：单体起步、门槛亮灯才拆、先拆变更最频繁的引擎。

车型改好了，下一节把车场本身升级——弹性调度的立体车场。