由于公司人员变动, 接手一个内部支付中心系统, 所谓“支付中心”, 作用就是整合各种第三方支付, 对内给各个业务子系统提供统一支付调度. 架构如下:
对于支付系统, 少不了支付结果的“异步通知”, 上图中, ‘第三方支付’会给‘支付中心’通知, ‘支付中心’会给‘业务系统’通知.
在看完这个支付中心的‘异步通知’代码之后, 发现存在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 1h 2h