業務流程
上文提到因爲支付處理的流程複雜性，爲了不由於冗長的流程阻塞下降了處理效率，支付系統中多使用異步機制，將整個支付業務流程拆分爲多步處理。支付系統將流程劃分爲業務受理、支付前置和支付網關、終態獲取、結果處理四個大部分，各部分之間以消息隊列或系統之間的交互分隔。風控和路由屬於支付前置服務，但因爲其重要性和複雜性，將它們提出來分別介紹。javascript
下面的圖是兩種典型的交易時序圖：php
業務受理
業務受理接口是與商戶系統的交互處，主要功能爲接受交易業務，響應給商戶的是受理結果，而並不是交易結果，交易結果會經過異步方式告知商戶。css
爲了考慮接口的安全性，受理接口要依次驗證支付請求報文的安全性、商戶的權限、參數的合法性。爲了保證保證交易入口的可用性，特殊接口還要限制商戶的請求頻率。html
因爲受理結果要同步響應給商戶，很長的驗證流程是不合適的。要儘可能保證受理接口進行的是基礎驗證，對其餘複雜的的驗證流程，進行異步處理，驗證沒法經過的再置交易爲失敗爲好。java
受理接口還須要特別注意到的一點是要保證系統受理和接口響應的原子性，即要保證響應給商戶的受理結果是真實的，可查詢的。要保證受理結果響應給商戶後，該筆交易要能查詢到，這時候便須要數據落地和響應商戶的順序了。爲了保證安全，要在數據落地後再將受理結果響應給商戶，避免出現數據丟失的狀況。python
此時要開始異步流程的第一步了，受理成功待處理的交易應該在消息隊列內。nginx
風控
風控的概念上文已提過，這裏說一下風控系統的簡單實現。git
首先是交易量風控，交易金額過大、交易頻率太高的交易都是須要注意的，經過配置對不一樣交易分類的閾值限制，將可疑交易打上風控標籤，再添加後續驗證來確認。github
而後是交易慣性風控，這就須要對比用戶畫像來肯定了。經過分析用戶的屢次支付習慣，爲用戶「畫」一張大概的「畫像」，支付時對比是否符合其支付習慣，對異常的交易進行後續驗證。（因爲用戶支付的量不大，無此功能，再也不多提）web
後續驗證能夠分交互性交易和非交互性交易來分別處理，對非交互性交易，如代收或代付，並不要求交易的實時性，能夠採用接口審覈或人工審覈的方式。而交互性交易，如收銀臺交易，審覈確定不能達到要求的實時性，添加驗證步驟，如手機驗證碼等二次驗證則十分適用。
支付路由
支付路由，簡單的說就是選擇一條支付通道。支付通道要有必定維度上的優先級，這裏提到優先級，是由於支付通道偶爾會由於系統維護、銀行維護等緣由關閉，那麼在可選通道之間要有優先級來調控優先通道不可用時的替代通道。單純的通道路由在技術上實現起來可能很是簡單，但是通道路由要考慮的因素還有不少：
- 三方系統三方系統支持：最基本的要求了，通常三方系統對帳戶類型、卡類型、銀行等有不一樣的支持範圍。
- 便宜：很直觀的要求，爲了公司的開銷考慮，能使用價格低的通道最好。雖然低價格在必定程度上表明着低質量，會埋下各類各樣甚至難以想象的坑。
- 通道限流：因爲各個系統對通道的限制不一樣，在達到通道上限後天然要限制交易頻率。還有些三方系統比較傲嬌，接了咱們的支付通道卻不用也不行，因此支付通道的流量還要有下限。
- 動態調節：動態調節是通道路由的徹底態會有的功能，和分佈式系統中對各個服務器的監控相似，實時監控通道的狀態，在判斷通道的失敗率達到某個閾值後自動關閉通道，使用替換通道。並間隔一段試探通道的狀態，在其交易恢復正常後再將通道打開。
支付網關
支付網關是支付系統與三方系統的交互接口，支付網關的設計要考慮的重點是報文的交互。除了普通系統要進行的參數驗證、內外系統參數映射、各類請求類的包裝外，支付系統要額外考慮的有：
- 報文簽名和加密：這個各個支付系統會有不一樣的要求，見招拆招便可，這就須要掌握一些加密知識了，也是我以前花不少時間研究通訊加密的緣由（提及來還挺敬業 = =）。
- 日誌：網關日誌很重要！！！不光是做爲與三方系統交互的憑證，也是排查錯誤的關鍵信息。通常會將原始（強調一下）報文記錄下來，包括請求參數、響應參數、耗時等信息。
終態獲取
支付系統的交易除了需求實時性較強的快捷支付外，其餘交易類型通常都是異步，那麼終態的獲取就靠主動查詢和異步回調通知。
異步回調通知：異步回調通知是最基本的獲取三方終態的方式了，即支付系統在支付請求時提供一個通知地址，在三方系統處理完交易後請求此地址並附帶交易結果信息。須要注意報文驗籤防止報文僞造。另外通知通常會屢次通知以確保通知到達，還要給三方系統符合規則的響應，以在本身系統處理完交易後，告訴三方系統中止通知。
主動查詢：主動查詢是對異步回調通知的保證。在有的系統（呵呵）不提供回調通知或本身系統故障通知失敗，或對交易的實時性要求很高，而三方系統的異步通知延遲嚴重時，主動查詢就很是重要了。須要注意查詢時機，必定要確認三方系統已徹底受理了交易且可查詢後再調用查詢接口。
結果處理
獲取到支付結果後，不光要及時更新本身系統內的支付狀態，還要考慮對交易的後續處理：
- 結果通知：同三方系統通知支付系統，支付系統要將支付結果及時通知商戶。爲了確保通知成功，重試機制是必不可少的，這裏考慮三方系統通知支付系統的邏輯。
- 推送帳務系統：因爲支付系統的帳務由帳務和資金管理系統負責，支付系統只負責交易結果的推送。單獨的帳務和資金管理系統功能介紹見下；
- 觸發統計：爲了保證交易統計的實時性，在支付成功後儘快統計支付結果。
支付結果在確認後正常流程內再也不變更，爲了減小支付結果的處理對交易表的侵入性，可使用另外一張 交易終態表 來承擔交易結果處理的記錄。至於兩張表的數據同步，使用數據庫的事務便可。
帳務和資金管理
帳務和資金管理系統是爲了在資金流上確保交易的正確。
支付系統之間通常在第二日進行前一日交易的資金結算。帳務負責維護各個商戶與支付通道的對應銀行帳戶，並根據當日的交易結果彙總出資金的應收應付，第二日財務人員根據應收應付和實收實付進行轉帳和核銷。
附屬服務
附屬服務不屬於交易流程的一部分，但它們也是必不可少的部分，對異常交易的排查、修復有着重要意義。
對帳
對帳是對前一日交易在全局上的對照，不一樣於帳務和資金管理系統，對帳是在數據流上肯定交易的正確性，通常的對帳流程以下：
- 下載對帳文件 針對各三方系統的下載方式：FTP/HTTP 獲取到對帳文件
- 標準化處理：將格式爲 txt/xml/cvs/zip 的三方系統對帳文件處理成一種選用格式；
- 本地對帳準備：能夠根據數據量的大小，從源庫/從庫/nosql/文件方式準備與三方系統對帳文件的對比
- 兩個帳務數據對比。
- 差別數據修復(人工/後續)
監控
監控在每一個完備的系統都會存在，不過通常是運維層面上的，支付系統更多的是在業務層面上的監控。監控系統通常監控交易異常、通道異常等影響正常交易的情況，並及時報警告知運營或技術人員。
監控方式通常有：
- 統計法：定時對比統計數據與監控閾值，在統計數據的異常比例超出監控閾值時觸發報警。
- 試探法：以測試交易來定時試探系統的穩定性和三方通道的穩定性。
- 埋點法：在支付關鍵節點埋點，並檢驗交易狀態是否在指望狀態。
統計
統計數據通常包括，交易總額，手續費，交易總筆數，成功率等，通常根據業務線、支付通道、銀行等維度來分別統計。
對運營人員來講，統計數據能夠幫助在全局上觀察交易情況，做出決策；對於業務流程來講，統計數據能夠做爲通道路由的基礎，如在支付通道交易異常率較高時下降其優先級等，也能夠爲監控系統提供數據；對技術人員來講，統計能夠幫助有方向地優化系統。
小結
理清了支付的各個必備模塊，系統設計應該就會很清晰了，完成了系統設計，後續的工做就剩下代碼的堆砌和完善了。
支付服務中的每一塊都有必定的「門道」，有機會和必要的話，會單獨拿出來一塊寫。
感謝關注。