Appearance
过渡架构与迁移规划：设计企业不停机变化的路径
新库存平台已经通过压测，团队准备把商城、门店和订单系统一次切换过去。上线当晚，商城已经向新平台预占库存，部分门店仍在旧 POS 本地锁定，支付回调同时触发新旧两个确认任务。系统都在运行，但同一库存事实出现三个修改来源，团队无法判断哪个结果应该保留。
目标架构描述最终状态，过渡架构描述企业在到达目标之前如何安全运行。迁移规划要把 Gap 组合成工作包、能力增量和迁移波次，为每个阶段声明责任、数据、依赖、进入条件、退出条件和收益证据。
先区分四种规划对象
| 对象 | 回答的问题 | 示例 |
|---|---|---|
| Target Architecture | 最终要达到什么状态 | 库存平台统一承诺和审计 |
| Transition Architecture | 某个中间阶段如何稳定运行 | 新商城走新平台，旧门店仍由 POS 负责 |
| Work Package | 哪组变化共同产生一个结果 | 商品映射、预占接口、渠道改造、对账 |
| Implementation/Migration Plan | 何时、由谁、按什么依赖实施 | 波次、资源、窗口、风险和验收 |
过渡架构不是临时部署图。它是一个在限定范围和时间内仍然完整、可运行、可治理的企业状态。
每个过渡状态先声明事实责任
迁移最危险的问题不是“流量切到多少”，而是“谁能改变事实”。库存迁移可以按以下阶段设计：
| 阶段 | 新平台责任 | 旧系统责任 | 写入权威 | 退出证据 |
|---|---|---|---|---|
| T0 基线 | 汇总和对账 | 各渠道判断和锁定 | 各旧系统按原范围 | 差异基线建立 |
| T1 影子 | 计算可售库存并比较 | 继续承担交易写入 | 旧系统 | 主要差异可解释 |
| T2 局部接管 | 指定线上渠道预占、释放、确认 | 未迁移渠道继续旧逻辑 | 按渠道范围唯一 | 新范围对账与演练通过 |
| T3 扩大接管 | 覆盖主要线上与门店 | 只保留适配和本地容错 | 新平台为主 | 旧入口无新增写入 |
| T4 目标 | 统一承诺、观测和审计 | 只读归档或下线 | 新平台 | 旧依赖、任务和权限清退 |
同一个阶段可以有多个权威方，但责任范围必须互斥。例如新商城由库存平台负责，未迁移门店仍由 POS 负责；不能让同一渠道、同一 SKU、同一时段同时双写。
影子运行用于验证而不是拖延切换
影子运行让新系统消费真实输入、计算结果但不参与最终交易。它可以验证：
- 商品、地点和库存身份映射是否正确。
- 新旧规则差异来自语义、时间还是缺陷。
- 新系统能否承受真实流量和数据分布。
- 观测、对账和异常处理是否可用。
影子运行必须有明确的比较口径和结束条件。若只记录“结果有差异”而不分类处理，它会长期存在，团队仍然无法获得接管信心。
常用迁移模式及边界
| 模式 | 适合场景 | 主要风险 |
|---|---|---|
| Strangler 绞杀 | 可按能力、渠道或流量逐步替换 | 路由和数据责任长期复杂 |
| Anti-Corruption Layer | 新旧模型语义不同，需要隔离转换 | 转换层变成永久业务中心 |
| Shadow Traffic | 验证新系统结果和容量 | 隐私、成本和副作用控制 |
| CDC | 遗留数据增量追平 | 缺少业务意图，依赖源表结构 |
| Event Bridge | 新旧事件模型过渡 | 重复、乱序和版本映射 |
| Dual Read | 比较新旧读结果 | 选择结果的规则和时延增加 |
| Dual Write | 极短期无法避免的同步写入 | 部分成功、冲突和补偿复杂 |
迁移模式不是架构目标。每个临时组件都要有 Owner、适用范围、监控和退出日期，否则桥接层会成为新的永久依赖。
双写为什么危险
一次写入两个系统会产生至少四种结果：都成功、旧成功新失败、新成功旧失败、都失败。重试后还会增加重复、乱序和覆盖问题。
如果必须双写，需要明确：
- 哪个系统是最终裁决方。
- 哪个写入先执行，失败时业务如何响应。
- 重试是否幂等，补偿是否可能失败。
- 多久对账一次，谁处理冲突。
- 双写何时停止，什么证据证明可以停止。
更稳妥的做法通常是单一权威写入，再通过 Outbox、事件、CDC 或批处理复制给其他系统。
工作包围绕能力增量
工作包不等于开发一个服务，也不等于某个团队的 Sprint 列表。它应组合能够独立产生业务结果的一组 Gap。
text
WP1 身份与语义基础
商品与地点映射 + 数据 Owner + 质量规则
WP2 库存可视
来源采集 + 时效标记 + 差异分类 + 运营视图
WP3 库存承诺
规则 + 预占状态机 + 接口事件 + 渠道迁移 + 对账
WP4 订单状态统一
企业订单 ID + 状态模型 + 历史查询 + 客服流程
WP5 履约编排
节点能力 + 拆单 + 门店自提 + 异常履约
WP6 遗留退出
旧入口 + 任务 + 权限 + 数据归档 + 合同退出每个工作包都有业务 Owner、完成条件和收益指标。只交付代码但流程、数据责任和旧入口没有改变，工作包不能算完成。
依赖图比日期更重要
路线图首先表达依赖，然后才表达日期：
- 企业 SKU 和地点映射是库存可视的基础。
- 库存可视和差异解释是库存承诺接管的前提。
- 库存承诺稳定后，订单状态统一才能减少兼容逻辑。
- 订单与库存事实稳定后，履约编排才能基于可靠输入优化。
- 每一阶段都要安排遗留退出，否则双轨成本持续累积。
如果跳过依赖，后续项目会在自己的系统中临时补齐前置能力，最终制造新的重复事实和桥接层。
迁移优先级同时考虑价值和风险
可以综合以下因素排序：
| 因素 | 判断方式 |
|---|---|
| 业务价值 | 关闭后改善哪些结果，多久能够观测 |
| 风险降低 | 是否减少资金、合规、数据或运行风险 |
| 时间紧迫 | 供应商退役、法规、合同和活动窗口 |
| 依赖作用 | 是否解锁多个后续工作包 |
| 实施规模 | 组织、数据、应用和技术改造量 |
| 可逆性 | 失败后回退和数据修复难度 |
| 学习价值 | 是否能用小范围验证关键假设 |
优先做高依赖基础不等于长期没有业务收益。可以选择一个有限渠道形成“纵向切片”，既验证身份、库存、订单和运行链路，又控制范围。
切换设计覆盖流量、数据和责任
上线计划常只写流量开关。完整切换至少包含：
- 数据准备：历史迁移、增量追平、校验和差异处理。
- 配置准备：渠道、规则、权限、密钥和 Feature Flag。
- 责任切换：新旧系统谁停止写入，谁开始裁决。
- 流量切换：按渠道、区域、租户或用户分批放量。
- 观测窗口：业务、服务、数据和成本指标的阈值。
- 回退条件：哪些异常触发暂停、降级或回退。
- 回退数据：新系统已产生的状态如何保留、回灌或挂起。
- 退出清理：旧任务、权限、接口、缓存和运维责任。
代码回滚容易，数据和责任回滚困难。回退方案如果没有说明新系统产生的数据如何处理，只是部署回滚，不是业务回退。
进入和退出条件
每个过渡架构都要有明确门槛。例如 T2 局部接管：
进入条件
- 目标渠道商品和地点映射完整率达到阈值。
- 影子结果的主要差异已经分类并关闭高风险问题。
- 峰值容量、幂等、补偿和恢复演练通过。
- 渠道改造、运行手册和人工异常流程就绪。
退出条件
- 目标渠道 100% 预占请求进入库存平台。
- 旧系统在该范围内没有新增锁定记录。
- 超卖率、锁定超时和对账差异达到目标。
- 回退窗口结束，遗留权限和任务清理完成。
没有退出条件的过渡架构会无限期停留，最终成为比原架构更复杂的新常态。
收益实现贯穿迁移路线
迁移不能等到最终 Target 完成才评估价值。每个能力增量应对应收益：
| 阶段 | 预期收益 | 证据 |
|---|---|---|
| 身份与语义基础 | 跨系统数据可以准确关联 | 映射完整率、无法关联记录 |
| 库存可视 | 运营能够解释差异 | 差异分类率、人工排查时间 |
| 局部库存承诺 | 新渠道不再独立锁定 | 超卖率、锁定超时、旧写入 |
| 订单状态统一 | 客服和客户跨渠道查单 | 可见率、客服处理时长 |
| 履约编排 | 提升交付时效并降低成本 | 准时率、单均履约成本 |
| 遗留退出 | 降低双轨和供应商成本 | 运行成本、接口和任务数量 |
收益偏离会触发路线调整：可能是实现不完整，也可能是原业务假设错误。
迁移风险成为治理对象
重点风险包括：
- 身份映射错误导致数据归属错乱。
- 新旧规则差异无法解释。
- 双轨期间重复写入或漏写。
- 第三方和门店改造速度低于计划。
- 过渡组件没有退出责任。
- 旧系统合同、数据和审计要求阻碍下线。
风险要关联具体过渡架构、Owner、缓解措施、触发指标和应急决策，不要只保存在项目风险台账中。
最小交付物
- Target 与各 Transition Architecture 的明确状态。
- 每个范围和阶段的事实权威、系统责任和数据流。
- Gap 到工作包、项目和能力增量的映射。
- 工作包依赖、优先级假设和收益节点。
- 历史迁移、增量、切换、回退和遗留退出方案。
- 每个过渡阶段的进入、退出和暂停条件。
- 业务、数据、服务、运行和成本证据。
常见失效方式
- 只有目标图，没有描述旧系统共存时谁负责什么。
- 路线图按季度排列项目，没有能力增量和依赖关系。
- 把服务上线当成工作包完成，流程和数据责任未改变。
- 双写没有裁决方、补偿和退出时间。
- 只设计代码回滚，没有数据和责任回退。
- 过渡组件缺少 Owner，长期成为新遗留系统。
- 只追踪项目进度，不验证阶段收益和旧责任退出。
能力验证
- 能区分 Target、Transition、Work Package 和实施计划。
- 能为每个迁移范围声明唯一事实权威和责任边界。
- 能选择绞杀、影子、CDC、事件桥接等模式并说明风险。
- 能围绕能力增量组合跨域 Gap，而不是围绕服务拆任务。
- 能设计数据、流量、责任和回退的一体化切换。
- 能为每个过渡阶段定义进入、退出和收益证据。
总结
过渡架构解决的是企业不能停机重建这一事实。它把理想目标拆成一系列仍然完整、可运行、可回退的中间状态；迁移规划再用工作包、依赖、波次和收益把这些状态连接起来。真正可靠的路线图不只是告诉团队何时上线，而是持续回答每个阶段谁拥有事实、风险如何控制、收益是否发生，以及旧责任何时真正退出。