写点什么

系统迁移基本法

2020 年 6 月 01 日

系统迁移基本法

背景

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


系统迁移方案概述

主要步骤

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


基础数据存量/增量迁移


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


需要解决的主要问题:


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


2020 年 6 月 01 日 10:00970

评论 1 条评论

发布
用户头像
最近正好在做重构,因为数据库结构部分修改了,加上新旧库双向同步时循环问题没有好的解决方法,放弃了通过解析binlog的方式
2020 年 06 月 01 日 13:11
回复
没有更多了
发现更多内容

劫持Chrome浏览器“获利”8000万元 | 法庭上的CTO(13)

赵新龙

CTO 法庭上的CTO

计算机网络简述

lee

计算机网络 网络协议 网络

重磅|中国PostgreSQL分会与腾讯云战略合作协议签订

PostgreSQLChina

数据库 postgresql 软件 开源社区

创建493个测试账户,被公司索赔527万 | 法庭上的 CTO(14)

赵新龙

CTO 法庭上的CTO

深入浅出 ZooKeeper

vivo互联网技术

zookeeper 分布式 ZAB

英特尔赵宏:从硬件创新到平台突破,PC的未来非常值得期待

intel001

智慧仓储管理系统,是否能解决购物狂欢节后新一轮爆仓危机?

一只数据鲸鱼

物联网 数据可视化 智慧物流 智慧仓储

智能合约交易所系统开发

DV:19924636653

软件开发

快速接入 | 从 0 到 1 构建语音聊天室

拍乐云Pano

音视频 RTC 实时语音 语音聊天室 语聊房

未签订劳动合同的CTO | 法庭上的 CTO(17)

赵新龙

CTO 法庭上的CTO

股东变员工,所以不发工资?| 法庭上的CTO(18)

赵新龙

CTO 法庭上的CTO

甲方日常 75

句子

工作 随笔杂谈 日常

这个问题值得讨论吗?

Alan

沟通 团队文化 七日更 28天写作

从MongoID的生成讨论分布式唯一ID生成方案

行如风

雪花算法 分布式ID 全局唯一ID 流星算法

大作业一

黄立

犯“走私罪”的CTO | 法庭上的CTO(19)

赵新龙

CTO 法庭上的CTO

像用户一样测试:打破知识的诅咒

QualityFocus

测试 软件质量 可用性 用户体验

生产环境全链路压测建设历程 21:某快递 A 股上市公司的生产压测案例之基于测试流量的混沌工程(故障演练)

数列科技杨德华

全链路压测 七日更

人工智能不过尔尔,基于Python3深度学习库Keras/TensorFlow打造属于自己的聊天机器人(ChatRobot)

刘悦的技术博客

人工智能 tensorflow chatbot 聊天机器人 keras

直播中不可缺少的一环-rtmp直播推流

anyRTC开发者

音视频 WebRTC CDN RTC RTMP

“有点技术之外,基本什么都没有”的CTO | 法庭上的CTO(15)

赵新龙

CTO 法庭上的CTO

“盗窃”公司源代码被开除的CTO | 法庭上的CTO(20)

赵新龙

CTO 法庭上的CTO

Spring 源码学习 11:invokeBeanFactoryPostProcessors

程序员小航

Java spring 源码 源码阅读

anonymous匿名者场外交易系统APP软件开发

开發I852946OIIO

系统开发

从一个模糊词查询需求的处理方案讨论到一种极速匹配方案的实现

行如风

模糊匹配 双数组trie树 ahocorasick ac自动机 黑名单过滤

SGY奇点交易所系统源码开发

DV:19924636653

软件开发

混合用工、被拖欠工资的 CTO | 法庭上的 CTO(16)

赵新龙

CTO 法庭上的CTO

重学JS | 数组遍历的7种方法及兼容性处理(polyfill)

梁龙先森

前端 编程语言

为什么要TDD(测试驱动开发)

sherlockq

敏捷开发 TDD 极限编程

什么是浮点数?

Kaito

计算机基础 浮点数

英特尔力邀150家产业大咖推动Evo严苛认证,打造PC界的奥斯卡

intel001

微服务架构下如何保证事务的一致性

微服务架构下如何保证事务的一致性

系统迁移基本法-InfoQ