微服务不是目标，而是手段。
很多团队“先拆再说”，结果是：服务变多了，发布更慢了，故障更难查了。
本文给出一条更稳的路径：先识别瓶颈，再按业务边界拆分，再分阶段迁移。
【场景：单体系统出现三类瓶颈】
典型信号：
- 一个小需求需要多人改同一仓库，冲突频繁。
- 任意模块故障都可能拖垮全站。
- 发布窗口越来越长，回滚成本越来越高。
当这些问题持续出现，才说明“值得拆”。
【第1步：先做领域边界，不要按技术层拆】
错误拆法：按 controller/service/repository 拆成多个服务。
推荐拆法：按业务能力拆分（订单域、库存域、支付域）。
判定原则：
- 数据是否天然聚合在一起
- 变更是否经常一起发生
- 团队是否可独立交付
【第2步：优先拆“低风险高收益”模块】
先从这类模块开始：
- 读多写少
- 与核心交易链路耦合较低
- 接口边界清晰
不建议第一刀就拆订单核心链路。
【第3步：建立“防腐层”而不是直接互调】
单体与新服务并存阶段，避免直接数据库互查。
建议：
- 通过 API 或消息契约交互
- 建立 anti-corruption layer 屏蔽旧模型
public OrderDTO queryOrder(Long orderId) {
LegacyOrder legacy = legacyClient.get(orderId);
return mapper.toOrderDTO(legacy);
}
【第4步：数据迁移采用“双写 + 校验 + 切流”】
典型流程：
- 新库建表，旧链路继续提供服务。
- 双写一段时间，校验一致性。
- 按比例切流到新服务。
- 观察稳定后完成下线。
transaction.execute(() -> {
oldRepo.save(order);
newRepo.save(order);
});
【第5步：先补基础设施，再放大拆分】
微服务落地前，至少先有：
- 配置中心
- 服务注册发现
- 链路追踪
- 统一日志与告警
- 灰度发布能力
没有这些，拆分只会把单体问题分散到更多节点。
【迁移节奏建议】
- 阶段1：单体内模块化（先降耦）
- 阶段2：拆 1~2 个边缘服务
- 阶段3：核心链路分域拆分
- 阶段4：治理优化（容量、弹性、成本）
目标是“连续可交付”，不是“一次性重构”。
【迁移检查清单】
- 是否明确“为什么拆”，而不是“为了拆”？
- 领域边界是否按业务语义划分？
- 是否有防腐层避免旧模型污染新服务？
- 数据迁移是否有双写与一致性校验？
- 是否具备可观测与灰度发布能力？
- 是否定义了回滚路径与应急预案？
下期预告：
《可观测性落地：日志、指标、链路追踪怎么统一》
