譯者 | 李睿

審校 | 重樓

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

軟件遷移示例

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

（1）數(shù)據(jù)源更改：應(yīng)用程序當(dāng)前從訂單表中獲取customerID以向客戶收費。但是，現(xiàn)在需要進行遷移，并從待支付表中（pendingPayments）表中獲取customerID。

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

軟件遷移策略

在持續(xù)運行的系統(tǒng)中，必須設(shè)計遷移以避免服務(wù)中斷并確保可靠性。為實現(xiàn)這一目標(biāo)，應(yīng)優(yōu)先考慮兩個關(guān)鍵目標(biāo)：

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

（2）數(shù)據(jù)完整性：遷移必須保持?jǐn)?shù)據(jù)的準(zhǔn)確性和一致性，確保輸出保持可靠且不受遷移的影響。

成功指標(biāo)

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

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

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

在實施遷移代碼時，對更改進行結(jié)構(gòu)化以實現(xiàn)向新系統(tǒng)的平穩(wěn)過渡至關(guān)重要。

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

為了實現(xiàn)這一點，系統(tǒng)應(yīng)設(shè)計為支持多種運營模式，這些模式包括：

（1）舊模式

• 說明：系統(tǒng)繼續(xù)像以前一樣運行，使用舊版實現(xiàn)。
• 目的：在引入新系統(tǒng)之前，作為基準(zhǔn)并確保穩(wěn)定性。

（2）影子模式

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

（3）反向影子模式

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

（4）新模式

• 描述：新系統(tǒng)全面投入運行，舊系統(tǒng)退役。
• 目的：這標(biāo)志著遷移的完成，新系統(tǒng)已經(jīng)過徹底的測試和驗證，可以用于生產(chǎn)。

執(zhí)行遷移

步驟1：準(zhǔn)備遷移（舊模式）

遷移過程默認從系統(tǒng)以舊模式運行開始，這確保當(dāng)前的實現(xiàn)在遷移準(zhǔn)備期間保持運行和穩(wěn)定。

步驟2：影子模式

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

步驟3：反向影子模式

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

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

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

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

這種分階段執(zhí)行的方法確保了平穩(wěn)過渡，實現(xiàn)風(fēng)險最小化和全面測試，并在出現(xiàn)問題時采取回退策略。

潛在的缺點

對簡單遷移采取過度措施

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

資源密集

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

復(fù)雜性

管理多個運行模式（例如，舊模式、影子模式、反向影子模式）將會增加遷移過程的復(fù)雜性。它還可能導(dǎo)致協(xié)調(diào)方面的挑戰(zhàn)，特別是當(dāng)涉及多個團隊來適應(yīng)依賴關(guān)系更改或解決差異時。

結(jié)論

這種遷移策略在確?？煽啃院托史矫婢哂酗@著的優(yōu)勢。通過使用影子模式和反向影子模式，可以及早發(fā)現(xiàn)新系統(tǒng)的潛在問題，從而在全面部署之前大幅降低風(fēng)險。在新舊系統(tǒng)之間切換的靈活性確保了更平滑的回滾，從而提供了一個強大的安全網(wǎng)。此外，監(jiān)視關(guān)鍵指標(biāo)和記錄差異有助于評估系統(tǒng)準(zhǔn)備情況并指導(dǎo)必要的調(diào)整。

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

原文標(biāo)題：Phased Migration Strategy for Zero Downtime in Systems，作者：Sandeep Kumar Gond