一、无需重新业务建模

1.1 数据库表不迁移的场景

1.1.1 治理盘点

• 待迁移的接口列表
• 哪些接口需要进一步升级后才能进入待迁移状态
• 接口迁移排期与优先级

1.1.2 新应用上线

• 新应用申请

• 代码迁移（建议原封不动的copy一份代码）

  • 【包路径，读写请求转发，灰度切流（先读后写）】

• 新应用部署

  

1.1.3 生产切流

• 小流量验证

  

1.1.4 迁移监控

• 业务监控
  • 在线核对（证明新接口功能和老接口一致，不一致需回滚）
    • 读类型接口
      • 根据请求参数和响应结果进行比对
    • 写类型接口
      • 在线/离线核对
      • 全量/采样核对
• 稳定性监控
  • 接口的请求总量、耗时、失败量

1.1.5 调用方切换新应用

1.1.5.1 调用方控制流量切换比例

1.1.5.2 新应用控制流量切换比例

1.1.6 老应用下线

• 接口下线（网关下线接口）
• 代码下线（删除代码）

如果需要迁移数据库、缓存、消息队列等，影响面比较大，上述流程也不适用。

1.2 数据库表迁移场景

流程跟《1.1 数据库表不迁移的场景》一致，但对数据库这块变更需要详细说明一下。

1.2.1 数据源评估

• 数据范围：明确需要迁移的数据范围，包括哪些表、字段。
• 数据量与复杂性：估算涉及的数据总量、数据结构复杂程度（如关联关系、索引等）。

1.2.2 数据源消费方评估

• 除了代码中对数据源的查询，可能存在离线链路的数据依赖。

1.2.3 迁移策略选择

• 全量迁移：成本低，风险低。但是需要“业务允许暂停”。

  

• 增量迁移：成本一般，风险高。迁移期间命中切流规则的数据在目标库执行，没命中切流的在源库执行，通过同步机制，最终同步到目标，所以对目标库的查询存在一定的延时。

  

• 双写同步：成本高，风险一般，需要编码处理的事务冲突问题（增量转双写过程）

  

1.2.4 应急预案

• 回滚方案：设计详尽的回滚方案，如遇到严重问题可快速恢复至迁移前状态。
• 数据修复：制定数据修复策略，如发现迁移后数据不一致，应能快速定位问题并修复。

二、需要重新业务建模

流程上可以参考：《1.2 数据库表迁移场景》
需要补充，在线核对+离线核对设计。