一、關於定位
今天和大家分享支付交易相關的系統，這是一個和資金打交道的系統，承載着電商平台的購物車、下單、支付渠道網關、訂單管理、虛擬資金賬戶、營銷優惠等重要業務，是電商平台不可或缺的系統。在不同的業務發展階段，支付交易系統需要的架構和投入的人力也不大一樣。
二、架構演進
1. 初期：單核階段
在平台發展初期，業務相對比較簡單，業務量也很小，一個系統就囊括了所有功能，很可能連部署都和其他功能混布。
這個階段的特點是：
系統簡單開發快，可擴展性差，無法快速滿足新商品支付的接入各個節點耦合度高，節點間多為事務性依賴，導致交易鏈路很長- 代碼越來越多，各個節點
並行開發越來越困難
為了解決這些問題，決定將各個節點進行服務化，采用分布式系統架構，把支付交易的各個節點服務化到后端，用來支撐多個前端應用。
2. 中期：服務化
除了服務化，這個架構里還加上了交易訂單，把訂單拆分為商品訂單和交易訂單，主要目的是讓支付和商品解藕，讓網關更加獨立，同時解決由於訂單信息變更帶來的觸發第三方渠道風控策略，導致無法支付的情況 ( 比如點擊過第三方支付，然后發生了訂單改價，那么同一個訂單號在第三方就不允許再次支付了 )
這個階段的特點是：
- 緩解了1.0的問題
- 分布式系統，保障
分布式事務的數據一致性是難點，這里不做深入介紹，可參考
- 跟着業務走
3. 后期：面向業務規則
3.0的支付交易系統應該是面向業務規則的系統，能夠滿足平台大多數的支付場景需要，業務規則可抽象，通過配置規則就能快速訂閱底層的支付基礎服務。
但這需要等業務發展到一定階段才可行。
三、支付網關
市面上有很多的渠道網關，那么渠道網關如何做選擇呢？我歸結為3個關鍵詞：主流、穩定、手續費
首先是主流,就是滿足大多數用戶的支付需求，市面上的網關巨頭如支付寶、微信基本就是標配
然后是穩定,一般主流的支付渠道穩定性都沒有問題，但為了更好的容錯容災，多接入一些渠道進行備份也是好的選擇
最后是手續費,當交易量達到一定量級，你會發現每筆交易支付的手續費也是一筆不菲的支出，降低手續費就成了需要去解決的問題
如何降低手續費呢？
- 通過商務手段進行談判，同時接入一些中小渠道，一般這些渠道為了發展會有較高的談判空間；
- 在界面上可以降低高手續費渠道的展示位置，當然不能影響交易額
- 對於有交易額階梯價的渠道，通過渠道引擎自動調整交易渠道，對用戶無感知，但這需要交易有一定渠道特點才能達到效果
四、財務清算
財務清算包括對賬並產出會計報表，它的設計有一定會計知識門檻,在系統初期，一般團隊都會因為快速支撐業務發展，而遺漏了這方面的設計。
財務清算系統和支付交易系統在交易數據上是緊耦合的，為了讓兩個系統有比較清晰的系統邊界，盡可能的解藕，我們的思路可以是這樣的
-
建立會計科目體系，結合自身平台的特性，在這些主科目下建立分科目
資產 = 負債+待清算+(收入-費用) -
支付交易系統產生交易流水
-
財務清算系統把交易流水錄入到科目體系
-
財務清算系統和第三方對賬單對賬