簡介： 社區評論系統在完成了基礎功能建設後，開始逐步將老系統業務遷移到新系統，實現整體架構統一、新系統功能賦能老業務、節省系統維護成本；遷移過程本身雖然枯燥無味，但並不妨礙通用解決方案的沉澱，本文以評論新老系統遷移爲背景，聊聊系統遷移的基本方法，同時也希望能拋磚引玉，探索更多遷移方案的可能性。
作者|王翔（烈翼）
出品|阿里巴巴新零售淘系技術部
背景
社區評論系統在完成了基礎功能建設後，開始逐步將老系統業務遷移到新系統，實現整體架構統一、新系統功能賦能老業務、節省系統維護成本；遷移過程本身雖然枯燥無味，但並不妨礙通用解決方案的沉澱，本文以評論新老系統遷移爲背景，聊聊系統遷移的基本方法，同時也希望能拋磚引玉，探索更多遷移方案的可能性。
系統遷移方案概述
▐ 主要步驟
就一般的系統而言，主要涉及到以下幾個步驟，其中，讀寫接口遷移順序可以根據實際情況做先後調整：
基礎數據存量/增量遷移
目標：老系統存量數據遷移到新系統，增量數據實時同步到新系統
需要解決的主要問題：
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的方式原生決定了預發的不可測試性，不方便功能的快速迭代和穩定上線。
————————————————
版權聲明：本文爲CSDN博主「阿里技術官方號」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/alitech2017/article/details/106339246