支付模組設計
看方案設計的文章時候，發現裡面給的程式碼相對都比較少，因為每個人設計的方案可能都稍微有點差別，或者方案就算一樣，實現出來程式碼再命名上，組織上也有些許區別，方案設計，理解其思想是第一位。
這次文章在解釋上比較多，但不妨其乾貨性，其主要提取的是一個線上執行10年的，大型分散式系統的支付部分設計經驗。
背景
每個公司都會有自己的支付賬戶，但是賬戶涉及到資金安全，不可能讓有、其它系統都知道支付的金鑰，配置等資訊，也不可能讓公司的系統都直接和其它平臺如支付寶，微信，銀聯等打交道。
因此公司都會有自己支付系統，其它系統在支付的時候呼叫本系統。 本系統之外的系統可以稱為業務系統。
交易系統由很多操作，比如凍結資金、扣錢，解凍資金，關閉交易，交易成功後是否履約等等。這些統稱為 操作
場景
需求
業務系統呼叫支付系統進行操作，支付系統和真正的支付平臺打交道，並且將支付平臺返回的結果返回給業務系統。平臺系統未必能及時返回結果，或者支付系統未必能及時返回結果，有時將結果再非同步回調回去。
有時可能第三方支付平臺未能及時返回結果，並且也未發生回撥，那麼需要自己主動查詢，同步結果，再同步給業務。
以上基本上是公司內部支付系統經常要乾的事，其它第三方支付平臺的處理邏輯都類似。那麼根據需求
設計
需要儲存的內容：
- 公司操作記錄
- 第三方平臺回撥記錄
- 業務系統回撥記錄
- 第三方平臺操作的記錄
公司操作記錄詳細：
- 操作型別
- 訂單號(內部訂單號)
- 第三方平臺唯一標識(重要欄位，後續的關於第三方操作都與此有關，相當於一個大的事情，理解為第三方訂單號)
- 業務請求流水號(唯一的，用於內部排查問題以及追蹤)
- 我們向第三方平臺傳送的請求流水號(用於第三方平臺回撥我們時候確定操作記錄)
- 使用者id(可選)
- 第三方使用者id
- 總金額
- 剩餘金額
- 每次操作金額
- 業務請求我們的時間(Datetime)
- 我們響應業務的時間
- 業務請求我們的引數
- 我們響應業務的內容
- 業務想要的回撥
- 業務想要回調的引數透傳
- 我們請求第三方平臺的引數
- 第三方平臺響應我們的內容
- 第三方平臺是否操作成功
- 我們請求第三方平臺的時間
- 第三方平臺響應我們的時間
- 我們回撥業務的引數
- 回撥業務後，業務返回的內容
- 我們回撥業務的狀態
- 如果我們回撥業務失敗，下次回撥的時間
然後一般表都有幾個必備欄位就說了，建立時間，修改時間，建立人，修改人，備註
業務回撥 && 第三方平臺回撥：這兩個功能類似，主要儲存資訊，一般不修改
- 回撥請求引數
- 回撥響應引數
- 回撥請求時間
- 回撥響應時間
- 回撥狀態
- 備註，以及幾個業務相關的重要標識
第三方平臺操作記錄：理解為公司操作的冗餘部分，冗餘儲存可以加快查詢速度
- 第三方的標識
- 第三方的各種資訊
- 第三方使用者id
- 第三方記錄金額
- 第三方狀態
- 等資訊
這個是我畫的一張圖，簡化了很多，但是大體流程就是這樣：
虛線的代表是非同步操作
image
程式碼層面考慮
- 給業務的外部服務
- 給業務的DTO
- 給業務的RE(特定業務的響應)
- 遠端呼叫Result(一般是所有系統通用Result)
- 回撥DTO
- 第三方平臺回撥我們的Controller
- 定時任務
其餘的一般是開發通用技術，DAO層操作，分散式鎖，業務互動協議，MQ，配置中心等等，程式碼上如何進行復用，如何面對多變的業務需求，每個人編碼的功力不同最終的結果也不一樣，但系統設計上不會有太多的變化
最後
設計上的東西，重點是理解其設計，本篇主要作為參考，希望能幫助到大家。