支付系统如何设计

支付系统如何设计？

支付系统整体可以看成由 交易核心 + 支付核心 两个大系统。交易系统关联了业务场景和底层支付，支付系统完成了调用支付工具到对账清算等一系列相关操作。

 

1、支付系统总览

核心系统交互

 

业务图谱

 

2、核心系统解析

交易核心

交易核心把公司的业务系统和底层支付关联起来，让业务系统专注于业务，不关心底层支付。

 

基础交易类型抽象

 

多表聚合 & 订单关联

 

支付核心

支付核心主要负责将多种支付类型进行抽象，变成充值、提现、退款、转账四种支付形态。同时，还要负责集成多种支付工具，对支付指令进行编排的等等。

 

支付核心预览

 

支付行为编排

其目的，是实现 插件式开发、支付规则可配置 的灵活开发方式。

 

异常处理

异常处理包括 重复支付、部分支付、金额不一致、其他异常 等异常场景。

 

渠道网关

 

资金核算

 

3、治理服务

平台统一上下文

通过确定系统边界，业务建模拆分之后，整个支付平台被拆分几十个服务，而如何保障在服务间流转业务信息不被丢失，是我们需要考虑的问题。平台统一上下文的要素信息(唯一业务标识码)，在整个支付平台链路中全程传递，被用来解决这个问题。

唯一要素标识码(四要素)，链路传递

• merchantId(商户)
• orderType(订单类型)
• subType(订单场景)
• payOrgNo(支付机构)

 

数据一致性治理

大型的支付公司，内部都有非常严格和完备的数据一致性方案，比如采用业务侵入性非常大的分布式事务等，以牺牲开发效率来提升数据的稳定，是非常有必要的。而业务公司，如果不采用分布式事务又有哪些应对策略呢？

CAS校验

交易核心、支付核心通过状态CAS防止并发。

update PayOrder set status = 'complete' where id=1 and status = 'process'

基于KVstore的分布式缓存锁

解决重复支付问题

 

幂等 & 异常补偿

全链路接口保持幂等

超时、网络异常等问题

• 基于Corgi准实时补偿
• 异常表补偿

 

对账

对账是数据一致性最后一道防线

内部业务准实时对账

T+1基于账单，内外对账

 

准实时对账

 

DB拆分

 

异步化

支付是整个交易链路的核心环节，异步化用来兼顾支付系统的 稳定性 和 执行效率。

 

消息异步化

• 基于支付交易核心订单数据
• 解耦、简化业务方数据获取

 

外部支付调用异步化

在外部支付中，经常需要服务方与第三方支付交互，获取预支付凭证，如上图所示。

在这种同步调用的情况下，由于需要跨外部网络，响应的RT会非常长，可能会出现跨秒的情况，由于是同步调用，会阻塞整个支付链路。一旦 RT 很长且 QPS 比较大的情况下，服务会整体 hold 住，甚至会出现拒绝服务的情况。

 

 

因此，可以拆分获取凭证的操作，通过独立网关渠道前置服务，将获取的方式异步化，从前置网关获取内部凭证，然后由前置网关去异步调用第三方。

 

异步并行化

 

资金核算异步化

 

热点账户账务单独处理

单边记账

• 内账户，财务不记账，会计补分录

异步记账

• 平台户异步记账，定时汇总记账

二级子账户

 

 

记账事务切分

 

4、生产实践

性能压测

构建压测模型，模拟现实真实场景；压测数据进影子库，正常业务无侵入；单机性能和集权链路都不能忽视；识别系统稳定性和容量配比。

 

稳定性治理

监控先行，关键指标管控

核心链路剥离

服务依赖治理

限流。降级

核心链路分离

 

服务依赖降级

梳理支付平台内强弱依赖，特别针对于核心下单链路

弱依赖做好降级开关

强依赖服务做好SLA保障