金融IT保命丹：多端支付强一致性架构设计实践

本文根据郑志成老师在〖deeplus直播第271期〗线上分享演讲内容整理而成。（文末有回放的方式，不要错过）

作为平台系统，应该具备：产品通用能力、个性化可配置。目前接入支付平台有几十条业务线，主要包括到家业务、骑士业务、快送业务等，根据不同的业务形态，我们提供了5种主要的支付产品：

• 收银台（具备多种支付能力）

• 直连支付（直接唤醒支付场景）

• 代扣服务（周期性扣款）

• 代付（好友代付等）

• 协议支付（便快捷支付、免密支付等）

支付系统核心功能主要是：支付和退款。

如在一些预售场景下，为业务线提供定金支付这种2阶段支付能力（如定金支付）；退款主要是全款、部分退款、以及提供人工退款服务。

除了核心功能，我们还提供支付营销能力，进一步提升支付的转化，如根据用户所属区域进行支付引流，支付券产品、免息产品、满减等。

在开发定金、和营销产品之前，支付系统被设计为一个订单，在产品形态上很单一，仅认为订单为固定金额，因此开发这两个需求的时候改动了比较大。

目前主流支付能力大概有多阶段支付、大额支付场景、组合支付、支付参与营销等能力，所以有开发支付系统需求的同学，在最开始最好提前预留一些设计。

我们目前基本接入了所有主流支付方式（微信支付、支付宝、京东支付、京东白条等），尤其是现在各类小程序当道，各业务线都需要支持在不同小程序中发展业务，但受到平台支付方式的限制，就需要我们接入更多的支付方式，例如百度支付、头条支付等，都需要接入。

当业务被嵌入到各种各样的流量渠道入口，我们也要根据不同的渠道支持不同的支付方式，如App支付、H5支付、刷脸支付等。

2、支付能力的快速接入

我们接下来看一下支付能力的快速接入的一个流程：

左上图是我们经常使用的收银台（支付页面），包括订单的基本信息、随机减活动和微信的引流活动等。

右上图是我们支付平台和微信的交互逻辑，整体上还是比较复杂的。

3、配置化支付方式

下图我们目前的个性化配置，目前我们最小力度是支持按照不同渠道进行配置，比如我们最核心的商超业务渠道有几十个，根据不同的终端适当屏蔽掉一风控能力减弱的支付方式，或者在某些特别的终端按照业务的要求配置指定的支付方式，每种相同的支付方式，根据具体的业务线或具体的业务配置不同的商户号，不同的商户号在第三方平台的费率，收款账户都是不同的。

我们的多端支付场景是指：

第一： 由于我们无法感知用户唤醒sdk后的操作。

所以我们不能限制用户的支付行为，一个订单可以从多个手机多个渠道使用相同或不同的支付方式、不同的人同时对一笔进行支付。

第二：支付、退款跨越多个端。

支付跨越多个机构，就会经过支付平台、第三支付平台、银行等。支付和退款是一个天然异步场景，这是不可抵抗的因素。

• 那我们如何做到多端支付支付金额的强一致呢/strong>

二、如何安全保证金额正确性

那么我们要通过什么手段，来保证实际收的钱应该大于或等于应该收的钱时，我们要尽可能通过不变量和不需要加工的数据来验证变量。

• 不变量：订单金额；

• 不需要加工的数据：业务申请的退款。业务一旦申请退款，校验通过就会插入数据库。这里是业务产生的退款，退款可能会有人工退款、多支付退款等，但是这些我们不用关心。

我们需要关心的是：订单金额-业务产生的退款，也就是我们至少收到多少钱，如果和实收相等，则认为没有问题。

• 那么我们如何保证实收就是正确的呢/strong>

继续使用实收和支付平台对账，其实就可以进一步确保实收没问题，我们需要对账每一笔正向支付交易和逆向支付交易产生的金额记录，且对账至少需要2种机制来相互保障。

三、高可用架构的一些实践及思路

1、高可用的分类

线上场景还有以下特征：

• 配送的时效性。一笔订单生命周期就不到1小时，所以在支付上我们不能延迟，不能像银行转账这么慢。

• 高并发。大家也知道银行等金融机构比较有钱，所以他们在做活动的时候，这些活动的力度不亚于一些商品秒杀场景。

• 营销限量。这是非常重要的一点，如果用户享受支付优惠，但是最终由于支付通知的延迟、服务器负载较高的情况下未能成功处理支付通知，那么用户就会要求索赔营销优惠了。

线下场景比线上场景更加复杂，有以下特征：

• 即时性。大家去的线下商店，基本都支持收银台在线支付，所以在排队的情况下，就需要商家及时完成顾客的支付请求。

• 网络环境不可控。在不同的位置，其网络信号就存在着不确定性。

• 群体性。线上主要是平台和支付平台的网络交互，但是线下还涉及到了商家，整个支付环节也没这么流畅。

我们需要做的就是尽可能快的让订单支付完成，或者在某种支付有问题的时候，第一时间下线这种支付方式。

我们过去的做法是通过暴力从数据库反查待支付的订单，但是对数据库压力还是比较大的，还要单独写个任务表，后来改写为基于事件通知机制。

我们使用JMQ队列作为事件管道，但由于不同场景触发的反向查询时机不同，所以我们不能对所有对待支付订单进行无差别对待，因此就受限于JMQ的特性。

目前不支持个性化延迟消费消息，所以我们的策略是申请多个队列，并按照不同的延迟level，放入队列中。

我们根据ToC和ToB业务请求，对服务器部署上做了资源的倾斜。确保业务相互不影响。

ToC一般是正向交易场景，RT要求比较高；ToB场景对时效基本没有要求，在某些业务场景下，会存在集中性的大批量退款申请、退款流程的事务也比较大，ToB就针对一些任务worker比较消耗cpu。

我们的目标是尽量避免非业务耗时导致的RT升高，而导致RT升高的因素有：池化资源不够（http请求线程、rpc处理线程、数据库线程、以及http连接等）、cpu资源抢占、GC 导致的业务线程等待等。

4、高可用-多级本地缓存

上图是我们线上的一个效果图，Redis的利用率已经达到了97%，这完成是布隆过滤器来决定的，效果还是比较明显的。

5、高可用-监控

我们再来举一个例子：

某晚上，手机一阵震动，打开报警一看，报警很明显。红色框是垂直类-支付渠道层的报警，而且都是apple Pay导致的报警，那么基本大概率影响支付方式是apple Pay。

绿色框是水平维度监控，显示了我们的影响功能：支付、查询。同理报警没有显示的业务线，就跟这些具体业务场景没关系。

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览91960 人正在系统学习中

来源：jeanron100