金融支付基礎設施對可用性的要求極高。Form3 作為一家提供帳戶對帳戶支付服務的平台，其系統必須確保在任何情況下都能持續運作。最初，Form3 的 v1 架構完全依賴 AWS，利用 AWS ECS 運行 Java 微服務，並使用 SQS 處理非同步工作流與 RDS Postgres 儲存數據。這種高度耦合的設計讓團隊在創業初期能快速迭代，將運維壓力外包給雲端供應商。
然而，隨著英國銀行監管機構對「雲端集中度風險」的關注，銀行客戶被要求必須具備「退出雲端」的能力，以防止單一供應商故障導致金融體系癱瘓。這迫使 Form3 必須將架構升級為 v2，從單雲環境轉向一個能同時在 AWS、Google Cloud Platform (GCP) 與 Azure 上運行且保持「三雲活性」（Triple Active）的複雜系統。
核心內容：三雲活性架構的實現
為了實現三雲活性，Form3 的設計目標是將「雲端供應商」視同於單一雲端內的「可用區」（Availability Zone, AZ）。這意味著如果任一雲端完全失效，流量能無縫切換至其他兩家雲端，而對使用者幾乎沒有感知。
為了達成此目標，Form3 採取了三項關鍵技術策略：
第一，採用雲端不可知（Cloud Agnostic）的技術棧。為了避免維護三套不同版本的程式碼，團隊將開發語言由 Java 改為 Go，以獲得更輕量級的部署足跡與更清晰的邏輯。基礎設施則統一使用 Kubernetes (K8s) 容器編排系統，確保同一份軟體能在不同雲端一致運行。
第二，解決跨雲數據一致性。這是多雲架構最困難的部分。Form3 捨棄了雲端原生的資料庫，轉而使用 CockroachDB（一種分散式 SQL 資料庫，兼容 Postgres 協議）與 NATS JetStream（高性能訊息代理）。這兩項技術允許在三個雲端的 K8s 集群之間建立單一的邏輯集群。例如，在 GCP 發送的訊息可以被 Azure 的節點接收，而數據則透過 Raft 共識演算法在三雲之間同步，確保強一致性。
第三，建立私有跨雲網路。為了讓不同雲端的 Pod 能夠直接透過 IP 通訊，Form3 部署了高可用且冗餘的私有鏈路，並在各雲端之間建立了相互信任的網路環境。
技術解讀：克服多雲部署的三大挑戰
在實作過程中，Form3 面臨了三個主要的技術瓶頸，並開發了相應的解決方案：
跨雲 DNS 解析問題。在單一 K8s 集群中，Pod 之間可以使用 Headless Service 的 DNS 名稱通訊，但跨雲則無法直接解析。Form3 創造了一種「偽後綴」機制，在 DNS 名稱中加入雲端名稱（例如 azure.service.local）。當本地 DNS 發現請求包含特定雲端標記時，會將請求轉發至該雲端的網路負載平衡器，再由對方的 CoreDNS 解析回本地 Pod IP。
跨集群的可用性保障。為了防止單一控制平面失效，Form3 選擇運行三個獨立的 K8s 集群而非一個跨雲的大集群。但這導致 K8s 原生的 Pod 中斷預算（Pod Disruption Budget, PDB）失效，因為 PDB 僅作用於單一集群。若三個集群同時進行節點更新，可能會導致 CockroachDB 失去過半數節點而崩潰。對此，Form3 開發了 X-PDB（跨集群 Pod 中斷預算）Operator，確保在全域範圍內同一時間僅允許一個 Pod 下線。
基礎設施即代碼（IaC）的維護噩夢。隨著環境增加（開發、測試、生產）以及地理分佈擴展，管理數百個節點池的 PR（拉取請求）變得極其低效。Form3 隨後開發了集群生命週期運算子（Cluster Lifecycle Operator, CLO），將底層節點池的管理抽象化。工程師只需定義目標映像檔版本，由 CLO 自動管理滾動更新的順序與速度，將數百個 PR 簡化為每個平台一個 PR。
影響與限制：市場適應性與權衡
儘管三雲活性架構在技術上極其強大，但在進入美國市場時，Form3 發現這種方案並不總是最佳選擇。美國客戶更在意「地理韌性」（Geographical Resilience），即東岸與西岸的備援，而非單純的供應商多元化。
由於美國大陸幅員廣大，跨雲同步數據會產生巨大的網路延遲（Latency），這會直接衝擊支付系統的服務等級協定（SLA）。為了在性能與韌性之間取得平衡，Form3 在美國採取了「主備模式」（Active-Standby）：主站運行於 AWS 東岸，備援站位於 GCP 西岸。
這種模式引入了 RTO（恢復時間目標）與 RPO（恢復點目標）非零的風險。為了降低故障恢復時間，Form3 後續引入了邏輯數據複製（Logical Data Replication）與事件總線同步，讓備援站保持「溫啟動」狀態，而非僅依賴 S3 備份還原，從而大幅縮短切換時間。
實務意義與總結
Form3 的經驗證明，多雲架構並非單純的技術堆砌，而是一種成本、性能與風險的權衡。三雲活性架構雖然能提供極高的可用性，但其運維成本高昂且對平台工程團隊的要求極高。
對於大多數企業而言，選擇多雲的決定因素應在於：第一，目標市場的法規或客戶是否要求（如金融監管）；第二，是否擁有足以支撐該複雜度的平台工程能力；第三，業務是否能承受跨雲同步帶來的延遲。如果這些條件不成立，單雲多可用區或簡單的主備切換方案往往是更務實的選擇。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。