美團Java團隊分享：如何實踐支付通道自動化管理

隨着支付業務量激增，支付團隊不斷壯大。爲了知足日益增加的業務需求，大量的支付通道逐漸接入，但因爲對接的各銀行和第三方系統的穩定性良莠不齊，支付通道故障時有發生，做爲承接上下游的核心繫統，要在一系列不穩定的系統之上創建一個能夠給上游提供穩定服務的系統，僅依賴人工維護是遠遠不夠的，因此創建一個完善的支付通道自動化管理系統勢在必行。本文主要介紹美團點評技術團隊支付通道自動化管理的演進之路。

初級階段

監控系統初級階段

故障處理流程圖以下：

支付通道自動化管理的初級階段持續時間是2014.06~2015.09，故障處理手動切走、手動切回，一次支付通道故障的詳細處理流程以下：
(1) 支付網關監控檢測到支付通道成功率異常，發送報警消息到美團點評技術；
(2) 美團點評技術當即查看監控頁面確認故障，並登錄到渠道路由配置頁面去修改對應支付通道的狀態，將通道置爲不可用；
(3) 收銀臺實時讀取支付通道狀態，將故障通道的流量所有切走；
(4) 美團點評技術聯繫銀行或第三方報故障，對方去查看問題，確認恢復後通知美團點評技術；
(5) 美團點評技術修改支付通道狀態爲可用，收銀臺實時讀取到該支付通道，將線上流量導入；
(6) 若是支付通道恢復，則用戶能夠正常交易，本次故障結束；
(7) 若是支付通道未恢復，大量交易失敗，美團點評技術須要將該通道從新置爲不可用，再次去聯繫銀行或第三方處理，如此往復，直到該通道的全部交易正常，本次故障結束。

半自動化階段

初級階段存在的問題

初級階段系統的主要目標是擴大支付通道的覆蓋範圍，提升用戶支付成功的機率。隨着支付通道的不斷接入，因爲公網環境、銀行或第三方系統的不穩定性，致使故障頻率升高，故障時間延長。而此時處於初級階段的監控系統已沒法有效保證通道的穩定性：
(1) 支付網關監控報警漏報率較高，小流量通道故障沒法及時發現；
(2) 支付通道切換都是人來手動處理，一方面技術的工做量嚴重增長，另外一方面沒法保證在處理故障過程當中沒有任何誤操做；
(3) 故障解決花費的時間較長，故障對用戶形成的影響就更大，同時用戶的不斷重試對支付系統自己也形成很大的壓力；
(4) 故障通道嘗試恢復時，只能所有打開用線上真實交易來檢測，可能會由於通道還沒有恢復，形成二次故障，擴大影響範圍。

系統優化

優化監控系統

(1) 優化監控算法：優化監控算法，將報警的準確度提升到95%，基本作到無誤報、無漏報；
(2) 新增自動置通道爲不可用功能：監控檢測到支付通道故障時，一方面發送報警消息給技術人員，另外一方面調用渠道路由的接口將支付通道置爲不可用，實現支付通道故障的快速降級。

此時的監控系統以下圖所示：

渠道路由支持實時通道變動

在初級系統中，渠道路由的主要功能是提供經過頁面修改支付通道配置來實現人爲管理支付通道的功能。隨着監控系統的完善，監控準確度和靈敏度提高，此時監控系統已經具有支付通道管理的決策力，須要渠道路由提供一個能夠實時更新支付通道狀態的接口，以實現支付通道的自動化管理。而做爲自動通道切換的補償機制，渠道路由還實現了基於移動App人工一鍵切換的功能，盡最大可能保證故障的快速解決。

渠道路由提供的接口除了具有實時通道狀態變動功能之外，還須要進行了如下幾個方面的控制：
(1) 一鍵切換功能，必須控制訪問權限；
(2) 具備事務控制和時效性控制，不管是自動仍是一鍵切換，一次故障必須能且只能切走通道流量一次；
(3) 必須保證通道狀態變化能夠經過各類途徑通知到相關的技術人員。

故障處理流程圖

支付通道自動化管理的半自動化階段持續時間是2015.10~2016.10，故障處理自動切走、手動切回，一次通道故障的詳細處理流程以下：
(1) 監控檢測到通道成功率異常發送報警消息給美團點評技術，同時自動將通道置爲不可用；
(2) 美團收銀臺實時讀取通道狀態，將故障通道的流量所有切走；
(3) 美團點評技術當即聯繫銀行和第三方報故障，對方確認問題和恢復狀況後反饋到美團；
(4) 美團點評技術修改通道狀態爲可用，收銀臺實時讀取到通道狀態爲正常後，將線上流量放入該通道；
(5) 若是通道恢復，則用戶能夠正常交易，本次故障結束；
(6) 若是通道未恢復，大量交易失敗，美團點評技術或監控會再次將通道狀態爲不可用；
(7) 美團點評技術再次聯繫銀行或第三方處理故障，如此往復，直到線上交易正常，本次故障結束。

主要完成的改進點

(1) 優化報警監控算法，並支持一鍵查看通道狀態，保證支付通道故障的快速發現；
(2) 實現故障通道一鍵切換和自動切換，從各方面保證通道故障快速處理；
(3) 大幅下降處理支付通道故障的人力成本。

全自動化階段

半自動化階段存在的問題

半自動化階段已將故障處理流程大幅簡化，但此時的系統中還存在如下問題：
(1) 通道恢復依賴於銀行或第三方的反饋，致使支付通道恢復延時較久；
(2) 一次通道故障涉及到的系統和人員較多，人工沒法保證全面和及時的周知。

但渠道路由因爲早期設計的侷限性，沒法實現全自動化，須要優化監控系統和渠道路由系統。

系統優化

實現監控自動回切

監控自動回切的主要思想是對故障通道進行小幅放量，經過檢測放量交易的成功率判斷通道是否恢復正常。若是小幅放量的交易成功率正常則繼續放量，反之則直接將通道切回故障，隔一段時間再從新開始進行放量測試，直到將通道置爲正常爲止。自動回切狀態機以下圖所示：

此過程的關鍵點是通道放量節奏的控制，通道放量節奏的影響要素有三個：首次放量的大小、兩次放量時間間隔、通道放量速度，放量節奏太快則易形成二次故障，太慢則通道恢復過慢，沒法達到縮短故障影響時間的效果。如下是最終實現的一次通道回切過程示例：

(1) 通道放量，但放量失敗

(2) 再次放量，若是成功則擴大放量

(3) 通道切回正常

實現通道相關係統間聯動

支付通道故障時，一方面經過消息組件通知到營銷活動、退款等系統，協助進行活動下線、通道退款關閉等處理，減小通道故障對其餘系統的影響；另外一方面以接口方式通知業務方系統，協助業務方系統進行故障分析。

渠道路由重構和優化

解決業務問題

支付通道有兩種通道類型，第一種定義爲「單卡通道」，只給指定銀行的指定卡種使用的通道，好比「中國銀行儲蓄卡快捷通道」就只能給輸入了中國銀行儲蓄卡卡號的請求使用；第二種定義爲「跨卡通道」，能給多個銀行的指定卡種使用的通道，好比「銀聯API儲蓄卡」就能夠給「中國銀行儲蓄卡」、「中國建設銀行儲蓄卡」等多個銀行的儲蓄卡帳號使用。

(1) 處理「跨卡通道」上某家銀行故障的狀況

因爲老路由系統設計之初，只簡單從「銀行渠道」和「支付通道」兩個維度考慮存儲信息，設計的表結構比較簡單，對於支付通道故障的狀況只能切換整個通道。若是是「跨卡通道」的單個銀行故障，老系統沒法作到只把這故障銀行流量切走——要麼聽任整個「跨卡通道」由於單個故障銀行拉低成功率，要麼切走總體通道的流量。在新路由系統中，針對每家銀行的指定卡種，分別記錄「跨卡通道自己不支持」和「跨卡通道支持可是銀行系統故障」的兩類數據，在執行路由邏輯篩選的時候就根據這些信息進行過濾，實現「跨卡通道」切走單個故障銀行。

(2) 配合通道監控系統實現通道的回切放量，試探性逐步恢復通道

解決技術問題

(1) 收斂分散的業務和存儲邏輯

驅使重構路由系統的一大緣由是老路由系統業務邏輯和數據存儲分散、系統間的邏輯嚴重耦合、邊界不清晰，常常在系統間模糊地段踩坑。所以，重構後須要將路由邏輯所有收斂到路由系統，這包含兩個層面：

代碼層面——新路由系統須要整合老路由系統邏輯（Java代碼）和上游收銀臺中的路由邏輯（PHP），劃清上下游的職責邊界。
存儲層面——原來收銀臺或者交易系統會分別從配置中心、緩存、數據庫表、代碼配置文件、老路由系統接口中獲取不一樣的數據，數據沒法被集中管理。重構以後，所有數據都由新路由管理集中管理，任何上游的數據需求都經過RPC接口請求路由系統。

(2) 系統容量和時效性

因爲路由邏輯和基礎數據都收斂到新系統，重構後的路由將成爲支付路徑上的關鍵環節，用戶在美團點評的每次支付交易至少會調用一次路由系統。根據目前美團點評的體量，這對路由系統的峯值容量提出考驗。另外一方面，因爲重構系統須要兼容以前的老邏輯，這會致使有些接口的響應時間達到幾百毫秒甚至超過一秒，對內網調用來講是不可接受的。

水平擴容機器是能夠解決第一個問題的，可是沒法解決第二個問題。基於路由的業務場景是典型的「讀多寫少」、且基礎數據總量有限的狀況，數據徹底能夠緩存在業務機器上，這樣能極大地減小對數據庫的讀取次數。採用本地緩存的方案後，系統接口響應時間由秒級降爲毫秒級。因爲下降了請求處理時間，一個線程的處理能力也相應提升了數十倍，系統的總體處理能力獲得量級提高。

(3) 系統容災方案

路由系統的容災主要從兩方面實現：

下降對外部組件的依賴性——「本地緩存」的引入使得路由系統處理實時業務請求時，不直接讀取外部的緩存中心或者數據庫，這樣避免了這些基礎組件可能帶來的風險。

制定服務異常時的備用方案——若是路由系統異常將會直接致使用戶沒法支付，於是收銀臺系統須要對路由進行依賴降級，採用的方案是：
a. 路由系統定時從數據庫中讀取基礎數據，並根據路由策略產生兜底數據，同步到配置中心；
b. 當路由系統異常，收銀臺系統將降級讀取兜底數據，保證用戶完成支付。

故障處理流程

支付通道自動化管理的半自動化階段持續時間是2016.11至今，故障處理自動切走、自動切回，一次通道故障的處理流程以下：
(1) 監控檢測到通道成功率異常發送報警消息給美團點評技術人員，同時自動將通道置爲不可用；
(2) 收銀臺實時讀取通道配置，收銀臺不會再將流量放入該通道，從而將故障通道的流量所有切走；
(3) 監控在將通道置爲不可用一段時間後，嘗試對故障通道放部份量進來用以檢測通道是否正常；
(4) 若是放進來的這部份量成功率正常，監控則繼續放2倍的量，直到通道全量，監控將通道置爲可用；
(5) 若是放進來的這部份量成功率異常，則將通道直接置爲不可用，監控隔一段時間後再繼續進行放量，直到通道恢復爲可用；
(6) 美團點評技術在發現通道故障後，能夠向銀行或第三方詢問故障緣由，並記錄，留做往後分析使用。

系統演進到這裏，支付通道的管理已經基本實現了徹底自動化，只有故障緣由等附加信息須要人工獲取。

主要解決的問題

(1) 渠道路由重構和優化後提供了根據配比放量的功能和通道故障發送推送消息到各個須要知道通道狀態變化的系統；
(2) 監控能夠根據通道當前狀態和成功率狀況，能夠主動選擇將通道置爲故障、開始放量、繼續放量、切回故障、置爲正常等操做，檢測通道是否恢復，以實現支付通道自動管理的功能；
(3) 釋放了大量須要處理通道故障的人力資源；
(4) 及時周知到相關係統，下降故障影響，協助業務方系統進行故障分析。

各階段系統優化數據對比

支付通道管理系統在故障處理上的性能對比數據以下：

階段	初級階段	半自動階段	全自動階段
平均故障響應時間	20min	1min	1min
平均人力成本	60min	43min	2min
平均故障恢復延遲	180min	180min	20min

注：
故障響應時間：從通道發生故障到通道被置爲不可用的時間；
平均人力成本：故障發生期間須要耗費人力；
平均故障恢復延遲：銀行或第三方真正恢復到美團打開通道入口的時間。

總結與展望

支付通道管理系統的演進過程就是一個完整的支付通道自動化管理的實踐之路，自動化不只提高了系統故障處理能力，提高系統可用性，還釋放了大量人力。隨着支付系統的發展，後續支付通道自動化管理系統還將面臨新的問題和挑戰。總結實踐的過程，主要有如下兩點：

監控系統的完善和優化

從監控系統從單一的成功率計算到覆蓋幾乎全部維度，以及後續的與其餘系統聯動實現支付通道自動化管理的功能，對於維護和提高系統可用性和穩定性起到了很是重要的做用。

渠道路由功能的完善

渠道路由提供了通道切走和回切放量功能，與監控系統完美的配合，實現支付通道的自動化管理功能。

目前的支付通道自動化管理還須要在如下四個方面進行優化：

(1) 優化監控算法，將報警準確率95%提高到99%以上；
(2) 故障自動通知到銀行或第三方技術人員，徹底釋放故障處理耗費的人力；
(3) 實現銀行和第三方網關網絡異常的自動化處理；
(4) 渠道路由的回切放量，優先命中耐受力比較強（統計維度上客訴少）的用戶進行成功率探測，以減小對業務的影響。

 推薦一個Java架構技術交流羣：688583154裏面有Java工程化、分佈式、微服務、高性能、性能調優、Spring，MyBatis，Netty源碼設計模式分析等知識點講解與IT技術、IT職場、在線課程、學習資源分享等，特別注意：咱們是免費分享學習資源，阿里架構師分享知識，多年工做經驗的梳理和總結，帶着你們全面、科學地創建本身的技術體系和技術認知。進羣免費領取如下架構師學習資料：