为了账号安全,请及时绑定邮箱和手机立即绑定

支付模块设计

标签:
架构 微服务

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

背景

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

场景

需求

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

设计

需要保存的内容:

  • 公司操作记录
  • 第三方平台回调记录
  • 业务系统回调记录
  • 第三方平台操作的记录
    公司操作记录详细:
  • 操作类型
  • 订单号(内部订单号)
  • 第三方平台唯一标识(重要字段,后续的关于第三方操作都与此有关,相当于一个大的事情,理解为第三方订单号)
  • 业务请求流水号(唯一的,用于内部排查问题以及追踪)
  • 我们向第三方平台发送的请求流水号(用于第三方平台回调我们时候确定操作记录)
  • 用户id(可选)
  • 第三方用户id
  • 总金额
  • 剩余金额
  • 每次操作金额
  • 业务请求我们的时间(Datetime)
  • 我们响应业务的时间
  • 业务请求我们的参数
  • 我们响应业务的内容
  • 业务想要的回调
  • 业务想要回调的参数透传
  • 我们请求第三方平台的参数
  • 第三方平台响应我们的内容
  • 第三方平台是否操作成功
  • 我们请求第三方平台的时间
  • 第三方平台响应我们的时间
  • 我们回调业务的参数
  • 回调业务后,业务返回的内容
  • 我们回调业务的状态
  • 如果我们回调业务失败,下次回调的时间
    然后一般表都有几个必备字段就说了,创建时间,修改时间,创建人,修改人,备注
    业务回调 && 第三方平台回调:这两个功能类似,主要存储信息,一般不修改
  • 回调请求参数
  • 回调响应参数
  • 回调请求时间
  • 回调响应时间
  • 回调状态
  • 备注,以及几个业务相关的重要标识
    第三方平台操作记录:理解为公司操作的冗余部分,冗余存储可以加快查询速度
  • 第三方的标识
  • 第三方的各种信息
  • 第三方用户id
  • 第三方记录金额
  • 第三方状态
  • 等信息
    这个是我画的一张图,简化了很多,但是大体流程就是这样:
    虚线的代表是异步操作
代码层面考虑
  • 给业务的外部服务
  • 给业务的DTO
  • 给业务的RE(特定业务的响应)
  • 远程调用Result(一般是所有系统通用Result)
  • 回调DTO
  • 第三方平台回调我们的Controller
  • 定时任务
    其余的一般是开发通用技术,DAO层操作,分布式锁,业务交互协议,MQ,配置中心等等,代码上如何进行复用,如何面对多变的业务需求,每个人编码的功力不同最终的结果也不一样,但系统设计上不会有太多的变化

最后

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

点击查看更多内容
TA 点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
JAVA开发工程师
手记
粉丝
1.1万
获赞与收藏
1544

关注作者,订阅最新文章

阅读免费教程

  • 推荐
  • 评论
  • 收藏
  • 共同学习,写下你的评论
感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
今天注册有机会得

100积分直接送

付费专栏免费学

大额优惠券免费领

立即参与 放弃机会
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消