系统迁移基本法

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

云栖号资讯:【点击查看更多行业资讯
在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来!

背景

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

系统迁移方案概述

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

基础数据存量 / 增量迁移

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

需要解决的主要问题:
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、 索引构建依赖精卫任务同步完成,整体示意图如下:

c44fa4a6404d43ca6cb880dfdd745d66

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

写接口迁移

1、支持反向同步通道(新系统 -> 老系统)
2、源系统 tag 防止死循环
3、写接口层路由,先写新系统

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

90fec853cd953e486b01bd7b508117cd

方案二:索引构建不依赖精卫
数据存量迁移 / 增量同步
1、 精卫存量 / 增量任务

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

写接口迁移
(双向同步阶段)
1、 反向同步通道(保证数据能回流到老系统,兼容老业务) 新 -> 老
2、 源系统 tag(保证双向同步时不出现循环)
3、 写接口路由开启(从先写老库切换为先写新库)

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

7007c2e13a6582a3b3452c110bde51ec

其他步骤与方案一相同
存量数据索引构建
1、 dts 任务读取存量离线表,完成存量数据新索引构建,这里可以使用多机并发任务。

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

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

方案三:完全不依赖精卫
数据存量迁移 / 增量同步
1、 dts 任务读取存量离线表,接口方式迁移存量数据
2、 增量同步依赖接口层双写

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

读接口迁移
1、 第一步会同步完成索引构建,因此可以先迁读接口
写接口迁移
1、 反向同步通道
2、 写接口路由开启,路由开启后,接口层双写自动关闭,数据开始 先写新系统 -> 再回流老系统

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

总结

3 套方案分别解决不同场景的问题,各有优劣,有以下几点可以作为方案选型的判断依据:
1、基础数据迁移: 新老系统都使用 mysql 存储时,尽量采用精卫做全量 / 增量迁移,精卫本身作为一款专业的数据同步工具,功能全面,可以最大程度保障数据迁移后的一致性和准确性,同时还可以利用精卫控制台随时调整迁移速度,保障迁移过程的稳定性。
2、读写接口迁移顺序: 依据索引构建的具体方案决定读写迁移的先后,读接口迁移强依赖索引构建完成:
方案一的优点: 基础数据与索引可以同步完成迁移,先切读接口也比先切写接口风险较低。
方案二的优点: 虽然不依赖精卫构建索引使得需要专门写任务重建索引,但不依赖精卫的索引构建方案在实际工程中更方便逻辑修改与迭代,精卫依赖 binlog 的方式原生决定了预发的不可测试性,不方便功能的快速迭代和稳定上线。

【云栖号在线课堂】每天都有产品技术专家分享!
课程地址:https://yqh.aliyun.com/zhibo

立即加入社群,与专家面对面,及时了解课程最新动态!
【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK

原文发布时间:2020-06-01
本文作者: 王翔(烈翼)
本文来自:“InfoQ”,了解相关信息可以关注“InfoQ

相关文章
|
5月前
|
SQL Oracle 关系型数据库
xtts 迁移注意
xtts 迁移注意
44 9
|
关系型数据库 MySQL 测试技术
不停机更换数据库解决方案
随系统规模逐渐增长,总会遇到更换数据库问题。 对MySQL分库分表后,需要从原来的单实例数据库迁移到新的数据库集群 系统从传统部署方式向云上迁移的时候,也需要从自建的数据库迁移到云数据库
255 0
系统迁移
系统迁移
121 0
|
6月前
|
弹性计算 Linux Windows
服务器迁移
本实践以小微客户为例,提供两个场景的迁移验证实践。采用 SMC 模式,一个以阿里云内部迁移举例;一个以他云服务器为例,迁移到华东2(上海)。
服务器迁移
|
存储 资源调度 Cloud Native
阿里云迁移工具推荐最佳实践:物理服务器迁移到阿里云
阿里云迁移工具推荐最佳实践:物理服务器迁移到阿里云
阿里云迁移工具推荐最佳实践:物理服务器迁移到阿里云
|
Windows 数据安全/隐私保护 搜索推荐