支付系統整體設計：整體架構設計以及注意要點（一）
導讀： 在支付系統中，支付閘道器和支付渠道的對接是最核心的功能。其中支付閘道器是對外提供服務的介面，所有需要渠道支援的資金操作都需要通過閘道器分發到對應的渠道模組上。一旦定型，後續就很少，也很難調整。而支付渠道模組是接收閘道器的請求...
在支付系統中，支付閘道器和支付渠道的對接是最核心的功能。其中支付閘道器是對外提供服務的介面，所有需要渠道支援的資金操作都需要通過閘道器分發到對應的渠道模組上。一旦定型，後續就很少，也很難調整。而支付渠道模組是接收閘道器的請求，呼叫渠道介面執行真正的資金操作。每個渠道的介面，傳輸方式都不盡相同，所以在這裡，支付閘道器相對於支付渠道模組的作用，類似設計模式中的wrapper，封裝各個渠道的差異，對閘道器呈現統一的介面。而閘道器的功能是為業務提供通用介面，一些和渠道互動的公共操作，也會放置到閘道器中。
功能概述
支付系統對其他系統，特別是交易系統，提供的支付服務包括簽約，支付，退款，充值，轉帳，解約等。有些地方還會額外提供簽約並支付的介面，用於支援在支付過程中綁卡。 每個服務實現的流程也是基本類似，包括下單，取消訂單，退單，查單等操作。每個操作實現，都包括引數校驗，支付路由，生成訂單，風險評估，呼叫渠道服務，更新訂單和傳送訊息這7步，對於一些比較複雜的渠道服務，還會涉及到非同步同通知處理的步驟。這裡詳細介紹這些步驟的實現要點。
1. 執行引數校驗
所有的支付操作，都需要對輸入執行引數校驗，避免介面受到攻擊。
● 驗證輸入引數中各欄位的有效性驗證，比如使用者ID,商戶ID,價格，返回地址等引數。
● 驗證賬戶狀態。交易主體、交易對手等賬戶的狀態是處於可交易的狀態。
● 驗證訂單：如果涉及到預單，還需要驗證訂單號的有效性，訂單狀態是未支付。為了避免使用者快取某個URL地址，還需要校驗下單時間和支付時間是否超過預定的間隔。
● 驗證簽名。簽名也是為了防止支付介面被偽造。 一般簽名是使用分發給商戶的key來對輸入引數拼接成的字串做MD5 Hash或者RSA加密，然後作為一個引數隨其他引數一起提交到伺服器端。
2. 根據支付路由尋找合適的支付服務
根據使用者選擇的支付方式確定用來完成該操作的合適的支付渠道。使用者指定的支付方式不一定是最終的執行支付的渠道。比如使用者選擇通過工行信用卡來執行支付，但是我們沒有實現和工行的對接，而是可以通過第三方支付，比如支付寶、微信支付、易寶支付，或者銀聯來完成。那如何選擇合適的支付渠道，就通過支付路由來實現。支付路由會綜合考慮收費、渠道的可用性等因素來選擇最優方案。
3. 評估交易風險
檢查本次交易是否有風險。風控介面返回三種結果：阻斷交易、增強驗證和放行交易。
● 阻斷交易，說明該交易是高風險的，需要終止，不執行第5個步驟；
● 增強驗證，說明該交易有一定的風險，需要確認下是不是使用者本人在操作。這可以通過傳送簡訊驗證碼或者其他可以驗證使用者身份的方式來做校驗，驗證通過後，可以繼續執行該交易。
● 放行交易，即本次交易是安全的，可以繼續往下走。
4.生成交易訂單
將訂單資訊持久化到資料庫中。當訪問壓力大的時候，資料庫寫入會成為一個瓶頸。
5. 呼叫支付渠道提供的服務
所有的支付服務都需要第三方通道來完成執行。一般銀行渠道的呼叫比較簡單，可以直接返回結果。一些第三方支付，支付寶，微信支付等，會通過非同步介面來告知支付結果。
6. 更新訂單
對於同步返回的結果，需要在主執行緒中更新訂單的狀態，標記是支付成功還是失敗。對於非同步返回的渠道，需要在非同步程式中處理。
7. 傳送訊息
通過訊息來通知相關係統關於訂單的變更。風控，信用BI等，都需要依賴這資料做準實時計算。
8. 非同步通知
如上述流程，其中涉及到呼叫遠端介面，其延遲不可控。如果呼叫方一直阻塞等待，很容易超時。引入非同步通知機制，可以讓呼叫方在主執行緒中儘快返回，通過非同步執行緒來得到支付結果。對於通過非同步來獲取支付結果的渠道介面，也需要對應的在非同步通知中將結果返回給呼叫方。 非同步通知需要呼叫方提供一個回撥地址，一般以http或者https的方式。這就有技術風險，如果呼叫失敗，還需要重試。而重試不能過於頻繁，需要逐步拉大每一次重試的時間間隔。 在非同步處理程式中，訂單根據處理結果變更狀態後，也要發訊息通知相關係統。
整體架構
整體軟體參考架構如下所示：
