58集團支付閘道器設計
說到支付閘道器，首先看一下閘道器的定義，閘道器的作用是實現網路之間的通訊連結，包含兩個基本功能：網間連線和協議轉換。 同理，商戶業務系統中的支付板塊實現的就是商戶業務系統與銀行支付系統之間的連結，所起到的作用是類似的，可以被看作為一個閘道器。
因此，本文要講的支付閘道器設計，其實就是商戶業務系統的支付板塊設計，下文特指58集團支付閘道器的設計，但本文重在“閘道器”，不在“支付”。也所以，支付閘道器業務特性要求的功能方面就不再展開了，只介紹支付閘道器在通用閘道器設計要求上的功能部分，包括統一介面、渠道路由、安全校驗、許可權校驗、IP白名單、流量削鋒、服務探活、監控報警、負載均衡等。
支付閘道器由來
初期，58支付系統為58集團各個業務線提供收銀臺與充值頁（支付paycenter系統）的收款功能，58財務系統（apply系統）同樣為各個業務線提供了打款功能，根據使用者及業務要求，需要提供多家銀行收付款支援。初期為了快速迭代，通過分別直接對接第三方支付的系統介面來完成功能開發。這時可以理解為第三方支付系統就是58支付體系的閘道器。
後期，隨著公司業務發展及商務合作，58支付系統及58財務系統需要對接多家第三方支付服務，這時候需要解決的問題是如何簡單方便接入多家第三方支付服務，另外對58支付體系的需求也發生了變化，支付閘道器的位置也需要進一步前移，對58支付體系提出了更高的要求。這時我們決定搭建自己的支付閘道器，並針對常規業務及需求抽象出通用的功能模組。
支付閘道器基礎設計
1）統一介面
2）渠道路由
3）安全校驗
4）許可權校驗
5）IP表名單
6）流量削峰
7）監控報警
8）服務探活
9）負載均衡
統一介面
不同的第三方支付服務，它們針對基礎的收付款功能介面，各自有自己的介面引數及返回值格式要求。閘道器需要提供統一通用的介面，規定其引數及返回值，為上層業務遮蔽第三方支付服務介面的複雜性，這就要求支付閘道器需要具有介面適配能力。
下圖以連連收款與易寶收款為例，展現“統一介面”設計架構與處理流程。
注：以上設計使用到介面卡模式實現。
渠道路由
接著上一部分，閘道器該如何選擇或路由到對應的第三方支付渠道，例如是通過微信或是支付寶，或是其他第三方支付渠道，閘道器提供多種策略，下面簡單介紹兩種。
1）渠道id策略路由：閘道器接入方通過顯示傳遞渠道id方式，例如收銀臺預設選擇微信收款，則顯示傳遞給閘道器對應的微信渠道id，則閘道器通過渠道配置資訊，選擇微信渠道進行收款。
2）費率計算策略路由：如上層業務未傳遞渠道id，則閘道器會根據判斷，選擇費率計算策略，例如第三方支付服務A每一筆收款都將收取1元手續費；第三方支付服務B單筆收款收取0.1%元手續費，則在單筆收款金額低於1000元時，走渠道B更為划算，反之則走渠道A更為划算。
下圖以連連收款與易寶收款為例，展現“渠道路由”設計架構與處理流程。
注：以上設計使用到策略模式實現。
安全校驗
如何判斷閘道器呼叫方是否擁有閘道器的接入許可權，我們採用校驗引數簽名的方式。
1）閘道器的接入方將被分配到一個接入id（parterId）及接入祕鑰（secretKey）。
2）呼叫方呼叫閘道器介面時除了傳遞必要引數，仍將傳遞接入id，及引數簽名sign值；為了安全強度還將加入當前時間戳now作為簽名引數並作為引數並一同傳遞，用於控制安全訪問的時間範圍。
3）閘道器接到呼叫請求時將校驗引數簽名的合法性。
下圖以收款為例，展現“安全校驗”設計處理流程。
注：以上設計使用到請求攔截器及引數簽名校驗方式進行實現。
許可權校驗
如何判斷閘道器呼叫方是否擁呼叫閘道器某一功能介面的許可權。
1）閘道器的接入方將被分配到一個接入id（parterId），呼叫閘道器某一個功能介面時將作為引數進行傳遞。
2）閘道器接到呼叫請求時將根據許可權配置，判斷對應的接入id是否擁有當前介面的訪問許可權。
下圖以收款為例，展現“許可權校驗”設計處理流程。
注：以上設計使用到請求攔截器實現。
IP白名單
如何判斷呼叫方請求是否來源於某一安全ip或網段。
下圖以收款為例，展現“IP白名單”設計的處理流程。
流量削峰
某些第三方支付服務介面對於一定時間內介面訪問次數存在一定限制，所以在流量高峰時，需要針對閘道器介面的請求進行流量削鋒。
1）根據rediszset資料結構實現時間視窗演算法邏輯，記錄一定時間視窗內閘道器訪問某第三方支付服務特定介面的訪問次數。
2）與該介面的單位時間內限流值配置進行比較，需要限流則放入將呼叫請求資訊放入redis佇列中。
3）非同步補償模組在流量低峰時，拉取redis佇列中的請求資訊，完成介面呼叫；再通過訊息模組，非同步通知閘道器的接入方呼叫結果。
注：通過rediszset實現的時間視窗演算法，此處不再展開，可自行查閱網上資料。
監控報警
閘道器的異常根據分類可分為業務異常及系統異常，可以採用AOP實現異常的統一捕獲並進行細化分類，通過按照不同的分類作為不同屬性，上報wmonitor實現閘道器的監控報警。
服務探活
第三方支付服務介面的可用性，即包括其自身可用性，往往也包括網路是否可達的問題。第三方支付服務不會主動通知閘道器其當前可用性資訊，所以需要閘道器實現探活模組，主動進行心跳檢測。
1）通過一定時間間隔視窗訪問各個第三方支付服務查詢介面，封裝探活模組。
2）當發現某個第三方支付服務不可用時，異常屬性上報WMonitor，進行報警；並將該服務介面標識為不可用狀態，作為支付閘道器的渠道路由功能的前置判斷依據。
負載均衡
關於負載均衡，支付閘道器不需要保證對第三方支付服務的呼叫請求進行負載均衡控制，而是由第三方支付服務介面自身保證其可靠性及健壯性。但是支付閘道器依然針對特殊業務場景做了一些呼叫請求的均衡工作，例如支付閘道器通過輪詢方式呼叫招行3臺前置機，方案也相對簡單，此處不表。
支付閘道器整體架構
支付閘道器除了上面介紹的一些通用閘道器的要求功能外，還有著支付體系要求的祕鑰服務、通知、配置、開放平臺、預算、推薦等基礎功能。
以下是支付閘道器的功能架構圖