还在为系统迁移烦恼？掌握这些“基本法”解锁更多可能

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

作者|王翔（烈翼）
出品|阿里巴巴新零售淘系技术部

背景

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

系统迁移方案概述

▐ 主要步骤

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

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

需要解决的主要问题：
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的方式原生决定了预发的不可测试性，不方便功能的快速迭代和稳定上线。

One More Thing

我们是淘宝内容社交互动团队，主要承载了用户从“买在淘宝”到“消费生活在淘宝”的重要体验升级，基于新的产品模式和运营模式，通过内容化，游戏化和社交社区化推动用户在淘宝内的活跃。伴随着广阔的业务空间机会之下的是有足够挑战性的技术场景: 我们有百亿级的用户关系和用户互动数据资产有待发掘，百万QPS的大流量高可用强一致性多租户技术场景，覆盖从工程开发，推荐算法，大数据分析平台等，提供了职业生涯增长空间和多样的岗位选择：数据化驱动运营，大容量高并发系统，推荐搜索服务平台，深度学习的工程体系等等
请投递简历至邮箱：[e-mail]