老舊系統改造要點

每次看到遺留系統的時候,我總想着設計一個遷移方案。時間一久,收集的案例一多,外加上我也有了越來越多的案例,便想着記錄一下這些內容。

遺留系統的遷移

遺留系統的遷移是一個相當複雜的工作,以至於重寫的成本甚至比遷移的成本更高。但是從技術維度來看,步驟無非就是:

  • 設定遷移的目標

  • 制定遷移的計劃

  • 遷移計劃的驗證(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。適用於多種客戶端模式

結論

沒有銀彈,遷移纔是最有意思的技術挑戰。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章