若您今年有關注 Monster Scale Summit，您可能聽過我們關於美國運通支付網路遷移的演講——不僅遷移了一次，而是兩次——且客戶無感停機，這意味著在兩次遷移過程中，沒有任何交易被中斷，也無需安排預定的維護時段。本次演講著重探討了我們如何在嚴格的營運限制下，可靠地轉移即時支付流量。如果您錯過了，可以在 Monster Scale Summit 網站上觀看演講。
本文將擴展本次會議演講的內容，更深入地探討兩次遷移中的工程決策、權衡取捨以及學到的經驗。
支付網路是一個關鍵任務的分布式系統，負責處理包括即時卡片授權在內的關鍵支付流量。它作為美國運通全球商家、收單機構和發卡機構之間的橋樑。
此平台必須持續可用、具備低延遲，並能處理大量關鍵流量。
2018 年，美國運通開始了為期多年的支付網路現代化計畫，其中包括將舊平台遷移至新的微服務架構。
如此規模的遷移必須在幾個不可協商的限制下進行：
我們不僅需要一次在這些限制下完成遷移，還需要做兩次。
第一次遷移涉及將即時卡片授權流量從舊支付網路轉移到一個新的、現代化的平台。
雖然支付網路龐大且複雜，但即時卡片授權流量主要由兩個子系統處理：路由層（為簡便起見，我們將其稱為「全局交易路由器」或「GTR」）和支付處理平台。
理解這兩個子系統是理解我們如何進行遷移的關鍵。
GTR 作為支付網路的入口。與典型的後端平台不同，卡片授權流量主要透過承載 ISO8583 訊息的長時 TCP 連線傳輸，ISO8583 是一種支付專用的訊息格式。
GTR 管理來自收單機構和發卡機構的長時連線，並將進來的交易路由到支付處理平台。它也負責將支付處理平台的響應路由給網路參與者。
該路由器刻意實現了對支付協議的最小化理解——僅足以做出路由決策。其主要角色是在不擁有支付處理邏輯的情況下，做出路由、故障轉移和流量整形決策。
作為入口，GTR 也為支付網路提供了集中式的流量控制和彈性。它位於支付網路的邊緣，高度專業化，針對低延遲和高吞吐量進行了優化。
支付處理平台是複雜、關鍵業務的支付處理邏輯所在之處。
該平台採用微服務架構實現，包含眾多服務和資料庫。當交易流經支付網路時，支付處理平台會對其進行驗證、豐富和轉換。
這項邏輯經過多年開發和完善。重建這項邏輯是一項重大任務，確保與舊系統的對等性至關重要。
從頭開始重建整個支付網路是一項重大的、為期多年的努力。它涉及複雜的處理邏輯、廣泛的邊緣案例和例外處理。在等待整個平台完成後再遷移即時流量是不可行的。開發新功能將需要在舊系統和新系統中都進行開發，導致重複工作並增加功能漂移的風險。
取而代之的是，我們將遷移分為三個階段：
在第一階段，我們希望將 GTR 引入交易流程。這是遷移中最關鍵的階段——它實現了所有其他階段，並且是第一個將新組件插入即時流量路徑的階段。
當新連線到達 GTR 時，它會將所有流量路由到舊支付網路。這使我們能夠在無需處理邏輯對等的情況下引入 GTR。
對於每個進來的連線，GTR 會建立一個對應到舊支付網路的連線。在進來連線上收到的任何交易都會透過下游連線轉發到舊支付網路。沒有邏輯，沒有訊息解析，只是簡單的轉發。
這種方法使我們能夠以最小的風險將集中式流量控制和彈性引入支付網路。為了進一步降低風險，我們分小批次遷移連線，密切監控系統健康狀況和效能。在此階段，GTR 的可觀察性和指標至關重要。
有了 GTR 後，我們就能夠將影子流量引入新的支付處理平台。
影子流量本質上是對即時生產流量的重播。我們部署了一個新的支付處理平台的專用生產實例，並將即時流量的副本重播給它。
如果舊支付處理平台和新支付處理平台之間存在任何功能差異，都會在這裡顯現。
這種影子流量功能使我們能夠在類似生產的環境中驗證支付處理邏輯，而不會影響即時流量。它並沒有取代傳統的單元測試和功能測試，而是為將即時流量路由到新平台提供了最後的驗證步驟。
在透過影子流量驗證了處理邏輯並部署了 GTR 後，我們準備將即時流量路由到新的支付處理平台。
我們將金絲雀部署原則應用於平台遷移。我們擴展了 GTR，使其具備足夠的支付協議理解能力，能夠根據交易屬性做出路由決策。
這使我們能夠擷取小比例的即時流量並將其路由到新的支付處理平台。隨著功能的就緒，我們識別了可以路由到新平台的客戶群體和交易類型。
GTR 負責根據金絲雀配置將這些交易路由到適當的後端平台。所有金絲雀決策均由 GTR 在交易到達支付處理平台之前進行集中強制執行。這種金絲雀路由功能是作為 GTR 的自訂邏輯實現的，以支援此次遷移，此後已成為支付網路架構的關鍵組成部分。
我們從 1% 開始；當一切看起來都很好時，我們將其增加到 5%，然後是 10%，依此類推。
如果檢測到異常，我們會立即將所有路由恢復到舊支付網路。這種漸進式的方法使我們能夠以最小的風險遷移即時流量。我們避免了任何一次性切換或影響客戶的操作。
除了降低風險外，這種方法還減少了重複的開發工作。它允許平台在不需長時間維護兩個獨立程式碼庫的情況下，隨著真實流量一起演進。
在新支付處理平台上線後，我們面臨了第二次重大遷移，該遷移重複使用了平台遷移期間建立的相同流量控制模式。我們需要從舊的 Kubernetes 基礎設施遷移到新的 Kubernetes 環境。
由於兩個環境在網路、安全和營運實踐方面存在顯著差異，因此無法進行就地遷移。這需要在新的 Kubernetes 環境中完全重建支付網路基礎設施。
這意味著我們需要再次遷移即時流量——零停機。延遲、吞吐量和彈性特性也必須保持一致。
此次遷移的第一步是建立一個可重複且一致的新 Kubernetes 環境。我們利用基礎設施即代碼（IaC）來確保測試和生產環境的一致性和可重複性。
現有的 Pod 和服務配置從我們現有的生產環境中匯出。它們被重新定義為聲明式的 IaC 配置。
這種方法確保了跨區域和環境的一致性。花費了一些時間才正確完成，但一旦我們有了堅實的基礎，我們就能夠快速啟動新環境，用於初始遷移和未來的擴展。任何新的基礎設施變更現在都從 IaC 定義開始。
在新環境建立後，我們驗證了它能夠滿足我們的效能和彈性要求。我們首先在現有環境中建立了一個效能基準。然後，我們在新環境中部署了相同的應用程式版本，並進行了負載測試以比較效能特性。新環境表現出需要調整的差異。
我們透過 IaC 實施了這些調整變更，並將其推廣到所有環境。
彈性測試採用了類似的方法。我們在現有環境中運行了各種故障場景，記錄了結果，然後在新環境中運行了相同的場景。任何差異都經過調查，並透過 IaC 變更解決。
在轉移任何流量之前，我們確保新環境滿足或超過了所有效能和彈性要求。
在新環境驗證後，我們準備再次遷移即時流量——零停機。
我們重複使用了第一次遷移中的相同金絲雀路由策略。這次，我們在兩個相同的支付處理平台之間路由流量。外部 ISO8583 連線繼續終止在邊緣；金絲雀路由僅應用於 GTR 和支付處理平台之間的內部 gRPC 遠端程序呼叫（gRPC）流量。
在建構 GTR 時，我們利用 Envoy Proxy 和自訂控制平面實現了金絲雀部署。雖然我們最初的實施重點是同一區域內不同版本之間的路由，但我們將此功能擴展到跨不同區域的路由。
我們稱之為多區域金絲雀路由。這使我們能夠將所有流量從一個區域路由到另一個區域。在重新路由流量後，我們得以在原始區域啟用新的 Kubernetes 環境。
準備就緒後，我們將流量百分比路由回原始區域，該區域現已運行新的 Kubernetes 環境。我們逐步增加回原始區域的流量，並密切監控系統健康狀況和效能。
可觀察性對於此步驟與金絲雀路由本身一樣至關重要。我們的業務指標、應用程式日誌和應用程式健康指標都讓我們能夠深入了解新環境在即時流量下的表現。如果檢測到問題，我們可以快速將所有流量恢復到次要區域。
兩次遷移都是重大的工程，我們在此過程中學到了很多。
GTR 和基於 Envoy Proxy 的金絲雀路由是兩次遷移的關鍵組成部分。它們提供了必要的流量控制，以便在不同平台和環境之間安全地路由即時流量。
這些功能最初是作為粘合程式碼開發的，但隨著時間的推移，它們演變成了我們支付網路架構的關鍵組成部分。
在兩次遷移中，能夠快速安全地回滾變更是至關重要的。在設計系統和流程時考慮回滾，降低了風險，並使我們能夠快速響應出現的任何問題。
可觀察性對於兩次遷移的成功至關重要。對系統健康狀況、效能和業務指標有深入的了解，使我們能夠在遷移過程中做出明智的決策。
影子流量功能在將即時流量路由到新的支付處理平台之前，提供了最後的驗證步驟。此功能對於識別舊系統和新系統之間任何未知的差異至關重要。
此後，我們利用此功能對新功能和變更進行持續測試和驗證。我們也正在使用此功能來驗證其他下游系統的遷移。
利用 IaC 進行 Kubernetes 遷移確保了一致性和可重複性。它使我們能夠自信地管理複雜的基礎設施變更，並為未來的擴展奠定了基礎。
最重要的教訓是耐心和紀律。在支付領域，成功是以可靠性來衡量的，即使這需要更長的時間。