非常幸運，這幾年系統遷移的事情基本被我趕上了，從外部系統遷移到內部系統遷移，從小項目到大項目都實踐過。遷移中踩過的坑和自我的總結，在這裏給大家分享分享。
隨着業務的發展，原有系統支撐當前業務就顯得力不從心了，這時就考慮進行系統拆分或者內部升級了，拆分成另外一個微服務或者內部模型升級，這裏將拆分的過程或者升級的過程統稱爲遷移，那麼新老系統業務過度期間如何保證系統平穩的對接呢？
根據數據特點遷移可分爲兩種，數據遷移和系統遷移
數據遷移
數據遷移適用於系統間的變動只需要通過數據的遷移就可以解決的場景，比如分庫分表的時候數據遷移，在遷移過程中可以通過遷移前後的數據對比來保證數據的完整性，如遷移的時候分批處理，每一批數據遷移完成後進行總量的對比，保證數據完整遷移過去。
數據遷移數據屬於比較簡單的遷移方式，通常由DBA進行，開發投入量不大。
系統遷移
這種情況就得根據業務情況來分析了，一個系統的業務可以有多複雜就有多複雜，需要花費大量的時間保障遷移的正確與完整性。
根據系統拆分的方式和遷移的方向，系統遷移又可以細分成外部系統遷移和系統內部遷移，無論是內部遷移還是外部遷移，總體流程基本一致。
遷移考慮點
在初始業務情況下，多個領域功能業務都冗餘在一個系統中，如果需要對某個領域模塊遷出形成新的一個系統服務，這種可以稱爲新增系統遷移，那麼如何保證系統的平穩遷移呢？遷移都可以從以下幾個點考慮
- 新系統的穩定性
這個得要根據公司的具體基礎組件功能來說了，如果是公司有成熟的服務組件，新增系統只是簡單的一個容器的部署的話，這個問題的優先度可以放到最低考慮。如果沒有成熟的組件，新系統意味着重新搭建一套服務體系，那麼這時系統的穩定性就得優先考慮了。如何保證系統不掛掉？如何保證就算系統掛掉一部分也不影響整體業務？如何快速止損？這些問題就顯得尤爲重要，得要優先考慮了。
- 業務重要性
這是一個很現實的問題，如果一個業務的重要程度不高，或者出問題基本沒什麼影響，那麼這個業務遷移的時候可以放心大膽的遷，否則都要非常小心的處理系統遷移過程
- 灰度
系統遷移過程中，如何進行灰度驗證呢？一開始總不可能把所有的量都放開，都是從小量到大量的處理，灰度可以有助於提前發現問題
- 限流
根據業務規則進行速度限制，大量的請求瞬間過來對業務的影響是非常大的，這裏可以使用令牌桶的方式進行限速。限速的過程會調整非常頻繁，這裏就需要使用的到分佈式配置了。如果系統中沒有這類組件，可以通過DB或者緩存的方式調整速率。
- 降級
這個和限流有着類似的情況，設計的時候需要考慮如何對此功能進行降級，如新增的系統有問題，僅僅通過限速是不能解決問題的，還需要降級的方案。
當新系統穩定性無法保證的時候，對遷移的業務可以添加一個兜底的邏輯，不對原有的業務進行修改，如果新系統處理失敗則進行原有邏輯執行
- 監控
這個就不必多說了把，要掌控系統的穩定性，必須要有對應的監控，否則就成了瞎子一樣，生產事故只能通過用戶反饋。
監控還可以通過T+H離線DB數據比對，和實時數據比對，比如數據發生變動後，覈對平臺通過監聽DB數據變動從而進行業務邏輯比對，從而達到數據實時比對功能。
- 告警
有了監控以後，當然需要配備對於的告警，否則監控做的再好放在那裏沒人看也起不到對應的作用，配合告警可以發揮出非常好的效果，不過這裏得注意告警的配置，主要是告警的級別和次數，如果告警的東西多了，容易產生告警疲勞，當真正有事故發生的時候告警卻被忽略過去。
- 回滾
遷移系統設計的時候就需要考慮好正向和逆向流程，沒有回滾方案的遷移都是耍流氓，如果出了問題，不能回滾，對於數據量大的情況下，數據處理幾乎是一場災難
- 流量回放/流量對比
新系統遷移完成後，那麼在測試階段如何快速發現問題？ 可以將歷史訪問流量進行回放，比如查詢類的接口數據，模擬線上的訪問，流量回放成功後那麼流量對比就排上用場了，流量回放僅僅能解決業務數據的問題，但是最終結果的準確性則需要流量對比進行處理了，可以根據返回的數據進行對比，對比的時候需要主要返回業務的順序，比如有些業務就是根據服務接口返回的數據進行展示，那麼數據的顯示順序就顯得尤爲重要，對比的時候千萬不能忽略。
系統遷移
系統內部遷移
內部遷移的情況往往是爲了償還技術債務，還有一部分情況是業務需求的變更，原有的模型已經不能滿足現有的需求，但是遷移到新業務邏輯後還有一大批歷史數據要處理，無法單純的通過DB的數據變動達到遷移的效果，那麼則需要進行內部遷移，內部遷移建議通過構造現有的接口數據進行業務處理。因爲是內部系統遷移，不能對外部系統產生其他影響，簡單的說就是其他系統是無感知的。
那麼如何保證遷移過程順利完成，遷移如何保證數據一致性？如何遷移？遷移的節奏？
鏡像遷移
根據現數據將數據遷移到系統中，對請求流量進行復制，這樣可以通過對比新老數據以及業務進行測試，但是這樣成本高，而且得要把控好整個系統流程纔可以，否則會出現消息重複發送，數據重複處理等問題。這種遷移方式適合那種查詢爲主的系統，而且對外處理流程較少，可以比較好控制。
預遷移
當鏡像遷移不能滿足時，我們可以通過預遷移的方式進行處理。
預遷移顧名思義就是在遷移前進行模擬遷移操作，比如可以把數據遷移到專門用來遷移的租戶下面，並做好映射關係，查詢老數據的時候異步進行新鏈路查詢，然後對比返回的數據，從而達到提前驗證的目的。
不過預遷移中需要特別注意數據同步，比如老數據修改了，需要實時同步到用來遷移的租戶，而且得要更新好數據映射關係。
在查詢老數據的接口上，進行流量複製並做轉換成用來遷移的租戶的請求數據，將返回的數據通過映射關係一一進行比對，這裏比對可以使用反射或者json的方式進行對比，輸出比對不一致的信息並告警。這裏要特別注意下，所有流程必須要可控的。比如可以屏蔽某些數據不進行對比，某些意料中的對比失敗數據可以忽略。需要做到這一點分佈式配置中心就非常有必要了，如果當前系統還沒有此功能，那麼可以使用db或者緩存都可以，只要能達到實時變更配置數據都可以。
同鏡像遷移類似，不過這裏不需要新增一個系統，而是在原有系統中進行數據預遷移，不過這裏是將業務邏輯模擬遷移過程，比如可以將數據遷移到新的租戶下面，從而達到數據的隔離。
預遷移還有數據集的問題，在數據量大的時候，將數據遷移到專門用來遷移的租戶下面可能系統無法支撐這麼大的數據讀取或操作，這時候需要提供多個遷移租戶用來承載這些數據，當然如果系統可以做到一對一映射這是再好不過了。
預遷移的處理流程：
這裏需要同遷移流程一樣，允許有部分流程不一致，但是核心流程必須一致，否則預遷移工作做得再好，數據驗證再完美也無法保證遷移的正確性。
預遷移持續的時間：
這個需要根據業務週期來定奪了，在預遷移過程中可以非常好的遷移過程中可能的問題，觀察時間可以根據業務特點來，最好的方式是將一個業務的所有生命週期都走過一遍，然後前期檢查好預遷移的數據情況，這樣遷移基本十拿九穩了。
遷移
前面做了那麼多工作，就是爲了遷移這一步，完成遷移纔是本質目的，在預遷移經過一段時間的驗證後，可以開始少量的遷移工作，遷移的時候需要注意：
1 少量驗證：一開始的時候需要非常小心，最好都是人工處理，每一步都進行數據驗證，在遷移的時候如果有涉及到其他系統，還需要提前打好招呼，萬一遷移有問題無法回滾，還需要地層幫助，臨時找人可不是一個明智的決定。驗證的過程中需要把所有核心流程都走一遍，比如訂單相關的需要驗證訂單的正向流程，還要驗證訂單的逆向流程，還有金額數據等等，這些根據具體業務來定，核心思想就是正向，逆向流程必須要走通。
2 分批遷移：經過少量驗證後，基本流程已經沒問題了，這時候可以開始批量處理了，這裏批量還是推薦分批較少數據。批量遷移開始的時候人工處理就顯得力不從心了，自動化驗證和核對這時就派上用場了，自動化驗證可以通過查詢核心接口，對比遷移前和遷移後的數據，在遷移前將數據採集下來保存，遷移完成後進行流量回放，流量回放可是一個技術活，如果系統接口沒有時效性，那麼可以直接將以前採集的數據進行回放。如果數據具有時效性，比如當前查詢和一小時後查詢的結果是不一樣的，跟時間有相關性，那麼這種數據採集就需要在遷移前實時處理了。
分批遷移的時候最好根據業務特點進行分塊處理，比如數據跟地域相關的在遷移前優先遷移方便處理的地域數據，需要先聯繫好地域負責人。某一個地域遷移成功後可以逐步往其他地域遷移，一個重要點就是如果數據處理你不能百分百操作，那麼一定要先聯繫好其他模塊負責人！
3 大批量遷移：經過分批遷移後基本驗證數據遷移的正確性，這時候可以開始大批量進行遷移了，這裏推薦遷移的時候優先處理生效數據，有些數據沒有生效，但是也需要遷移，這些可以放在後面進行，保證主體核心鏈路遷移完成
回滾
沒有回滾方案的遷移都是耍流氓，如果遷移後發現數據問題無法處理的時候，這時候就需要回滾了，這裏得要說明一個原則，回滾是不得已的辦法，只有在其他方法都無法處理的時候才進行回滾。
回滾可不是一個簡單的活兒，有一個非常重要的點，如何保證回滾後的數據和之前數據的一致性？數據覈對如何處理？
這時數據備份就顯得非常重要了，可以將新產生的數據全部刪除，然後通過備份數據的id將歷史數據恢復。
以上說的都是正常的回滾，沒有增量數據的情況。如果遷移後數據有變動了，這時候回滾就得要根據最新的數據進行回滾，那麼逆向流程的驗證就非常重要了，如何保證數據的一致性，這個就和遷移的過程一樣重要。
還有一種就是無法進行回滾，遷移後數據改變了，沒法通過最新的數據映射到老數據，或者成本太高，那麼有損回滾可以考慮下，通過還原備份的數據，在將新數據鏈路上做的操作在老鏈路上再做一次，保證數據的一致性。
遷移的感想
- 過程完全沒有想象的那麼簡單
- 注意環境隔離，比如預發環境和線上環境數據問題，本來在預發的數據在線上執行是否會有其他問題，如果有需要控制好環境數據
- 數據重複遷移，在設計的時候需要考慮好是否可以重複遷移，比如系統以來其他系統，如果有任何一步失敗了這時候是否允許通過再次遷移的方式來繼續遷移。如果允許重複遷移，那麼數據控制就得要非常細心了，比如數據已經發生了變化，再次遷移的話可能會導致數據被覆蓋
- 完善工具：處理的時候最好是通過工具進行處理，比如提供一個h5頁面進行操作，遷移的時候都是非常小心而且緊張的，越是傻瓜式的工具越能提供更好的保障
- 覈對：可以通過遷移後新老數據進行覈對，保證遷移後數據的正確性