譯者 | 李睿

審校 | 重樓

在分布式系統中，多個服務協同工作以完成既定任務，每個服務由不同的團隊管理并獨立發展。這往往催生了對依賴遷移的需求，例如數據庫模式更新、外部服務升級或數據源更改。這些遷移是開發生命周期的關鍵部分，需要周密的計劃和執行，以確保有效地防止回滾、數據不一致問題和運營中斷等情況的發生。

軟件遷移示例

在探索遷移策略之前，了解需要進行軟件遷移的常見場景及其詳細規劃要求至關重要：

（1）數據源更改：應用程序當前從訂單表中獲取customerID以向客戶收費。但是，現在需要進行遷移，并從待支付表中（pendingPayments）表中獲取customerID。

（2）依賴版本更新：工作團隊將他們的系統從V1版本更新到V2版本，其中新版本不向后兼容。應用程序必須適應新版本以保持無縫的功能。

軟件遷移策略

在持續運行的系統中，必須設計遷移以避免服務中斷并確保可靠性。為實現這一目標，應優先考慮兩個關鍵目標：

（1）零停機時間：在整個遷移過程中，系統必須保持完全運行并可供客戶端訪問，確保不間斷的可用性。

（2）數據完整性：遷移必須保持數據的準確性和一致性，確保輸出保持可靠且不受遷移的影響。

成功指標

定義清晰且可衡量的指標是成功遷移的基礎。這些指標確保遷移在不引入錯誤或不一致的情況下實現其目標：

• 對于數據源更改：通過驗證新舊數據源是否提供相同的數據來衡量是否成功。這確保了遷移不會影響數據的完整性或準確性。
• 對于依賴項更改：通過確認依賴的舊版本和新版本的輸出（例如，對象值）相同來定義成功，這保證了轉換后的無縫功能。

遷移代碼和A/B測試框架

在實施遷移代碼時，對更改進行結構化以實現向新系統的平穩過渡至關重要。

最佳實踐是將遷移代碼置于控制和處理設置或A/B測試框架之后。這種方法允許開發人員在新舊系統之間無縫切換，而不需要額外的代碼更改。它增強了測試、監控和風險管理，確保遷移過程可控，并在必要時易于逆轉。

為了實現這一點，系統應設計為支持多種運營模式，這些模式包括：

（1）舊模式

• 說明：系統繼續像以前一樣運行，使用舊版實現。
• 目的：在引入新系統之前，作為基準并確保穩定性。

（2）影子模式

• 說明：新舊系統并行運行，但客戶端只使用舊系統的結果。
• 目的：該模式允許在不影響最終用戶的情況下比較新舊系統的輸出。
• 行動：測量和記錄新舊系統結果之間的任何差異，并發布指標進行分析，以驗證新系統的準確性。

（3）反向影子模式

• 說明：舊系統和新系統都運行，但這次客戶端使用新系統的結果。
• 目的：提供機會在實際條件下驗證新系統的結果，同時保留舊系統作為備用。
• 行動：記錄兩個系統之間的差異，并發出指標來監控新系統的性能。

（4）新模式

• 描述：新系統全面投入運行，舊系統退役。
• 目的：這標志著遷移的完成，新系統已經過徹底的測試和驗證，可以用于生產。

執行遷移

步驟1：準備遷移（舊模式）

遷移過程默認從系統以舊模式運行開始，這確保當前的實現在遷移準備期間保持運行和穩定。

步驟2：影子模式

切換到影子模式，在這種模式下，舊系統和新系統并行運行，但只有舊系統的結果返回給客戶端。這是最關鍵的階段，因為它允許在不影響生產功能的情況下對新系統進行廣泛的測試和改進。使用指標和警報來監視差異，并調查和處理其根本原因。你應該進行必要的修復，以確保新系統的行為符合預期。在這一階段應該分配充足的時間，在各種場景中收集足夠的指標。

步驟3：反向影子模式

一旦對影子模式感到滿意，就可以切換到反向影子模式。在該模式下，客戶端使用新系統的結果，而舊系統繼續在后臺運行以進行驗證。這種轉換有助于識別新系統成為主要系統時可能出現的任何新問題或意外行為。例如，一個問題在影子模式下可能不會被發現，但在反向影子模式下可能會被檢測到，即舊系統向數據庫寫入正確的值，而新系統只讀取這些值而沒有進行必要的更新。由于新系統現在在反向影子模式下驅動整個流程，因此任何此類差異都會變得顯而易見。

如果識別出關鍵問題，重要的是切換回影子模式，以在實施必要修復的同時將風險降至最低。

步驟4：完全遷移（新模式）

一旦對反向影子模式下的性能充滿信心，就過渡到新模式，在新模式下，舊系統將退役，新系統將開始全面運行。這樣就完成了一個可靠的且經過徹底測試的新系統的遷移。

這種分階段執行的方法確保了平穩過渡，實現風險最小化和全面測試，并在出現問題時采取回退策略。

潛在的缺點

對簡單遷移采取過度措施

對于直接的或向后兼容的遷移來說，這種方法可能過于復雜。例如，升級Java版本或在兼容API之間轉換等任務通常需要最少的努力，并且可以通過更簡單的策略和不太詳盡的計劃來完成。

資源密集

在影子模式下運行并行系統可能在基礎設施、計算和工程投入方面成本高昂。規模較小的團隊或項目可能難以分配日志分析、指標檢測和擴展測試所需的資源。

復雜性

管理多個運行模式（例如，舊模式、影子模式、反向影子模式）將會增加遷移過程的復雜性。它還可能導致協調方面的挑戰，特別是當涉及多個團隊來適應依賴關系更改或解決差異時。

結論

這種遷移策略在確保可靠性和效率方面具有顯著的優勢。通過使用影子模式和反向影子模式，可以及早發現新系統的潛在問題，從而在全面部署之前大幅降低風險。在新舊系統之間切換的靈活性確保了更平滑的回滾，從而提供了一個強大的安全網。此外，監視關鍵指標和記錄差異有助于評估系統準備情況并指導必要的調整。

但是，重要的是要權衡該策略的潛在缺點，以確保不會在不適用的情況下采用它，畢竟有些遷移更適合采用更簡單的方法。盡管存在這些考慮因素，但對于高風險或復雜的遷移任務來說，該策略提供了一種可控的增量方法，可以最大限度地減少中斷，確保平穩的用戶體驗，同時謹慎地管理風險。

原文標題：Phased Migration Strategy for Zero Downtime in Systems，作者：Sandeep Kumar Gond