支付模块设计

看方案设计的文章时候，发现里面给的代码相对都比较少，因为每个人设计的方案可能都稍微有点差别，或者方案就算一样，实现出来代码再命名上，组织上也有些许区别，方案设计，理解其思想是第一位。
这次文章在解释上比较多，但不妨其干货性，其主要提取的是一个线上运行10年的，大型分布式系统的支付部分设计经验。

背景

每个公司都会有自己的支付账户，但是账户涉及到资金安全，不可能让有、其它系统都知道支付的密钥，配置等信息，也不可能让公司的系统都直接和其它平台如支付宝，微信，银联等打交道。
因此公司都会有自己支付系统，其它系统在支付的时候调用本系统。本系统之外的系统可以称为业务系统。
交易系统由很多操作，比如冻结资金、扣钱，解冻资金，关闭交易，交易成功后是否履约等等。这些统称为操作

场景

需求

业务系统调用支付系统进行操作，支付系统和真正的支付平台打交道，并且将支付平台返回的结果返回给业务系统。平台系统未必能及时返回结果，或者支付系统未必能及时返回结果，有时将结果再异步回调回去。
有时可能第三方支付平台未能及时返回结果，并且也未发生回调，那么需要自己主动查询，同步结果，再同步给业务。
以上基本上是公司内部支付系统经常要干的事，其它第三方支付平台的处理逻辑都类似。那么根据需求

设计

需要保存的内容：

• 公司操作记录
• 第三方平台回调记录
• 业务系统回调记录
• 第三方平台操作的记录
  公司操作记录详细：
• 操作类型
• 订单号(内部订单号)
• 第三方平台唯一标识(重要字段，后续的关于第三方操作都与此有关，相当于一个大的事情，理解为第三方订单号)
• 业务请求流水号(唯一的，用于内部排查问题以及追踪)
• 我们向第三方平台发送的请求流水号(用于第三方平台回调我们时候确定操作记录)
• 用户id(可选)
• 第三方用户id
• 总金额
• 剩余金额
• 每次操作金额
• 业务请求我们的时间(Datetime)
• 我们响应业务的时间
• 业务请求我们的参数
• 我们响应业务的内容
• 业务想要的回调
• 业务想要回调的参数透传
• 我们请求第三方平台的参数
• 第三方平台响应我们的内容
• 第三方平台是否操作成功
• 我们请求第三方平台的时间
• 第三方平台响应我们的时间
• 我们回调业务的参数
• 回调业务后，业务返回的内容
• 我们回调业务的状态
• 如果我们回调业务失败，下次回调的时间
  然后一般表都有几个必备字段就说了，创建时间，修改时间，创建人，修改人，备注
  业务回调 && 第三方平台回调：这两个功能类似，主要存储信息，一般不修改
• 回调请求参数
• 回调响应参数
• 回调请求时间
• 回调响应时间
• 回调状态
• 备注，以及几个业务相关的重要标识
  第三方平台操作记录：理解为公司操作的冗余部分，冗余存储可以加快查询速度
• 第三方的标识
• 第三方的各种信息
• 第三方用户id
• 第三方记录金额
• 第三方状态
• 等信息
  这个是我画的一张图，简化了很多，但是大体流程就是这样：
  虚线的代表是异步操作
  

代码层面考虑

• 给业务的外部服务
• 给业务的DTO
• 给业务的RE(特定业务的响应)
• 远程调用Result(一般是所有系统通用Result)
• 回调DTO
• 第三方平台回调我们的Controller
• 定时任务
  其余的一般是开发通用技术，DAO层操作，分布式锁，业务交互协议，MQ，配置中心等等，代码上如何进行复用，如何面对多变的业务需求，每个人编码的功力不同最终的结果也不一样，但系统设计上不会有太多的变化

最后

设计上的东西，重点是理解其设计，本篇主要作为参考，希望能帮助到大家。