每次看到遺留系統的時候，我總想着設計一個遷移方案。時間一久，收集的案例一多，外加上我也有了越來越多的案例，便想着記錄一下這些內容。
遺留系統的遷移
遺留系統的遷移是一個相當複雜的工作，以至於重寫的成本甚至比遷移的成本更高。但是從技術維度來看，步驟無非就是：
設定遷移的目標
制定遷移的計劃
遷移計劃的驗證（PoC）
實施應用程序的遷移
校驗遷移結果
對，就是這麼簡單。
遺留資產
我們通過把數字化時代的遺留資產劃分了這幾種類型：
遺留代碼。所有沒有測試的代碼。
遺留基礎設施。所有不安全、沒有彈性、不可靠的基礎設施。
遺留系統。所有不可觀察、沒有支持的自制系統或者商業化系統（COTS）
遺留架構。所有限制交付價值的架構。
舊式流程。所有不可度量的流程（缺少 KPI、SLO）
舊式組織。所有不敏捷且不統一的組織
舊式思維。相信上述內容無法克服或無法改變
替換這些系統的原因，也無非就是：
降低成本：更快的概念兌現
改善客戶體驗
上市
可伸縮、可擴展系統
技術變革根上業務變革的速度
遷移的目標架構
架構量子則是具有高功能內聚並可以獨立部署的組件，它包括了支持系統正常工作的所有結構性元素。—— 《演進式架構》
在單體架構中，量子就是整個應用程序，每個部分都高度耦合，因此開發人員必須對其進行整體部署。
| 架構 | 架構量子 | 可演進性 |
沒有架構的單體 | 單體（大泥球） | 低 |
分層單體 | 單體（分層應用） | 低 |
模塊化、結構化單體 | 單體（如模塊化的 COTS） | 中 |
微內核 | 內核 + 插件 | 中 |
事件驅動 - 中介 | 總線、消費者、訂閱者 | 中 |
事件驅動 - 代理 | 隊列、消費者、訂閱者 | 高 |
基於服務的架構 | 微服務 | 高 |
過程模式
對應的替換過程模式有：
改善現有。現有系統已經過現代化改造，可以通過改進設計來提供更好的結果。通常，核心技術堆棧保持不變，或者可能會引入一些次要的補充。
緩慢替換。IT 系統的組件/功能塊已被新技術取代，並作爲單獨的應用程序移至生產環境，而系統的其餘部分仍舊採用舊技術。隨着時間的流逝，剩餘的組件/功能塊將被單獨的應用程序取代，然後逐步重建整個系統。
普通替換。整個系統使用新技術進行了重建，舊系統已停用。它使用標準平臺從頭開始構建，或者使用第三方程序包作爲基礎層構建。
當然了，每種模式的要求也有所不同：
| 改善現有 | 緩慢替換 | 完全替換 | |
現有化技術棧 | 低 | 高 | 最高 |
系統修改 | 應用級別 | 應用級別 / 局部變化 | 企業級 |
風險等級 | 低 | 中 | 低 - 高 |
資金需求 | 中 | 中 | 低 - 高 |
持續時間 | 數月 | 數月到 1 年 | 數月到數年 |
長期收益 | 低 | 高 | 最高 |
人生度 | 最高 | 高 | 低 |
人力成本 | 低 | 中 | 高 |
遷移策略
在我們決定好了遷移的目標和模式之後，只需要適合的方式即可：
保留（Retain），什麼都不做。
清退（Retire），擺脫原有束縛。
重新採購（Repurchase），轉移至不同的產品。
重新託管（Rehost），即直接遷移。
平臺更新（Replatform），『修補加遷移』。
架構重構（Re-Architect），更改應用程序的架構和開發方式，往往通過使用雲原生功能來完成的。
這裏，我們主要考慮討論的是：重新託管、平臺更新、架構重構，因爲只有這三項是技術活動。
防護網
對於遺留系統的遷移，想必你也相當的有經驗了，比如這些常見的實踐：
使用版本管理。
小步前進。
使用測試作爲防護網。
頻繁提交。
……
而在這其中除了架構的設計，最複雜的一部分莫過於：防護網的設計。
自動化測試
適用的場景：遺留代碼、遺留系統、 遺留架構。
對應的實施方式：
代碼級重構。
組件級重構。
API 級重構。
系統級遷移。
常見的防護措施有：
單元測試。針對於包級、組件、函數級的代碼重構場景。
容器內測試。針對於模塊化的 OSGI 架構應用。
API 測試。採用紡錐型測試策略進行系統遷移。
端對到端測試。較少採用，成本較高，效果較差。
UI 測試。
性能測試。針對於雲遷移下的對比。
常見的工具有：xUnit、 REST Assured、Karate、Cucumber 等。
比對
適用場景：遺留基礎設施、遺留系統、遺留架構。
基礎設施遷移：
數據庫遷移。
構建工具遷移。
常見的實施方式有：
數據比對測試。通過測試對比遷移前後的數據變化，來判定遷移是否成功。
數據庫比對測試。同上，只是維度變成了數據庫。
Schema 比對。確保數據模型或架構結構在源系統和目標系統之間匹配。
Row 計數比對。確保計數是針對源和目標之間的表是否匹配。
數據彙總測試。對源和目標之間的大量表執行彙總檢查。
製品比對測試。針對於構建工具遷移，對比構建產物，看是否發生變化。
checksum 比對。
class 比對。
常見的工具有：DBDiff、DbUnit 等。
防腐層
適用場景：遺留系統絞殺。
常見的實施方式有：
過渡 API。適用於遺留系統遷移的過渡模式，在遷移完成好，可以刪除。
防腐層。即建立與遺留、腐敗的代碼的層級，以隔離系統變化。
BFF。適用於多種客戶端模式
結論
沒有銀彈，遷移纔是最有意思的技術挑戰。