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

作 者|王翔（烈翼）

出品|阿里巴巴新零售淘系技术部

背景

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

系统迁移方案概述

▐  主要步骤

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

基础数据存量/增量迁移

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

需要解决的主要问题：

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的大流量高可用强一致性多租户技术场景，覆盖从工程开发，推荐算法，大数据分析平台等，提供了职业生涯增长空间和多样的岗位选择：数据化驱动运营，大容量高并发系统，推荐搜索服务平台，深度学习的工程体系等等

请投递简历至邮箱： [email protected]

动动动动起来了！可交互内容玩法技术揭秘

玩转娱乐化时代|淘系互动团队几年的技术沉淀+经验都在这！