引言
现代支付系统中,单一的现金支付方式已经不能满足多变的业务营销场景,因此有了以各类非现金支付方式(积分、红包、话费、流量等)抵扣部分现金的需求,对产品经理进行支付流程与接口的设计提出了更高的要求。
本文主要提出一种多凭证支付的流程与接口设计方案,并考虑多凭证支付时的效率问题。
名词解释
为了方便读者在同一频道上沟通,先解释下列的名词。
- 现金支付:使用借记卡、信用卡或某宝某信的余额进行支付;
- 非现金支付: 使用积分、红包、话费、流量等等辅助方式进行现金抵扣;
- 多凭证支付: 同时存在现金支付及非现金支付(一种或多种)的组合支付方式。
原价100元的商品,使用 现金100元 支付,是为现金支付;也可以改为使用96元现金+1元红包+20积分+1元话费,是为多凭证支付,96元以外的部分称为非现金支付。
多凭证支付流程设计
进入正题,设计这个流程的最大挑战在于积分、红包、话费、流量等等凭证信息是分属于不同的系统,甚至是不同公司不同团队来开发与维护。
想要将这些系统整合成为支付系统的一部分,如何串联外部系统是个大问题,相信接到任务的同事已经死了不下二百个脑细胞。
分析
通过简单的分析能发现这个需求的要点,核心是要让现金支付与非现金支付的各个环节一齐成功,假如有某个环节失败,那么整个支付就应被判定为失败。与此同时,这些凭证信息又分布在各自的系统上。
![img_3288b69c6871ba58168a4c3689748dfb.png](https://yqfile.alicdn.com/img_3288b69c6871ba58168a4c3689748dfb.png?x-oss-process=image/resize,w_1400/format,webp)
等等!研发的同事笑了,这不就是一个典型分布式事务吗?对!我的思路就是参考分布式事务的设计思想来构建这个流程。
分布式事务思考
对于分布式事务,并不是本文所要描述的重点,各位前辈们早己为我们铺好了路,需要了解的可以查看以下连接。
漫画:什么是分布式事务?
聊聊分布式事务,再说说解决方案
微服务架构下分布式事务解决方案——阿里GTS
我们所要做的只是站在巨人的肩膀上去看问题。
![img_e8863bccd27186a47e0a8105d9e981f6.png](https://yqfile.alicdn.com/img_e8863bccd27186a47e0a8105d9e981f6.png?x-oss-process=image/resize,w_1400/format,webp)
两阶段提交(2PC)的支付流程
分布式事务最经典的模式莫过于两阶段提交(简称2PC)。其核心思想是先锁定资源,再提交变更。
![img_e0f0eacc1a821366550f0c16faaf8155.png](https://yqfile.alicdn.com/img_e0f0eacc1a821366550f0c16faaf8155.png?x-oss-process=image/resize,w_1400/format,webp)
运用两阶段提交的做法,可以将业务流程设计如下。
![img_7ebeb37dfbdb72f2a5ecdcc32e46d7ce.png](https://yqfile.alicdn.com/img_7ebeb37dfbdb72f2a5ecdcc32e46d7ce.png?x-oss-process=image/resize,w_1400/format,webp)
其过程可描述如下:
- 当用户提交支付请求以后,由事务管理器(这里其实是支付系统)锁定用户的各种非现金凭证资源,所有凭证资源锁定成功后,调起现金支付。
- 用户完成现金支付后,支付系统再向各个外部系统提交对各种支付凭证资源的变更操作。所有凭证系统返回变更成功后,支付被确认为成功。
- 在上面的过程中,任何锁定或提交失败,都认为支付失败,并归还被锁定的凭证资源,并回滚提交的变更。
以上的流程确保了的可用性和一致性,但存在重大的缺点:随着非现金支付凭证的增加,需要锁定的凭证越来越多,由于是外部系统,响应时长方面很难控制,造成用户提交支付请求后,等待跳转现金支付环节的时间越来越长,用户很容易失去耐心,造成支付半途而废。
根据TCC改进的流程
为了弥补上述缺点,参考金融系统常用的TCC机制(参考TCC型分布式事务原理和实现之:原理介绍),将流程略作改进,变成如下。
![img_b92d777fb8ef5888ba86bd046e323603.png](https://yqfile.alicdn.com/img_b92d777fb8ef5888ba86bd046e323603.png?x-oss-process=image/resize,w_1400/format,webp)
这里使用TCC机制的目的在于,将尝试资源操作和提交变更操作的驱动者分离,由不同的服务来执行。流程要点如下:
- 所有持有凭证资源的系统都必须实现Try,Confirm,Cancel三个功能接口。
- 用户在客户端上选择某个凭证时(比如勾选“使用积分支付”),此时立即使用Try接口锁定凭证资源。
- 用户点击“去支付”提交支付请求时,由于支付所需要的非现金凭证资源已经被成功锁定,可以立即进入现金支付的环节。
- 用户完成现金支付后,由支付系统提交所有凭证系统的Confirm接口,进行变更确认。由于Try阶段已经预留了资源,因此Confirm操作必然成功。
- 如果现金支付不成功或者用户超时未进行现金支付,则支付系统使用Cancel接口释放Try操作已锁定的凭证资源。
最终一致性保证
采用分布式事务不可避免的要面对各种不可预料的情况。作为支付系统,最终一致性是重中只重,因此,我们还需要通过每天对账确保各方系统最终一致。
设计回顾
综上,一个可落地的流程已经设计好了。简单回顾一下上述TCC流程,有以下优点:
- 各方系统可以保证最终一致性。
- TCC机制使得系统响应速度提升,用户平均等待时间变短,也降低了系统等待资源的开销。
- 此流程保留了较好的扩展性,理论上可以添加无数种非现金支付的凭证作为辅助支付手段。
当然,在具体实施过程中,以上的流程还需要有很多的机制需要完善与改进,比如需要为锁定的资源指定超时时间,又比如异步化处理提升效率,再比如要避免死锁设计等等。但这已经超出了产品设计的范畴, 所以本文也就到此为止了。
一点浅见,仅供参考,欢迎回复讨论。