模块化单体到微服务：订单中心拆分的七个取舍点

把订单中心从一套三十万行的单体里拆出来，是我们团队这两年做过最贵的一次重构。贵不在写代码，而在每一个“看起来无所谓”的决定后面都跟着一串账单。下面七个取舍点，是按踩坑顺序整理的，不是按教科书顺序。

一、先定边界，再谈技术栈

大多数拆分失败的项目，问题出在第一周：先选好了服务框架和注册中心，然后开始琢磨“哪些表分出去”。正确的顺序是反过来的——先回答“谁的变更会卡住谁”。

我们用限界上下文画了两轮图。第一轮按部门画，画出来一团乱麻；第二轮按数据所有权画，边界立刻清楚：订单只拥有“下单意图与履约状态”，支付流水归支付域，库存扣减归库存域。订单表里原来那十几个 pay_* 字段，全部退化成一份支付状态快照，只用来渲染列表页，不作为事实来源。

这一步花了三周，没有写一行生产代码，但它决定了后面所有接口的形状。跳过它的团队，通常会在第六个月开始第二次拆分。

二、数据库按三步走，不要一步到位

“一个服务一个库”是终点，不是起点。我们的路径是：共享实例分 schema → 独立实例 → 按读压力做只读副本。每一步都留了至少一个发布周期的观察窗口。

• 分 schema：先把跨域 JOIN 全部显式化，编译器帮我们找出了 40 多处隐式耦合。
• 独立实例：连接池、慢查询、备份窗口互不影响，这一步之后故障隔离才真正成立。
• 只读副本：列表与报表走副本，写链路不受影响。

跳过中间步骤直接拆库的团队，通常会在灰度期间被分布式事务补丁拖住，最后写出一套比单体更难维护的东西。

三、一致性用事务性发件箱，不要用分布式事务

下单要同时写订单、扣库存、发通知。我们试过两阶段提交，跨三个存储、平均延迟 180ms，而且协调者一挂全链路阻塞。最后换成“本地事务 + 事务性发件箱 + 幂等消费”，延迟回到 12ms 量级。

BEGIN;
INSERT INTO orders (id, user_id, amount, status) VALUES (?, ?, ?, 'CREATED');
INSERT INTO outbox (aggregate_id, event_type, payload, created_at)
VALUES (?, 'OrderCreated', ?, now());
COMMIT;  -- 业务数据与事件同一事务落地

独立的中继进程按主键顺序扫 outbox，投递后标记已发送。消费端必须幂等，否则重投就是灾难：

INSERT INTO consumed_events (event_id, consumer)
VALUES (?, 'inventory-service')
ON CONFLICT (event_id) DO NOTHING;   -- 影响行数为 0 说明已处理过

关键点在于幂等键要来自事件本身，不能用消费时间或随机 UUID。我们最初用消息 ID，结果中继重启后重新生成了 ID，同一笔扣减执行了两次，对账花了三天。

四、同步调用只走查询，写链路一律异步

我们的规则很简单：跨服务的写操作不允许多一次远程调用。下单链路里，库存预占是异步事件驱动的，页面上的“预计发货时间”则是一次带 300ms 超时的同步查询——超时就直接降级成“以实际为准”。

同步调用必须有三个东西：明确的超时、明确的降级值、明确的熔断阈值。缺一个，就等于把整条链路的可用性交给了最慢的那个下游。

五、可观测性要在拆分之前建好

单体时代一个堆栈就能定位问题，拆开以后一个请求穿过六个服务，没有 trace 等于摸黑。我们在拆分前一个季度先做了三件事：全链路 trace id 透传、每个入口打 RED 指标（Rate / Errors / Duration）、日志结构化并统一字段名。

这三件事的收益在第一次线上故障时就回来了：从“用户说下单失败”到定位到库存服务的连接池耗尽，用时四分钟，而过去这种问题要一个小组合计两小时。

六、按团队拆服务，而不是按技术分层拆

康威定律不是建议，是物理规律。我们最初按“接入层 / 业务层 / 数据层”拆，结果每个需求仍然要三个团队一起改，发布还得对齐窗口。改成按业务能力拆之后，一个团队拥有订单全链路（含自己的库和流水线），发布频率从双周变成按需。

判断边界是否合理，有个很土但有效的测试：让一个团队独立发布一次，看是否需要别人审批。需要，就说明边界还没切干净。

七、回滚设计要写在设计文档里

拆分的风险不在上线那一刻，而在上线后第二天的流量高峰。我们每个新服务都强制带三样东西：特性开关（可以一键切回旧的实现路径）、影子流量（新服务先接 5% 只读流量比对结果）、以及明确的数据回滚脚本。

其中特性开关最重要。它把“回滚”从一次紧张的发布操作，变成一次配置变更。

写在最后

拆分不是目的。我们真正的目标是两件事：故障不再全站放大，以及一个需求不再需要五个团队对齐排期。如果这两件事没有改善，那么拆出来的服务只是把复杂度从代码搬到了网络上。

一个务实的判断标准是：拆分完成后，单个服务的平均恢复时间是否下降、单个需求的平均交付周期是否缩短。这两个数字没有变好，就说明这次拆分只是换了个形状。