簡介：?社區(qū)評(píng)論系統(tǒng)在完成了基礎(chǔ)功能建設(shè)后，開始逐步將老系統(tǒng)業(yè)務(wù)遷移到新系統(tǒng)，實(shí)現(xiàn)整體架構(gòu)統(tǒng)一、新系統(tǒng)功能賦能老業(yè)務(wù)、節(jié)省系統(tǒng)維護(hù)成本；遷移過程本身雖然枯燥無味，但并不妨礙通用解決方案的沉淀，本文以評(píng)論新老系統(tǒng)遷移為背景，聊聊系統(tǒng)遷移的基本方法，同時(shí)也希望能拋磚引玉，探索更多遷移方案的可能性。

作者|王翔（烈翼）
出品|阿里巴巴新零售淘系技術(shù)部

背景

社區(qū)評(píng)論系統(tǒng)在完成了基礎(chǔ)功能建設(shè)后，開始逐步將老系統(tǒng)業(yè)務(wù)遷移到新系統(tǒng)，實(shí)現(xiàn)整體架構(gòu)統(tǒng)一、新系統(tǒng)功能賦能老業(yè)務(wù)、節(jié)省系統(tǒng)維護(hù)成本；遷移過程本身雖然枯燥無味，但并不妨礙通用解決方案的沉淀，本文以評(píng)論新老系統(tǒng)遷移為背景，聊聊系統(tǒng)遷移的基本方法，同時(shí)也希望能拋磚引玉，探索更多遷移方案的可能性。

系統(tǒng)遷移方案概述

? 主要步驟

就一般的系統(tǒng)而言，主要涉及到以下幾個(gè)步驟，其中，讀寫接口遷移順序可以根據(jù)實(shí)際情況做先后調(diào)整：

基礎(chǔ)數(shù)據(jù)存量/增量遷移
目標(biāo)：老系統(tǒng)存量數(shù)據(jù)遷移到新系統(tǒng)，增量數(shù)據(jù)實(shí)時(shí)同步到新系統(tǒng)

需要解決的主要問題：
1、保證數(shù)據(jù)不丟失，同步后新系統(tǒng)數(shù)據(jù)準(zhǔn)確
2、新老系統(tǒng)id映射：新老系統(tǒng)id體系不同時(shí)，需要做好id映射，比如新db中擴(kuò)展字段存老系統(tǒng)id，同時(shí)將老系統(tǒng)id對(duì)應(yīng)的新系統(tǒng)id存到ldb，方便反查；評(píng)論新系統(tǒng)設(shè)計(jì)之初為了方便老系統(tǒng)遷移，使用了與老系統(tǒng)相同的sequenceId生成體系，因此不需要考慮id映射問題

讀接口遷移：先讀新系統(tǒng)
目標(biāo)：接口層直接查新系統(tǒng)
需要解決的主要問題：新老接口數(shù)據(jù)結(jié)構(gòu)兼容，降低前臺(tái)遷移成本

寫接口遷移
目標(biāo)：新數(shù)據(jù)先寫新系統(tǒng)

需要解決的主要問題：
1、前期需要支持反向同步到老系統(tǒng)（這一步之所以需要雙向同步回老系統(tǒng)，主要是為了兼容老業(yè)務(wù)接口、odps數(shù)據(jù)，很難一步切干凈），需要保證雙向同步時(shí)不出現(xiàn)死循環(huán)
2、老系統(tǒng)各個(gè)寫入口都要做適配路由，這一步改造的工作量比較大，與具體系統(tǒng)特性相關(guān)性比較大，本文不做討論

? 關(guān)鍵階段

相應(yīng)的，系統(tǒng)遷移過程也會(huì)有幾個(gè)關(guān)鍵階段：

階段一：數(shù)據(jù)單向同步階段（老系統(tǒng)->新系統(tǒng)）
階段二：讀/寫接口遷移完成，入口流量先走新系統(tǒng)，增量數(shù)據(jù)先寫入新系統(tǒng)，再同步回老系統(tǒng)（雙向同步階段）
階段三：所有下游業(yè)務(wù)流量、mtop入口流量均遷移到新系統(tǒng)，老系統(tǒng)流量逐步清0直到下線；這一步也是最終完美的狀態(tài)

一般來講，需要平臺(tái)側(cè)做的適配改造全部完成后，即可進(jìn)入階段二，階段三主要依賴逐步推動(dòng)下游業(yè)務(wù)方遷移，平臺(tái)方本身不需要再做額外改動(dòng)，因此本文總結(jié)的方案重點(diǎn)以解決前兩個(gè)階段面臨的問題為主。

此外，根據(jù)不同的系統(tǒng)特性，除了基礎(chǔ)數(shù)據(jù)遷移，可能還會(huì)多一步索引構(gòu)建，比如評(píng)論系統(tǒng)，索引層就是系統(tǒng)很重要的一部分，幾乎支撐了前臺(tái)所有的查詢場(chǎng)景，而索引構(gòu)建策略也會(huì)影響到遷移方案的選型。

評(píng)論系統(tǒng)遷移的幾種方案

? 方案一：依賴精衛(wèi)做數(shù)據(jù)遷移與索引構(gòu)建

數(shù)據(jù)存量遷移/增量同步
1、精衛(wèi)存量/增量任務(wù)
2、精衛(wèi)client/sar包任務(wù)同步創(chuàng)建索引（目前client模式已下線，只能使用sar包方式）

說明：
1、如果系統(tǒng)可以接收一部分增量數(shù)據(jù)不一致，可以先開啟增量任務(wù)，再開啟全量任務(wù)（相同記錄會(huì)覆蓋寫）；如果系統(tǒng)對(duì)一致性要求高，需要使用精衛(wèi)增量任務(wù)的位點(diǎn)回溯功能，保證在全量數(shù)據(jù)遷移期間發(fā)生的所有變更都能同步到新庫，如果全量任務(wù)遷移時(shí)間較長，還需要聯(lián)系精衛(wèi)值班保留更長時(shí)間的位點(diǎn)（線上默認(rèn)位點(diǎn)只保留1天）

2、索引構(gòu)建依賴精衛(wèi)任務(wù)同步完成，整體示意圖如下：

讀接口遷移
由于索引已同步創(chuàng)建，所以可以直接在接口層做讀接口路由遷移

寫接口遷移
1、支持反向同步通道（新系統(tǒng)->老系統(tǒng)）
2、源系統(tǒng)tag防止死循環(huán)
3、寫接口層路由，先寫新系統(tǒng)

說明：通過給先寫入新系統(tǒng)的數(shù)據(jù)打源系統(tǒng)標(biāo)的方式防止雙向同步死循環(huán)（這里也可以使用打鷹眼標(biāo)的方式，但個(gè)人認(rèn)為不如直接存儲(chǔ)源系統(tǒng)標(biāo)更保險(xiǎn)，也容易根據(jù)源數(shù)據(jù)溯源），老系統(tǒng)->新系統(tǒng)的增量通道中通過校驗(yàn)數(shù)據(jù)是否帶新系統(tǒng)標(biāo)，決定處理還是丟棄，寫接口遷移后新老系統(tǒng)雙向同步狀態(tài)示意圖如下：

? 方案二：索引構(gòu)建不依賴精衛(wèi)

數(shù)據(jù)存量遷移/增量同步
1、精衛(wèi)存量/增量任務(wù)

說明：存量/增量數(shù)據(jù)方案與方案一相同

寫接口遷移
（雙向同步階段）
1、反向同步通道（保證數(shù)據(jù)能回流到老系統(tǒng)，兼容老業(yè)務(wù)） 新->老
2、源系統(tǒng)tag（保證雙向同步時(shí)不出現(xiàn)循環(huán)）
3、寫接口路由開啟（從先寫老庫切換為先寫新庫）

說明：讀接口切換前需要先完成索引重建，索引重建包括增量/存量兩部分，增量部分依賴系統(tǒng)異步消費(fèi)評(píng)論寫接口成功后發(fā)的metaq消息完成，因此需要先對(duì)寫接口做遷移，保證增量數(shù)據(jù)能進(jìn)索引：

其他步驟與方案一相同

存量數(shù)據(jù)索引構(gòu)建
1、dts 任務(wù)讀取存量離線表，完成存量數(shù)據(jù)新索引構(gòu)建，這里可以使用多機(jī)并發(fā)任務(wù)。
說明：增量數(shù)據(jù)索引構(gòu)建依賴寫接口切換，存量數(shù)據(jù)的索引構(gòu)建則需要專門寫任務(wù)讀離線表完成。

讀接口遷移
1、索引存量/增量數(shù)據(jù)構(gòu)建完成后，可以開啟讀接口切換

? 方案三：完全不依賴精衛(wèi)

數(shù)據(jù)存量遷移/增量同步
1、dts 任務(wù)讀取存量離線表，接口方式遷移存量數(shù)據(jù)
2、增量同步依賴接口層雙寫

說明：精衛(wèi)方案一般適用于新老系統(tǒng)存儲(chǔ)都使用mysql的場(chǎng)景，當(dāng)存儲(chǔ)方案不一致時(shí)，只能通過寫dts遷移任務(wù)的方式完成存量數(shù)據(jù)遷移，由于是走接口層寫入數(shù)據(jù)，所以metaq方式構(gòu)建的索引可以同步完成重建。

讀接口遷移
1、第一步會(huì)同步完成索引構(gòu)建，因此可以先遷讀接口

寫接口遷移
1、反向同步通道
2、寫接口路由開啟，路由開啟后，接口層雙寫自動(dòng)關(guān)閉，數(shù)據(jù)開始 先寫新系統(tǒng)->再回流老系統(tǒng)

說明：這里不存在雙向同步的問題，老系統(tǒng)->新系統(tǒng)的同步鏈路在接口層雙寫，寫接口路由開啟后，在先寫新系統(tǒng)的同時(shí)，雙寫邏輯就會(huì)關(guān)閉，只需要構(gòu)建反向通道將數(shù)據(jù)同步回老系統(tǒng)即可

總結(jié)

3套方案分別解決不同場(chǎng)景的問題，各有優(yōu)劣，有以下幾點(diǎn)可以作為方案選型的判斷依據(jù)：

1、基礎(chǔ)數(shù)據(jù)遷移：新老系統(tǒng)都使用mysql存儲(chǔ)時(shí)，盡量采用精衛(wèi)做全量/增量遷移，精衛(wèi)本身作為一款專業(yè)的數(shù)據(jù)同步工具，功能全面，可以最大程度保障數(shù)據(jù)遷移后的一致性和準(zhǔn)確性，同時(shí)還可以利用精衛(wèi)控制臺(tái)隨時(shí)調(diào)整遷移速度，保障遷移過程的穩(wěn)定性。
2、讀寫接口遷移順序：依據(jù)索引構(gòu)建的具體方案決定讀寫遷移的先后，讀接口遷移強(qiáng)依賴索引構(gòu)建完成：

方案一的優(yōu)點(diǎn)：基礎(chǔ)數(shù)據(jù)與索引可以同步完成遷移，先切讀接口也比先切寫接口風(fēng)險(xiǎn)較低。

方案二的優(yōu)點(diǎn)：雖然不依賴精衛(wèi)構(gòu)建索引使得需要專門寫任務(wù)重建索引，但不依賴精衛(wèi)的索引構(gòu)建方案在實(shí)際工程中更方便邏輯修改與迭代，精衛(wèi)依賴binlog的方式原生決定了預(yù)發(fā)的不可測(cè)試性，不方便功能的快速迭代和穩(wěn)定上線。

One More Thing

我們是淘寶內(nèi)容社交互動(dòng)團(tuán)隊(duì)，主要承載了用戶從“買在淘寶”到“消費(fèi)生活在淘寶”的重要體驗(yàn)升級(jí)，基于新的產(chǎn)品模式和運(yùn)營模式，通過內(nèi)容化，游戲化和社交社區(qū)化推動(dòng)用戶在淘寶內(nèi)的活躍。伴隨著廣闊的業(yè)務(wù)空間機(jī)會(huì)之下的是有足夠挑戰(zhàn)性的技術(shù)場(chǎng)景: 我們有百億級(jí)的用戶關(guān)系和用戶互動(dòng)數(shù)據(jù)資產(chǎn)有待發(fā)掘，百萬QPS的大流量高可用強(qiáng)一致性多租戶技術(shù)場(chǎng)景，覆蓋從工程開發(fā)，推薦算法，大數(shù)據(jù)分析平臺(tái)等，提供了職業(yè)生涯增長空間和多樣的崗位選擇：數(shù)據(jù)化驅(qū)動(dòng)運(yùn)營，大容量高并發(fā)系統(tǒng)，推薦搜索服務(wù)平臺(tái)，深度學(xué)習(xí)的工程體系等等
請(qǐng)投遞簡歷至郵箱：zizhan.xb@taobao.com

總結(jié)

以上是生活随笔為你收集整理的还在为系统迁移烦恼？掌握这些“基本法”解锁更多可能的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。