簡介：?社區評論系統在完成了基礎功能建設后，開始逐步將老系統業務遷移到新系統，實現整體架構統一、新系統功能賦能老業務、節省系統維護成本；遷移過程本身雖然枯燥無味，但并不妨礙通用解決方案的沉淀，本文以評論新老系統遷移為背景，聊聊系統遷移的基本方法，同時也希望能拋磚引玉，探索更多遷移方案的可能性。

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

背景

社區評論系統在完成了基礎功能建設后，開始逐步將老系統業務遷移到新系統，實現整體架構統一、新系統功能賦能老業務、節省系統維護成本；遷移過程本身雖然枯燥無味，但并不妨礙通用解決方案的沉淀，本文以評論新老系統遷移為背景，聊聊系統遷移的基本方法，同時也希望能拋磚引玉，探索更多遷移方案的可能性。

系統遷移方案概述

? 主要步驟

就一般的系統而言，主要涉及到以下幾個步驟，其中，讀寫接口遷移順序可以根據實際情況做先后調整：

基礎數據存量/增量遷移
目標：老系統存量數據遷移到新系統，增量數據實時同步到新系統

需要解決的主要問題：
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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。