系统迁移基本法

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

背景

社区评论系统在完成了基础功能建设后,开s L Y始逐步将老系统业务迁移到新系统,实现整体架构统一、新系统功能赋能老业务、节省系统维护成本;迁移过程本身虽然枯燥无0 r 0 ) n 2 S T R味,但并不妨碍通用解决方案的沉淀,本文以评论新老系统迁移为背S / X U景,聊聊系统迁移的% B C K : t U C Z基本方法,同时也希望能抛砖引玉,s 5 y a _探索更多迁移方案的可能性。

系统迁移方案概述

主要步骤
就一般的系统而言,主要涉及到以下几个步骤,其中F } I L C e $,读写接口迁移顺序可以根据实际情况做先h G i h =后调整:e c 7 | g - | G @

基础数据存量 / 增量迁移

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

需要解决的主要问题:
1、 保证数据不丢失,同步后新系统数据准确
2、 新老系统 id 映射:新老系统 id 体系不同时,需要做好 id 映射,比如新 db 中扩展字段存老系统 id,同时将老系统 id 对应的新系统 id 存到 ldb,方便反查;评论新系统设计之初为了I l | u c方便老系统迁移,使用了与老系统相同的 sequenceId 生成体系,因此不需要考虑 id 映射问题

读接口迁移:先读新系统

目标:接口层直接查新系统
需要解决的主要问题:新老接口数据结构兼容,降O + & k低前台迁移成本

写接口迁移

目标:新数据先写新系统
需要解决的主要问题:
1、 前期需要支持反向同步到老系 # ) h 6 A & 9统(这一步之所以需要双向同步回老系统,主要是为了兼容老业务接口、odps 数据,很难一步切干净),需要保证双向同步时不出 , q u z +现死循环
2、 老系统各个写入口都要做适配路由,这一步改造的工作量比较大,与具体系统特性相关性比较大,本文不做讨论

关键阶段

相应的,系K u W统迁移过程也会有几个关键阶段:
阶段一: 数据单向同步阶B . ? , 4段(老系统 -> 新系统)
阶段二: 读 / 写接口迁移完成,入口流量先D 0 7 j | W # 走新系统,增量数据先写入新系统,再同步回老系统(双向同步阶段)
阶段三: 所有下游业务流量、mtop 入口流量均迁移到新系统,老系统流量逐步清 0 直到下线;这一步也是最终# M i . / @ e ` _完美的状态

一般来) 1 L讲,需要平台侧做的适配改造全部完成后,即可进入阶段二,阶段三主要依赖逐步推动下] a p r Y S 3 G游业务方迁移,平台方本M : + x身不需要3 w E再做额外改动,因此本文总结的方案重点以解决前两个阶段面临的问题为主。

此外,根据不同的系统特性,除了基础数据迁移,可能还会多一步索引https://www.fons.com.cn/tag/%e6%9e%84%e5%bb%ba" target="_blank">构建,比如评论系统,索引层就是系统很重要的一部分,几乎支撑了前台所有的查询场景,而索引u P B $ ,构建策略也会d e影响到迁移方t / $ t ~ 0 ! j ,案的选型。

评论系统迁移的几种方案

方案一:依赖精卫做数据迁移与索引构建
数据存量迁移 / 增量同步
1、 精卫存量 / 增量任务
2、 精卫 clientQ } w ; 0 6 v _ 1/sar 包任务l y ? ! q 9同步创建索引(目前 client 模式已下线,只能使用 sar 包方式)

说明:
1、 如果系统可以接收一部分增量数据不一致,可以先开启增量任务,再开启全量任务(相同记录会X & k + d o覆盖写);如果系统对一致性要求高,需要使用精卫增量任务的位点回溯功能,保证在全量数据迁移期间发生的所有变更都能同步到新库,如果全量任q n F U务迁移时间较长,还需要联系精卫值班保留更长时间的位点(线上默认位点只保留 1 天)
2、 索引构建依赖精卫任务同步完成,整体示意图如下:

系统迁移基本法

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

写接_ P $ P j口迁移

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

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

系统迁移基本法

方案二:索引构建不依赖精卫
数据存量迁移 / 增量b b ^ e 9 %同步
1、b w h $ b b g 精卫存量 / 增量任务

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

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

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

系统迁移基本法

其他步骤与方案一相同
存量数据索引构G e y O , ]
1、 dts 任务读取存量离线表,完成存量数据新索引构建,这里可以a d s ] ; ~ .使用多机并发任务。

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

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

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

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

读接口迁移
1、 第一步会同步完成索引构建,因此可以先迁读接口
写接口迁移
1、 反向同步通道
2、 写接口路由开启,路由开& y c启后,接口层S 5 M ] ? o n双写自动关闭,数据开始 先写新系统 -> 再回流老系统O ^ k Z %

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

总结

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

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

立即加J 5 | % r ?入社群,H b ~ X 2 z X |与专家面对面,及时了解课程最新动态A S ( t Z )
【云栖号在线课堂 社群】https:z Y I D I L//z F V Q bc.tb.cn/F3.Z8gvnK

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