雲栖号資訊：【 點選檢視更多行業資訊】
在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
背景
社群評論系統在完成了基礎功能建設後，開始逐漸将老系統業務遷移到新系統，實作整體架構統一、新系統功能賦能老業務、節省系統維護成本；遷移過程本身雖然枯燥無味，但并不妨礙通用解決方案的沉澱，本文以評論新老系統遷移為背景，聊聊系統遷移的基本方法，同時也希望能抛磚引玉，探索更多遷移方案的可能性。
系統遷移方案概述
主要步驟
就一般的系統而言，主要涉及到以下幾個步驟，其中，讀寫接口遷移順序可以根據實際情況做先後調整：
基礎資料存量 / 增量遷移
目标：老系統存量資料遷移到新系統，增量資料實時同步到新系統
需要解決的主要問題：
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、 反向同步通道（保證資料能回流到老系統，相容老業務） 新 -> 老
2、 源系統 tag（保證雙向同步時不出現循環）
3、 寫接口路由開啟（從先寫老庫切換為先寫新庫）
說明：讀接口切換前需要先完成索引重建，索引重建包括增量 / 存量兩部分，增量部分依賴系統異步消費評論寫接口成功後發的 metaq 消息完成，是以需要先對寫接口做遷移，保證增量資料能進索引：
其他步驟與方案一相同
存量資料索引建構
1、 dts 任務讀取存量離線表，完成存量資料新索引建構，這裡可以使用多機并發任務。
說明：增量資料索引建構依賴寫接口切換，存量資料的索引建構則需要專門寫任務讀離線表完成。
1、 索引存量 / 增量資料建構完成後，可以開啟讀接口切換
方案三：完全不依賴精衛
1、 dts 任務讀取存量離線表，接口方式遷移存量資料
2、 增量同步依賴接口層雙寫
說明：精衛方案一般适用于新老系統存儲都使用 mysql 的場景，當存儲方案不一緻時，隻能通過寫 dts 遷移任務的方式完成存量資料遷移，由于是走接口層寫入資料，是以 metaq 方式建構的索引可以同步完成重建。
1、 第一步會同步完成索引建構，是以可以先遷讀接口
1、 反向同步通道
2、 寫接口路由開啟，路由開啟後，接口層雙寫自動關閉，資料開始 先寫新系統 -> 再回流老系統
說明：這裡不存在雙向同步的問題，老系統 -> 新系統的同步鍊路在接口層雙寫，寫接口路由開啟後，在先寫新系統的同時，雙寫邏輯就會關閉，隻需要建構反向通道将資料同步回老系統即可
總結
3 套方案分别解決不同場景的問題，各有優劣，有以下幾點可以作為方案選型的判斷依據：
1、基礎資料遷移： 新老系統都使用 mysql 存儲時，盡量采用精衛做全量 / 增量遷移，精衛本身作為一款專業的資料同步工具，功能全面，可以最大程度保障資料遷移後的一緻性和準确性，同時還可以利用精衛控制台随時調整遷移速度，保障遷移過程的穩定性。
2、讀寫接口遷移順序： 依據索引建構的具體方案決定讀寫遷移的先後，讀接口遷移強依賴索引建構完成：
方案一的優點： 基礎資料與索引可以同步完成遷移，先切讀接口也比先切寫接口風險較低。
方案二的優點： 雖然不依賴精衛建構索引使得需要專門寫任務重建索引，但不依賴精衛的索引建構方案在實際工程中更友善邏輯修改與疊代，精衛依賴 binlog 的方式原生決定了預發的不可測試性，不友善功能的快速疊代和穩定上線。
【雲栖号線上課堂】每天都有産品技術專家分享！
課程位址：
https://yqh.aliyun.com/zhibo立即加入社群，與專家面對面，及時了解課程最新動态！
【雲栖号線上課堂 社群】
https://c.tb.cn/F3.Z8gvnK
原文釋出時間：2020-06-01
本文作者： 王翔（烈翼）
本文來自：“
InfoQ”，了解相關資訊可以關注“
”