简介: 社区评论系统在完成了基础功能建设后,开始逐步将老系统业务迁移到新系统,实现整体架构统一、新系统功能赋能老业务、节省系统维护成本;迁移过程本身虽然枯燥无味,但并不妨碍通用解决方案的沉淀,本文以评论新老系统迁移为背景,聊聊系统迁移的基本方法,同时也希望能抛砖引玉,探索更多迁移方案的可能性。
作者|王翔(烈翼)
出品|阿里巴巴新零售淘系技术部
背景
社区评论系统在完成了基础功能建设后,开始逐步将老系统业务迁移到新系统,实现整体架构统一、新系统功能赋能老业务、节省系统维护成本;迁移过程本身虽然枯燥无味,但并不妨碍通用解决方案的沉淀,本文以评论新老系统迁移为背景,聊聊系统迁移的基本方法,同时也希望能抛砖引玉,探索更多迁移方案的可能性。
系统迁移方案概述
▐ 主要步骤
就一般的系统而言,主要涉及到以下几个步骤,其中,读写接口迁移顺序可以根据实际情况做先后调整:
基础数据存量/增量迁移
目标:老系统存量数据迁移到新系统,增量数据实时同步到新系统
需要解决的主要问题:
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的大流量高可用强一致性多租户技术场景,覆盖从工程开发,推荐算法,大数据分析平台等,提供了职业生涯增长空间和多样的岗位选择:数据化驱动运营,大容量高并发系统,推荐搜索服务平台,深度学习的工程体系等等
请投递简历至邮箱:zizhan.xb@taobao.com