背景
目前我就職於大樹網絡科技，主要的產品是給信用優質都用戶提供線上都信用貸款。而我所在的組是支付組，主要對接第三方支付。支付用於放款和還款兩個操作，本次主要講還款（其實兩個都差不多）。目前還款主要有一下這幾種方式：
- 用戶通過APP主動還款
- 系統發起定時扣款任務
- 催收人員通過內部作業系統，發起扣款
大樹沒有支付牌照，只能通過第三方支付來完成扣款操作。我們對接了好多第三方支付服務，比如京東兩方代扣、京東快捷、翼支付、網信支付等（這裏把代扣和快捷區分開來了，因爲業務處理上有些不同）。不同的第三方支付，支持的銀行和對應的限額不同，穩定性和費用也不相同。這裏就需要考慮到通道到可用性和穩定性還有費用等問題，我們通過支付路由選擇出最優的通道（支付路由下期再講）。因爲第三方支付的各種問題，這裏支付我們需要保證業務上的一致性，這也是本文介紹的主題。
支付面臨的問題
支付結果一致性
1、由於真正的支付有第三方提供，存在不穩定性、且有小部分的交易需要很長時間才能確認支付結果。這裏的一致性指的是第三方支付服務與我方系統的支付結果的一致性
2、我們採用的是微服務的方式，支付的成功並不表示着這次還款計劃的成功，需要保證我們系統之間的信息一致性
信息追蹤
我覺得一旦涉及到金錢，就需要格外小心。有句話：“有錢能使鬼推磨”。代扣能不聲不響的從你銀行卡扣錢，可怕不！！！一旦觸及到了別人兜裏的錢，就需要有理由(貸款協議)。還有跟第三方支付的扯皮（哈哈，在正式的業務當中沒出現過，因爲都以銀行爲準），真的到了扯皮，還是需要有證據的
最終支付架構
上圖是我設計都最終架構圖（歡迎大佬指正）。下面我將怎麼演進的和注意點分析一下，懂了的大佬可以隨意
正常流程
分佈式鎖
這裏使用分佈式鎖和重複訂單檢查目的是冪等，防止支付多次提交。支付服務提供的是dubbo服務，dubbo默認重試3次。用戶的一次還款，被扣了三次。好可怕，投訴投訴！！！
支付路由
1、省錢，省錢，省錢，這是支付路由選擇支付通道的最主要的規則。 哪個通道省錢，基本會優先考慮這個通道。
2、提升支付產品的QOS。這體現在系統的可靠性、穩定性、性能和可用性上。通過屏蔽掉無法連接、不穩定、性能低的通道來提升這些指標。
本次不講，留到後面😁
第三方支付
第三方支付主要涉及到加密、簽名等保證數據的一致性
本次不講，留到後面😁
第三方支付回調
第三方的支付一般都是異步的，上面的發起支付，第三方支付系統只是收單。異步會調用銀行的指令（這是以前的代扣，跟銀行。現在應該會調用網聯繫統）。支付成功或失敗後，第三方系統會進行回調
發送MQ給下游
發送給關注支付這個事件的系統，後續由它們去處理
改進一——添加日誌追蹤
日誌
可以看到每一步調用第三方之前都會插入一條日誌記錄，並在響應之後更新日誌。這裏日誌我們需要記錄什麼呢？
1、支付訂單的一些信息，比方支付發起方式、扣款銀行卡等
2、支付操作
3、請求第三方信息
4、第三方返回信息
改進二——查詢
查詢
天啊，這個第三方支付爲什麼沒回調！！！沒回調有2種
1、網絡抖動丟掉了
2、他們本來就沒有回調這樣的接口😢（我碰到過）
查詢不僅能彌補對方系統的不足，還能完善我們的系統。
發送MQ
記錄該條查詢
如果沒發生MQ，在系統中輪詢。可能機器突然掛了，這條查詢命令就消失了。
緩衝
有好些第三方支付結果獲取一般在3s左右。剛發起支付去查詢，很大的概率還是在支付處理中。可以到消息隊列裏緩衝一下
改進三——未知訂單
上述的系統是不是很完美了呢？當然沒有，我們想一下下面幾種情況
當第三方系統查詢接口GG的時候，我們還是無腦的循環查詢嗎？這樣肯定有問題
如果我想知道哪些支付是在支付處理中，我們是不是查詢數據庫
select * from pay_order where status = "處理中"
如果該表很大呢？而且status又不能做索引（分辨率低）。
- 如果程序處理到第三方支付支付，這時候程序掛了（假設該第三方支付沒回調）該筆訂單是不是就無法知道狀態了
綜上，出來了下面的架構
未知訂單--超過10分鐘
這裏說的未知訂單狀態不是支付的狀態。而是該未知訂單是否可以查詢的狀態。這裏有1個定時任務：
- 定時任務發起查詢，查詢的是未知訂單創建時間超過10分鐘
爲什麼要這麼設計呢？
想一下這種情況，當支付請求進來，流程到了支付路由這一步驟。這時剛好發起了定時任務。查詢第三方支付服務，第三方還沒有收單（還沒接收到我們支付請求），這是會返回無效訂單。我們系統會認爲該支付爲失敗。有這樣10分鐘的經驗值。
發送查詢MQ，次數限制
每次發送查詢MQ，要對查詢次數做限制，不要無腦查詢（對方系統慢了，很大原因是它處理不過來了，我們也要給別人休息休息）
本地事務
以上三個地方需要做本地事務，作用的話就不講了
總結
上面就是我們支付服務中的核心交易系統，主要就是保證交易核心系統與第三方支付服務的一致性，交易核心系統與其他下游系統的一致性。
在我的理解裏最終一致性的保證需要
1、“記錄”
2、“補償”
在做所有的不確定的事情之前，先把事情記錄下來，然後去做不確定的事情，結果可能是：成功、失敗或是不確定，“不確定”（例如超時等）可以等價爲失敗。成功就可以把記錄的東西清理掉了，對於失敗和不確定，可以依靠定時任務等方式把所有失敗的事情重新搞一遍，直到成功爲止。