
兩次遷移美國運通支付網路且達成零停機時間的技術實踐
這篇文章詳細介紹了我們如何將任務關鍵型的支付網路從舊系統遷移到微服務架構,隨後又遷移到新的 Kubernetes 環境,且在兩次遷移過程中都確保了零停機時間,完全沒有影響到客戶交易。
背景
這篇文章詳細介紹了美國運通(American Express)如何將其核心支付網路進行兩次大規模遷移,且全程達成零停機與零客戶影響的技術細節。該系統作為商戶、收單行與發卡行之間的關鍵橋樑,必須在極低延遲與高可用性的嚴苛條件下,從舊有的單體架構轉向現代化的微服務架構,並透過引入「全球交易路由器」(GTR)來實現流量的精確控制與平滑過渡。
社群觀點
在 Hacker News 的討論中,參與者對這項工程壯舉展現了兩極化的反應。一部分技術人員對支付系統的本質感到玩味,認為人類投入如此龐大的基礎設施與心力,最終目的僅是為了極其精確地在兩個數字之間進行減法運算,並確保審計過程無誤。然而,這種看似簡單的邏輯背後隱藏著極高的複雜度,有網友指出,支付網路除了防範欺詐外,還必須處理極其繁瑣的獎勵積分計算、限時優惠折抵以及退款時的帳務沖銷,這些細節正是美國運通能提供優於一般銀行應用程式體驗的核心原因。
關於系統架構的轉型,社群內展開了針對「微服務與延遲」的技術辯論。有評論者質疑,支付網路對延遲極其敏感,轉向微服務架構是否會破壞其服務等級協議(SLA)。對此,討論者們對支付流程的實際耗時提出了不同見解。有人認為終端機刷卡後的數秒等待多半是點對點銷售系統(POS)的問題,而非網路本身;也有專業人士補充,發卡行處理器通常有約 2.5 秒的核准視窗,雖然實際網路傳輸可能在百毫秒等級,但整體流程涉及收單行、網路與發卡行之間的多方往返,微服務帶來的延遲在這種容許範圍內或許並非致命傷。
此外,討論中也出現了一些針對技術選型的揶揄與對網站安全性的疑慮。當讀者在文中發現 Kubernetes 的蹤影時,引發了部分對過度工程化的感嘆。有趣的是,由於該部落格似乎未正確配置 SSL 憑證,導致部分網友的防毒軟體或網路服務供應商將該網址標記為可疑網站,這對於一家強調安全與現代化的金融科技公司來說,成了一個帶有諷刺意味的小插曲。
延伸閱讀
- The Anatomy of the Swipe:留言中推薦的一篇 Medium 文章,深入解析了刷卡交易背後的詳細流程與參與方。