系统迁移基本法

背景

社区评论系统在完成了基础功能建设后，开始逐步将老系统业务迁移到新系统，实现整体架构统一、新系统功能赋能老业务、节省系统维护成本；迁移过程本身虽然枯燥无味，但并不妨碍通用解决方案的沉淀，本文以评论新老系统迁移为背景，聊聊系统迁移的基本方法，同时也希望能抛砖引玉，探索更多迁移方案的可能性。

系统迁移方案概述

主要步骤

就一般的系统而言，主要涉及到以下几个步骤，其中，读写接口迁移顺序可以根据实际情况做先后调整：

基础数据存量/增量迁移

目标：老系统存量数据迁移到新系统，增量数据实时同步到新系统

需要解决的主要问题：

1、 保证数据不丢失，同步后新系统数据准确

2、 新老系统 id 映射：新老系统 id 体系不同时，需要做好 id 映射，比如新 db 中扩展字段存老系统 id，同时将老系统 id 对应的新系统 id 存到 ldb，方便反查；评论新系统设计之初为了方便老系统迁移，使用了与老系统相同的 sequenceId 生成体系，因此不需要考虑 id 映射问题

读接口迁移：先读新系统

目标：接口层直接查新系统

需要解决的主要问题：新老接口数据结构兼容，降低前台迁移成本

写接口迁移

目标：新数据先写新系统

需要解决的主要问题：

1、 前期需要支持反向同步到老系统（这一步之所以需要双向同步回老系统，主要是为了兼容老业务接口、odps 数据，很难一步切干净），需要保证双向同步时不出现死循环

2、 老系统各个写入口都要做适配路由，这一步改造的工作量比较大，与具体系统特性相关性比较大，本文不做讨论

关键阶段

相应的，系统迁移过程也会有几个关键阶段：

阶段一： 数据单向同步阶段（老系统->新系统）

阶段二： 读/写接口迁移完成，入口流量先走新系统，增量数据先写入新系统，再同步回老系统（双向同步阶段）

阶段三： 所有下游业务流量、mtop 入口流量均迁移到新系统，老系统流量逐步清 0 直到下线；这一步也是最终完美的状态

一般来讲，需要平台侧做的适配改造全部完成后，即可进入阶段二，阶段三主要依赖逐步推动下游业务方迁移，平台方本身不需要再做额外改动，因此本文总结的方案重点以解决前两个阶段面临的问题为主。

此外，根据不同的系统特性，除了基础数据迁移，可能还会多一步索引构建，比如评论系统，索引层就是系统很重要的一部分，几乎支撑了前台所有的查询场景，而索引构建策略也会影响到迁移方案的选型。

评论系统迁移的几种方案

方案一：依赖精卫做数据迁移与索引构建

数据存量迁移/增量同步

1、 精卫存量/增量任务

2、 精卫 client/sar 包任务同步创建索引（目前 client 模式已下线，只能使用 sar 包方式）

说明：

1、 如果系统可以接收一部分增量数据不一致，可以先开启增量任务，再开启全量任务（相同记录会覆盖写）；如果系统对一致性要求高，需要使用精卫增量任务的位点回溯功能，保证在全量数据迁移期间发生的所有变更都能同步到新库，如果全量任务迁移时间较长，还需要联系精卫值班保留更长时间的位点（线上默认位点只保留 1 天）

2、 索引构建依赖精卫任务同步完成，整体示意图如下：

读接口迁移

由于索引已同步创建，所以可以直接在接口层做读接口路由迁移

写接口迁移

1、支持反向同步通道（新系统->老系统）

2、源系统 tag 防止死循环

3、写接口层路由，先写新系统

说明：通过给先写入新系统的数据打源系统标的方式防止双向同步死循环（这里也可以使用打鹰眼标的方式，但个人认为不如直接存储源系统标更保险，也容易根据源数据溯源），老系统->新系统的增量通道中通过校验数据是否带新系统标，决定处理还是丢弃，写接口迁移后新老系统双向同步状态示意图如下：

方案二：索引构建不依赖精卫

数据存量迁移/增量同步

1、 精卫存量/增量任务

说明：存量/增量数据方案与方案一相同

写接口迁移

（双向同步阶段）

1、 反向同步通道（保证数据能回流到老系统，兼容老业务） 新->老

2、 源系统 tag（保证双向同步时不出现循环）

3、 写接口路由开启（从先写老库切换为先写新库）

说明：读接口切换前需要先完成索引重建，索引重建包括增量/存量两部分，增量部分依赖系统异步消费评论写接口成功后发的 metaq 消息完成，因此需要先对写接口做迁移，保证增量数据能进索引：

其他步骤与方案一相同

存量数据索引构建

1、 dts 任务读取存量离线表，完成存量数据新索引构建，这里可以使用多机并发任务。

说明：增量数据索引构建依赖写接口切换，存量数据的索引构建则需要专门写任务读离线表完成。

读接口迁移

1、 索引存量/增量数据构建完成后，可以开启读接口切换

方案三：完全不依赖精卫

数据存量迁移/增量同步

1、 dts 任务读取存量离线表，接口方式迁移存量数据

2、 增量同步依赖接口层双写

说明：精卫方案一般适用于新老系统存储都使用 mysql 的场景，当存储方案不一致时，只能通过写 dts 迁移任务的方式完成存量数据迁移，由于是走接口层写入数据，所以 metaq 方式构建的索引可以同步完成重建。

读接口迁移

1、 第一步会同步完成索引构建，因此可以先迁读接口

写接口迁移

1、 反向同步通道

2、 写接口路由开启，路由开启后，接口层双写自动关闭，数据开始 先写新系统->再回流老系统

说明：这里不存在双向同步的问题，老系统->新系统的同步链路在接口层双写，写接口路由开启后，在先写新系统的同时，双写逻辑就会关闭，只需要构建反向通道将数据同步回老系统即可

总结

3 套方案分别解决不同场景的问题，各有优劣，有以下几点可以作为方案选型的判断依据：

1、基础数据迁移： 新老系统都使用 mysql 存储时，尽量采用精卫做全量/增量迁移，精卫本身作为一款专业的数据同步工具，功能全面，可以最大程度保障数据迁移后的一致性和准确性，同时还可以利用精卫控制台随时调整迁移速度，保障迁移过程的稳定性。

2、读写接口迁移顺序： 依据索引构建的具体方案决定读写迁移的先后，读接口迁移强依赖索引构建完成：

方案一的优点： 基础数据与索引可以同步完成迁移，先切读接口也比先切写接口风险较低。

方案二的优点： 虽然不依赖精卫构建索引使得需要专门写任务重建索引，但不依赖精卫的索引构建方案在实际工程中更方便逻辑修改与迭代，精卫依赖 binlog 的方式原生决定了预发的不可测试性，不方便功能的快速迭代和稳定上线。

本文转载自公众号淘系技术（ID：AlibabaMTT）。

原文链接：

https://mp.weixin.qq.com/s/wz0Pny7UHc-PKw420ks2Vg