由於公司人員變動, 接手一個內部支付中心繫統, 所謂“支付中心”, 作用就是整合各種第三方支付, 對內給各個業務子系統提供統一支付排程. 結構如下:

對於支付系統, 少不了支付結果的“非同步通知”, 上圖中, ‘第三方支付’會給‘支付中心’通知, ‘支付中心’會給‘業務系統’通知. 

在看完這個支付中心的‘非同步通知’程式碼之後, 發現存在2個比較“坑”的問題, 應該需要改造一下.

問題

• 支付中心給業務系統的非同步通知, 是dubbo的方式.

對於回撥通知, 採用dubbo反向依賴, 耦合度有點高, 因為支付中心需要維護各個業務系統的dependency.  每新接入一個子系統, 支付中心就得改程式碼, 打包上線, 這很不科學.

• 支付中心只給業務系統通知一次, 沒有補償.    

一次通知可能出現網路異常, 或者接受者處理失敗的情況,  顯然沒有補償是不太友好的.

改造

• dubbo改成http 

採用http方式, 支付中心不會反向依賴業務系統, 降低了耦合. http如果要走外網, 可以對引數進行簽名處理.

• 延時遞進補償 

採用RocketMQ延時訊息, 目前其支援的延時遞進等級

1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1