【系统设计】创业项目中如何快速实现强扩展性的支付模块

2017-04-11 本文已影响888人一名软件工程师

从支付宝离职创业后做了不少项目，走过许多弯路也走过一些捷径，期间从许多同行的许多博文中获取了解决方案和灵感，有感于不能一味索取，也应有所回馈，所以想把自己的一些拙见做些记录分享。

支付作为一个常见底层业务模块，对于大部分，尤其是电商类项目不可或缺。本文主要就是分享一下我们在支付模块上的设计经验。

C2B支付业务链路梳理

业务方向：用户向企业付款（C2B）
资金来源：项目自定义的资金账户，营销工具（红包，积分，抵扣券等），第三方支付平台（支付宝，微信等）
资金链路：
- 第三方支付：用户支付宝账户 =》企业支付宝账户 =》提现至企业其它资金账户
- 自有支付工具：用户资产 =》企业资产账户 =》回销

核心模型梳理

用户资产模型（Asset）：

我们可以将积分，红包，抵扣券等抽象为用户某种形式的资产，从而不同的支付工具账户得到了一致的抽象。
对于第三方支付平台的用户资产，因为我们系统没有查询权限，可以不纳入项目资产模型

资金变动单据模型（TransactionDocument）：

抽象用户资产后，支付行为其实就是对用户资产的变动。当我们购买一个东西，或者进行其它类型缴费时，会产生一个支付凭证，作为实物证据证明本次支付行为。从这个角度可以将资产变动行为映射为构建支付凭证的行为，这里我们称之为“资金变动单据”，简称“资金单据”，创建相应模型TransactionDocument。它的创建及持久化可以作为一次支付操作。

总结来看，所有的支付工具都是用户某种形式的账户资产，其对应的支付行为，就是完成相应资金单据的构建，以及持久化。

业务模型梳理

用户支付POJO模型：Payment

与订单模型Order建立多对多关系，这样就为合并支付（多个订单Order对应一次支付Payment），分阶段支付（一个Order对应多次Payment）等深度业务预留了扩展空间。

用户支付资金单据POJO模型：TransactionDocument

此外还包括一些特殊子类例如WeixinPayTransactionInfo，CouponPayTransactionInfo，这些模型产生的原因是不同类型资金单据在成员属性上相差较大，例如对于微信支付有预支付单号，微信支付单号，这些字段对于红包资金单据是不需要的。

用户资产POJO模型：CustomerAsset

CustomerBalanceAsset，CustomerCouponAsset

数据库模型梳理

CustomerBalanceAsset：

储存用户余额资产，这类资产多为返现活动，例如评价返现30元，一般我们都是返到用户余额；另外一些项目有充值需求，也可以把第三方支付结构或者银行机构内的资金充值到余额中。

CustomerBalanceAssetLog：

储存用户余额资产变动记录。因为资产肯定会发生变动（增减），必须需要log表例如customer_balance_log（可以业务代码实现写入也可以通过数据库的event实现，建议采用前者）记录所有的资金变动详情，方便对账补偿差错。

CustomerCouponAsset：

储存用户红包资产，我们系统设计是和CouponActivity关联的，用户参加红包活动，领取红包资产，会记录到这张表中。

CustomerCouponAssetLog：

储存用户红包资产变动记录，消费，过期等

...... 另外一些积分，抵扣券可以沿用类似逻辑

Payment：

储存用户支付行为信息，关键字段有总支付金额，支付创建人，支付状态等，与Order表多对多映射，具体原因前面分析过了。

Transaction：

储存用户资金单据，关键字段为支付渠道，支付金额，支付时间，支付状态等。其与Payment为多对一关系。但是不同的Transaction有不同的字段，例如微信支付有商户订单号，预支付单号等，这些字段是余额资金单据不需要的，如果设计一个大Transaction表的话，不利于扩展，也会造成不少记录会出现空字段。所以我们创建了BalanceTransactionInfo，CouponTransactionInfo，WeixinTransactionInfo字表，以共享主键的方式与Transaction表建立一对一关系。

代码设计

一期方案

核心接口：
- AssetService接口，包括changeAsset()方法，在进行资金扣除操作时可以通过SQL WHERE条件进行有效性保证，例如：
  update CustomerAssetsBalance c set c.customerAssetsBalance = c.customerAssetsBalance + (?2) where c.customerId = ?1 and c.customerAssetsBalance >= -(?2)
- TransactionService接口，包括buildTransactionList()方法，进行完整的支付资金单据集合创建，持久化时会调用changeAsset()进行资产变动。
交互链路：
1. 用户选择项目点击支付按钮，进行支付预检，库存，是否黑名单用户等
2. 后端接收到请求，开始生成支付确认页面渲染所需要的数据，主要是完整的资金单据集合，调用了buildTransactionList进行了资金单据预创建，注意，这是没有进行持久化，没有进行资产变动操作，只是为了让前端展示各支付渠道的支付情况，方便用户审核
3. 用户确认各支付工具支付无误后，点击立即支付按钮，我们会根据操作环境弹出支付渠道选择框（例如微信浏览器内不支持支付宝支付），支付渠道选择完毕后支付请求提交后端重新进行资金单据List构建，并与前端传递数据比对（保证用户看到的支付资金单据与后台实际处理的资金单据一致），核对无误后进行资金单据持久化，资产扣减，然后调用第三方支付进行支付预创建操作，这些都是包裹在一个事物里的，拿到第三方支付预创建结果后让前端跳转第三方支付机构支付页面完成支付
4. 在第三方支付页面，支付完成后，前端拿到第三方前端回调结果或者支付直接回调指定页面，我们都让用户跳转至本系统的支付结果页面轮询支付结果
5. 第三方支付机构处理成功后通知业务系统，业务系统核对后进行相应的WeixinpayTransactionInfo构建，相应的Transaction状态修改，订单状态修改等操作，包裹在事物中，此后前端轮询也就是上一步会得到正确结果，展示支付成功等信息。

二期方案：

代码上线因为营销需求接入了很多支付工具，导致buildTransactionList方法实现代码量非常大，不同支付工具的共有方法重复，代码复用性低。

一种改进方案是通过责任链设计模式，通过链式处理器的思想对资金单据集构建做链式处理，考虑到责任链设计还是有一部分耦合代码，同时与Spring框架结合不够紧密，没有采用
另一种解决方案，针对责任链进一步思考，其实很符合AOP思想，一个支付请求输入是用户项目支付渠道等信息，输出是一个资金单据集合，后续基于资金单据集合进行资产变动操作，中间过程实际上就是不同支付单据处理器对订单进行基于切面的流水线加工。如果用面向切面的思想设计，建立BalanceTransactionProcessor切面，CouponTransactionProcessor切面，这样不同切面可以通过接口和抽象类实现代码复用，同时buildTransactionList方法被切后只需要保留几行日志代码就可以了。我们新接一个支付工具变得非常容易，代码改动量很小，增量增加处理器就好，另外处理器顺序可以通过Spring AOP的Order注解保证。
这里还有一个点需要注意，不同切面是有参数传递的，比如目标是构建一个资金单据集合List，支付渠道限制等数据需要贯穿整个切面处理过程。这里我们参考了Spring Security的设计，用户验证信息是放在一个SecurityContext中的，本质是一个线程变量，因为Spring MVC是基于线程池处理用户请求的，所以线程变量这里变成了一个类似数据总线Data Bus的角色，我们新建了自己AppContext，切面对AppContext中的Order对象和TransactionList对象不断加工处理，最后得到完整合法的资金单据集合。关于应用上下文AppContext的具体实现，我会放到另一篇文章里讲述。

至此我们支付系统一期，二期基础结构已经陈列清楚。
大家如果对其中的部分细节感兴趣，或者有异议，非常欢迎留言谈论批评指正，我会及时勘正补缺。