支付模块设计
看方案设计的文章时候，发现里面给的代码相对都比较少，因为每个人设计的方案可能都稍微有点差别，或者方案就算一样，实现出来代码再命名上，组织上也有些许区别，方案设计，理解其思想是第一位。
这次文章在解释上比较多，但不妨其干货性，其主要提取的是一个线上运行10年的，大型分布式系统的支付部分设计经验。
背景
每个公司都会有自己的支付账户，但是账户涉及到资金安全，不可能让有、其它系统都知道支付的密钥，配置等信息，也不可能让公司的系统都直接和其它平台如支付宝，微信，银联等打交道。
因此公司都会有自己支付系统，其它系统在支付的时候调用本系统。本系统之外的系统可以称为业务系统。
交易系统由很多操作，比如冻结资金、扣钱，解冻资金，关闭交易，交易成功后是否履约等等。这些统称为操作
场景
需求
业务系统调用支付系统进行操作，支付系统和真正的支付平台打交道，并且将支付平台返回的结果返回给业务系统。平台系统未必能及时返回结果，或者支付系统未必能及时返回结果，有时将结果再异步回调回去。
有时可能第三方支付平台未能及时返回结果，并且也未发生回调，那么需要自己主动查询，同步结果，再同步给业务。
以上基本上是公司内部支付系统经常要干的事，其它第三方支付平台的处理逻辑都类似。那么根据需求
设计
需要保存的内容：
- 公司操作记录
- 第三方平台回调记录
- 业务系统回调记录
- 第三方平台操作的记录
公司操作记录详细：
- 操作类型
- 订单号(内部订单号)
- 第三方平台唯一标识(重要字段，后续的关于第三方操作都与此有关，相当于一个大的事情，理解为第三方订单号)
- 业务请求流水号(唯一的，用于内部排查问题以及追踪)
- 我们向第三方平台发送的请求流水号(用于第三方平台回调我们时候确定操作记录)
- 用户id(可选)
- 第三方用户id
- 总金额
- 剩余金额
- 每次操作金额
- 业务请求我们的时间(Datetime)
- 我们响应业务的时间
- 业务请求我们的参数
- 我们响应业务的内容
- 业务想要的回调
- 业务想要回调的参数透传
- 我们请求第三方平台的参数
- 第三方平台响应我们的内容
- 第三方平台是否操作成功
- 我们请求第三方平台的时间
- 第三方平台响应我们的时间
- 我们回调业务的参数
- 回调业务后，业务返回的内容
- 我们回调业务的状态
- 如果我们回调业务失败，下次回调的时间
然后一般表都有几个必备字段就说了，创建时间，修改时间，创建人，修改人，备注
业务回调 && 第三方平台回调：这两个功能类似，主要存储信息，一般不修改
- 回调请求参数
- 回调响应参数
- 回调请求时间
- 回调响应时间
- 回调状态
- 备注，以及几个业务相关的重要标识
第三方平台操作记录：理解为公司操作的冗余部分，冗余存储可以加快查询速度
- 第三方的标识
- 第三方的各种信息
- 第三方用户id
- 第三方记录金额
- 第三方状态
- 等信息
这个是我画的一张图，简化了很多，但是大体流程就是这样：
虚线的代表是异步操作
image
代码层面考虑
- 给业务的外部服务
- 给业务的DTO
- 给业务的RE(特定业务的响应)
- 远程调用Result(一般是所有系统通用Result)
- 回调DTO
- 第三方平台回调我们的Controller
- 定时任务
其余的一般是开发通用技术，DAO层操作，分布式锁，业务交互协议，MQ，配置中心等等，代码上如何进行复用，如何面对多变的业务需求，每个人编码的功力不同最终的结果也不一样，但系统设计上不会有太多的变化
几个业务相关的东西
预授权转支付失败后有失败记录，这些失败记录会影响用户重新下单，什么时候会关闭这些转支付失败记录？
1.租金代扣，如扣款成功后，立即将租金科目的全部转支付失败记录关闭
2.违章费用代扣，如扣款成功后，立即将违章科目的全部转支付失败记录关闭
- 合同结算冻结时，立即将租金科目所有的转支付失败记录关闭
- 违章费用结算后生成违章追款单，立即将违章费用科目所有的转支付失败记录关闭
最后
设计上的东西，重点是理解其设计，本篇主要作为参考，希望能帮助到大家。
