互聯網金融行業發生了翻天覆地的變化，相對應的金融科技也在不斷的更新和迭代，每次有新的軟件系統出爐的時候，就是老的軟件系統命運終結的開始，老的項目當然不會束手就擒，它也會做最後的掙扎，當你從它身上遷移用戶或者商戶的時候，它會給你帶來很多麻煩，比如說，它會臨時罷工、出現資金損失等等不可忽視的問題，因此，遷移是個大任務，有的時候遷移並不亞於開發一套新系統的難度，甚至可以說是有過之而無不及。
哪些場景需要遷移
我們總結了各種需要遷移的場景。
字段遷移
原來設計的字段大小不能滿足現在業務的需求，直接在原表上擴容字段可能會影響線上跑的業務，因此，我們需要增加一個字段來替換原來的字段；字段的數據格式需要升級，通過新增字段來替換原有字段，例如：原有未加密的字段處於安全需求進行加密。
表遷移
用於數據庫表設計重構的場景，原有表的結構不合理，新增合理的表來替換原有的表，這時候我們需要表遷移。
數據庫遷移
把單庫遷移到分庫分表的多個庫；從一種數據庫遷移到另外一種數據庫；分庫分表的多個庫需要擴容的時候，需要進行數據庫遷移，遷移到一套能夠容納足夠數據的數據庫集羣。
數據庫遷移到其他類型的庫
對數據庫的選型發生了變化，例如：微博的粉絲庫從原有的 MySQL 遷移到 HBase。
系統遷移
原有系統的技術已經過時了，不能滿足新需求或者業務發展的需要，開發完成新系統來替換原有系統。
通用的遷移方法論
通用的遷移方法分爲平滑遷移和停機遷移，平滑遷移一般採用雙寫的方案，不需要停機就可以完成遷移，類似飛機的空中加油，或者給運行的汽車換輪子。而停機遷移，則需要停止現有的業務服務，然後遷移數據，待數據遷移之後，再開啓對外提供服務。
這裏講解的方法論是一種通用的遷移方案，既適合字段遷移、表遷移，也適合庫遷移以及應用遷移，既適合數據庫的遷移也適合緩存的遷移，雖然在細節上有些不同，但是在方法論上則大同小異，我們以分片後的數據容量不能滿足需求，需要對分片後的數據擴容爲例，這裏的擴容實際上是遷移的一種特殊案例，我們以擴容爲例來說明相應的步驟和實現細節。
平滑遷移
平滑遷移適合對可用性要求較高的場景，例如，線上的交易服務對緩存或者數據庫依賴較大，不能忍受停機帶來的業務損失，也沒有交易的低峯期，我們對此只能採用平滑遷移的方式。
平滑遷移，是指將正在提供線上服務的數據，從一個地方數據存儲到另一個數據存儲，整個遷移過程中要求不停機，服務不受影響。根據數據所處層次，可以分爲緩存遷移、數據庫存儲遷移、應用遷移等等；根據數據遷移前後的變化，又可以分爲數據平移和數據轉移。數據庫對數據庫的遷移屬於平移，數據庫對其他 NoSQL 庫的遷移屬於數據轉移。
數據平移是指遷移前後數據組織形式不變，比如 MySQL 數據庫從1個實例擴展爲4個實例，Redis 緩存從2個實例擴展到8個實例等等。
如果在最初的設計裏就爲以後的擴容做好準備，也就是做了充分的容量評估（關於容量評估，請參考《分佈式服務架構：原理、設計與實戰》一書中第3章的內容），那麼數據遷移工作就會簡單很多，比如 MySQL 已經做了分庫分表，擴展實例的時候，只需要多做幾個從庫，切換訪問關係，最後將冗餘的庫表刪除即可達到擴容的效果，當然，這需要短暫的停止服務。
近年來出現很多支持自動可伸縮的數據庫，在實現上已經做到全自動數據遷移，如 HBase、TiDB 等，那就更簡單了，只要通過管理功能來添加機器，手工修改配置或者系統自動發現，就可完成數據庫容，也就免去了複雜的數據遷移等工作。
數據轉移是指在數據遷移前後，數據組織形式發生了變化。比如將 MySQL 數據庫遷移到 HBase 數據庫，微博就經歷過這樣的過程。
平滑遷移通常使用的是雙寫方案，方案分成4個步驟：雙寫、遷移歷史數據、切讀、下雙寫。
這種方式如果應用於緩存擴容的遷移場景，則還有一個變種，就是不需要遷移舊數據，在第1步中雙寫後，在一定的時間裏通過新規則對新緩存進行寫入，新緩存已經有了足夠的數據，這樣我們就不用再遷移舊數據，直接進入第3步即可。
首先，假設我們的應用現在使用了具有兩個分片的數據集羣，通過關鍵字哈希的方式進行路由，如下圖所示。
因爲兩個分片已經不能滿足容量的需求，所以現在需要擴容到4個分片，達到原來兩倍的總大小，因此我們需要遷移。
遷移的具體過程如下。
（1）雙寫
按照新規則和舊規則同時往新舊數據系統中寫數據，如下圖所示。
這裏，我們仍然按照舊的規則，也就是關鍵字哈希除以2取餘來路由分片，同時按照新的規則，也就是關鍵字哈希除以4取餘來路由到新的4個分片上，來完成數據的雙寫。
這個步驟有優化的空間，因爲是在成倍擴容，其實，我們不需要準備4個全新的分片，對於新規則中的前兩個分片的數據，其實是舊規則中的兩個分片數據的子集，並且規則一致，所以我們可以重用前兩個分片，也就是一共需要兩個新的分片，用來處理關鍵字哈希取餘後爲2和3的情況，使用舊的數據分片來處理關鍵字哈希取餘後0和1的情況即可。如下圖所示。
（2）遷移歷史數據
把舊緩存集羣中的歷史數據讀取出來，按照新的規則寫到新的數據集羣中，如下圖所示。
在這個過程中，我們需要遷移歷史數據，在遷移的過程中可能需要遷移工具，這也需要一部分開發工作量。在遷移後，我們還需要對遷移的數據進行驗證，表明我們的數據遷移成功。
在某些應用場景下，例如緩存數據，並不是應用強依賴的，在緩存裏獲取不到數據，可以回源到數據庫獲取，因此在這種場景下通過容量評估，數據庫可以承受回源導致的壓力增加，就可以避免遷移舊數據。
在另一種場景下，數據一般是具有時效性的，應用在雙寫期間不斷向新的集羣中寫入新數據，歷史數據會逐漸過時，並被從舊的集羣中刪除，在一定的時間流逝後，新的集羣中自然就有了最新的數據，就不再需要遷移歷史數據了，但是這需要進行評估和驗證。
（3）切讀
把應用層所有的讀操作路由到新的數據集羣上，如下圖所示。
在這一步驟裏，把應用中讀取的操作的數據源轉換成新的數據集羣，這時應用的讀寫操作已經完全發生在新的數據庫集羣上了。這一步一般不需要上線代碼，我們會在一開始上雙寫時就實現開關邏輯，這裏只需要將讀的開關切換到新的集羣即可。
（4）下線雙寫
在這一步，我們把寫入舊的集羣的邏輯下線，如下圖所示。
這一步通常是在雙寫和切讀後驗證沒有任何問題，並保證數據一致性的情況下，才把這部分代碼下線。同時可以把舊的分片下線，如果是擴容的場景，並且重用了舊的分片1和分片2，則還可以清理分片1和分片2中的冗餘數據。
對於字段遷移來講，我們除了新增字段，雙寫後替換原來字段，我們還可以採用原地替換的方法，對於新數據加密，加密後做標誌，然後異步的將歷史數據加密，讓查詢程序兼容加密的數據和非加密的數據。
可以用“軟着陸”來形容雙寫遷移方案，這和新領導上任後，一般先招心腹，慢慢的替代老下屬的職責，慢慢淘汰老下屬，慢慢實現軟着陸如出一轍。
停機遷移
停機遷移的方法比較簡單，通常分爲停止應用、遷移舊數據、更改數據源文件、啓動應用這4個步驟，如下圖所示。
具體的遷移步驟如下。
-
停機應用，先將應用停止服務。
-
遷移歷史數據，按照新的規則把歷史數據遷移到新的緩存集羣中。
-
更改應用配置，指向新的緩存集羣。
-
重新啓動應用。
這種方式的好處是實現比較簡單、高效，能夠有效避免數據的不一致，但是需要由業務方評估影響，一般在晚上交易量比較小或者非核心服務的場景下比較適用。
如何驗證遷移成功？
遷移過程中最重要的一環就是如何驗證遷移方案是成功的，我曾經給小夥伴們定了一個順口溜。
要明確什麼樣角色的什麼人在什麼時候到什麼系統看到什麼樣的數據，才能確認遷移成功。
雖然這是看似簡單的一句話，但是信息量滿滿的，有了這句話作爲指導，能夠確保遷移方案的方向一定是正確的，一定不會導致太大的問題。
這句話具體包括幾個要素：誰、什麼時候、什麼樣的數據，這些必須在遷移方案中都要事先明確，具體執行的人必須瞭解清楚這些條款，假設我們在遷移支付行業中的計費模板，那麼遷移切量後，我們就需要計費的運營在切量後的第一時間到計費系統中查看計費的準確性，並且明確什麼樣的計費結果是準確的，什麼樣的計費結果是不準確的。
有的時候只靠人來確定數據是否正確恐怕還不夠，我們通常需要工具自動化的進行比對，同樣我們以計費模板遷移爲例，我們從一套計費模板遷移到另外一套計費模板中，通常在初期我們不會真正的以新模板爲準，我們會在程序中實現“雙計”，既使用老的計費模板計費，也使用新的計費模板計費，在初期我們以老的計費模板爲準，新的計費模板計費的結果只用於比對，並且計入日誌，這樣通過程序自動比對一段時間以後，發現新的計費模板確實沒有問題，我們才真的開啓開關，以新的計費模板爲準。
當然，有的時候數據量巨大，我們比對每一個流量產生的數據不太現實，也會嚴重影響性能，這個時候我們需要對數據比對進行抽樣，只對一些比較有代表性的數據進行比對。
系統遷移後數據清洗？
系統遷移過程中，上了雙寫以後，歷史數據仍然保留在老系統，因此，我們需要將歷史數據遷移到新系統，因爲，有些時候我們需要讀取或者修改歷史數據，例如支付行業的退款等。
我們把遷移歷史數據的過程稱爲洗數據，通常使用如下的步驟來實現。
-
先清洗歷史數據，將清洗後的數據寫入新系統。
-
做全量對比，如果數據太多，沒法全量對比，就抽樣對比，看看有沒有不一致的數據。
-
在數據量巨大的情況下，線上系統複雜，出現少量的不一致是正常的，這時候不一致的數據進行分析，這時候可能需要參考線上服務系統的交易日誌，查明造成不一致的原因，並進行修復。
這裏，有讀者會對上面第2步有疑問，爲什麼會產生不一致的數據呢，這有很多原因。下面我們來仔細分析。
對於增加記錄，到遷移歷史數據這一階段，我們使用的是雙寫，因此，數據在新老數據庫中都會存在，即使雙寫有問題，導致一方不存在，我們也可以通過比對來補齊。
對於更新數據，則容易產生不一致，導致新老數據庫的數據不一致，假設在遷移某條歷史數據的過程中，線上的交易系統正好修改了這條數據，在雙寫系統還沒有更新歷史數據的時候，遷移工具已經把這條數據拿到了應用系統中，這時數據在新老庫中都更新了，但是遷移工具後續又把老版本的這條數據更新到新系統中，就導致數據不一致。
對於刪除數據，和上面更新數據有一樣的問題，也會導致不一致的問題，這時候以誰爲準，怎麼保證一致性是個難題，我們需要藉助修改的 timestamp 或者版本來區分哪一個是最新的版本，然後對數據進行修復。還有另外一個更好的方法，對於某些業務，數據是有一定時效性的，超過一定時間的數據就不再更改，因此，我們可以讓雙寫的時間拉長，要長於數據更新的時間段，這樣在歷史數據完全不被更新的時候，我們再進行洗數據，就不會因爲遷移而產生不一致了。
遷移失敗怎麼辦？
這裏探討，遷移失敗了，遷移後驗證遷移有問題了，怎麼辦？其實，遷移失敗了沒有什麼好的辦法，只有兩個途徑可以走，一個就是遷移失敗了就在新系統中修復，但是有些時候這可能會導致更多不可用時間，另外一個方案就是遷移失敗了，需要遷移回來，但是遷移回來遷移過程中產生的數據怎麼辦？
這是唯一能用的兩個辦法，沒有更好的辦法能解決遷移失敗的問題，因此，在這個問題上我們不能奢求完美的解決方案，我們只能退而求其次，提前做好應對方案。
如果我們決定了遷移失敗了就在新系統中修復，而不再切回老的系統，我們就要充分的做好應急方案，一旦這種事情出現了，我們要預測可能產生的問題，針對問題做相應的解決方案，甚至我們提前做好工具，在問題出現的時候，我們要快速發現和快速恢復。
如果我們決定了遷移失敗後要遷移回來老系統，我們也要提前做好應急方案，應急方案中要包含如何發現問題，如何遷移回老系統，將流量遷移回老系統之後，還要考慮在新系統中遺留的數據怎麼辦，通常來講，我們有兩個方法，一種方法是通過工具把這些數據遷移回老系統，另外一種方法是讓老系統兼容新數據。
遷移方案的評審？
這裏我們詳細闡述作爲架構師應該如何評審遷移方案。
首先，需要有人牽頭寫即將要評審的遷移方案，遷移方案的內容要包括具體的遷移產品，遷移的目的是什麼，描述爲什麼要進行此次遷移，以及要達到什麼效果，遷移任務的時間點，遷移方案什麼時候在系統上實施，什麼時候真正的進行切量，什麼時候進行驗證，什麼時候結束，遷移過程中有什麼原則，遷移會影響多少用戶和商戶，影響到什麼程度，這次遷移的主要負責人是誰，參與人是誰，這些都需要落實到紙質的文檔。
然後，我們最需要考慮的就是這次遷移的影響範圍，都對哪些角色的人會產生影響，以及對哪些人是透明的，這要評估是否對商戶、用戶、運營人員等有感知，如果對任何人有感知，需要制定提前通知的方案，要通知哪些人，什麼時候通知，以什麼形式通知，是否需要被通知人回覆認可等。
接下來需要確認遷移用戶和商戶的選擇、順序、批次，一般選擇不重要的用戶和商戶先遷移，驗證遷移過程沒問題，再遷移重要的用戶和商戶，要綜合考慮用戶和商戶的等級、交易類型、遷移複雜度等，以此確定用戶和商戶遷移順序和批次。
通常，在全量切換之前，我們需要進行多次驗證，我們需要在準生產測試遷移變更邏輯和開關邏輯，或者通過 TCPCopy 環境來驗證代碼變更的正確性，然後，通過少量的內部用戶在線上驗證邏輯的正確性，最後，會按照我們選定的用戶和商戶的批量，逐漸的放量、觀察和驗證，最後再全量切換。
然後，要確定遷移過程中對系統的變更內容，要確定變更的關鍵內容，然後做測試方案，要測試到所有的場景，包括遷移開關的開和關，要測試遷移失敗後遷移回老系統的情況，不要抱着僥倖態度就忽略這部分的測試。
最後，進入遷移方案的關鍵內容，要對遷移的過程識別風險，這包括交易風險、業務風險、系統風險、技術風險和政策風向等，要對遷移過程中更改的信息流和資金流進行詳細評估，對識別的風險要給出應對方案。
遷移開關和遷移工具
在遷移的過程中，除了要配合遷移開發系統，還有兩個比較特殊的工作。
一個就是遷移開關的設計，在遷移的過程中，雙寫、切流量、有問題了切迴流量，這些都需要使用遷移開關，遷移開關的設計非常的重要，如果遷移開關設計的不合理會產生很大問題，甚至會導致資金損失，在我經歷過的金融系統中，曾經經歷過遷移開關設計在統一的共享緩存上，由於網絡原因重試導致請求流量重複，請求流量走到了不同的應用節點上，不同應用節點讀取共享緩存有時差，導致兩個流量一個走了開的邏輯，一個走了關的邏輯，如果後端系統沒有做冪等，這會導致資金損失。因此，我們對遷移開關的設計，制定瞭如下的最佳實踐。
-
遷移開關要做在訂單上，在訂單上標記是否遷移新系統。
-
遷移開關要有不同的維度，可在訂單上，可在商戶或者用戶上，可在系統級別。
-
遷移開關要能開能關，也就是流量要能切到新系統，也要能切到老系統。
另外一個重要的任務是開發遷移工具，比如說遷移後校驗數據，對比數據等，這都需要開發專業的工具，靠運營對比大量的數據很容易產生誤差，如果想做好遷移，就要捨得成本來投入到這些關鍵任務上。
遷移過程中的政治因素
遷移是個費力不討好的工作，因此，很多人其實不願意幹這個活，遷移做得好，那是應該做的事情，遷移出現了問題，那全是工作沒做好，況且遷移總不會順順利利的，這就是爲什麼大家不願意做，越是有挑戰的任務，其實，它的內在價值就越大。
但是要真的想做一次徹底的遷移，替換掉老的系統，這需要一定的激勵措施，要與遷移負責人和參與人明確遷移的目標和價值，一旦按照計劃遷移成功除了遷移過程中給大家帶來的經驗，還有什麼樣的獎勵，否則，只是作爲一個常規任務，那麼參與者必然失去興趣，遷移也就成了撓癢癢，基本就變成今天遷移一點流量，明天遷移一點流量，最後就新老系統並存，不倫不類的。
遷移一定要由架構組來把關
數據遷移並不是一項需要高大上的技術工作，它需要的是對業務邏輯的把控，對操作流程的理解，對新舊系統特性和環境的掌握，以及對細節的掌控，要深入骨髓般的理解系統才能做好，因此遷移是需要架構組來把關的。
但是，遷移的事情也不是那麼簡單的，也不能由運營單獨搞定的，這涉及到遷移工具的開發，遷移後的驗證，遷移失敗如何遷回，髒數據如何處理，遷移過程中如何平滑過度，例如遷移計費模板的過程，應該開發工具進行對比結果後，才能真正的使用新的計費系統，這些都是必須有業務人員和技術人員來共同完成的，因此，遷移工作最好由架構組牽頭，由產品、運營、技術等一起來實施。
如何彙報遷移技術方案
由於遷移是個非常大的任務，設計的部門和角色比較多，由於出了問題產生的影響比較大，因此，很多老闆都會關注遷移的方案，這裏，對於遷移負責人和架構師，要負責給不同角色的人彙報遷移方案，這裏我總結的一個最佳實踐是不同角色的人關注不同的內容。
-
銷售的老闆會關注遷移後帶來的價值，帶來哪些系統能力的提升，能夠帶來多少毛利的增長。
-
業務的老闆關注的是業務的風險，關注遷移以後是否帶來產品能力的提升等等。也會關注成本的降低；還會關注遷移的里程碑，時間點等。
-
運營的老闆更會關注遷移的實施方案，包括如何通知商戶、如何選擇商戶等。
-
而技術的老闆會關注具體的遷移設計方案本身。
因此，在給不同的老闆做彙報的時候，我們彙報內容的側重點要有所不同。