前言

说到支付平台，支付宝的大型支付平台和小公司的支付是不一样的。如果一家初创公司或者刚成立一两年的公司没有人力、没有财力，想要打通支付怎么办？得益于支付宝和微信支付，两大行业巨头提供了简单易用的解决方案，简化了对接流程并支持大多数银行。今天我们将根据不同的业务规模，设计一个能够经受业务考验的支付平台。

第一阶段

例如，阿里在空闲时间接手了一个外包的分发系统。商业模式是这样的：成为会员，就可以自动分发带有二维码的海报。扫描您的二维码成为会员后，您将获得佣金。

这个例子有几个核心步骤：

申请会员，付费成为会员，自动生成海报，

计算分配佣金。

自动生成海报是一个挑战。这个可以参考微信参数二维码接口和GDI+绘图图片来完成，也可以使用它来完成。

最核心的部分当然是支付。

首先我们看一下订单表格流程图来总结一下情况。

订购型号

前几天看到域驱动提到了核心域和子域，那么整个交易流程就是这个模型的核心域，而订单表就是交易流程的子域。

我简单说一下这几个字段，业务类型、业务id、业务处理URL，实现各个业务的解耦。每个业务线都有自己的限界上下文。可以根据取消日期和取消地址完成订单取消动作，并可以根据支付平台交易ID和支付平台进行查询和对账。业务通知状态用于总结通知业务处理是否成功。说完订单，我们再来看看整体的交易流程。

交易流程

订单主要分为三个流程。订单提交由用户触发，支付回调由支付平台触发，定时取消是后台任务，根据设置的取消时间自动运行。小企业无需考虑订单取消。

这样，支付中心的第一个版本就完成了。由于刚刚上线，每天的访问量很小。平稳运行一段时间后，可能有支付平台有支付，但支付中心尚未支付。只能手动修改数据库并触发业务回调。这在最终一致性这里，可以变成人为的补偿。后来我不厌其烦的加了一个支付日志，记录下与支付平台交互的任何信息，然后每隔一段时间扫描一下最近变化的日志表，和订单表进行比较。如果发现不匹配，将其修复为付费，这是一个完美的解决方案。这个问题，在最终一致性上，可以概括为时序补偿。

事务日志表

老板人手紧缺，业务量呈上升趋势，很欣赏阿里解决问题的能力，于是直接给阿里加了一倍工资，从原来的公司聘用了他。 （故事纯属虚构）

第二阶段

来到新公司没多久，我就得到了一笔融资，然后新公司又聘用了很多同事。随着销售人员的增多、产品线的增多，在线支付流量也随之加速。阿里信心十足，感觉动力十足。正得意不久，就遇到了服务热线反映的问题：客户重复付款，需要退款。于是我改了订单，清理了数据，并进行了财务退款，暂时解决了问题。后来，当交易数量增多，人工处理容易出错时，我就查询了支付宝和微信的自动退款接口，然后依靠日志表记录成功支付对比，判断重复支付，发起退款，引入了自动退款流程。

交易流程补充自动退款流程

然后我们就收到了网上客户的抢购请求，每个月有一天我们聚集在一起抢，类似于小米的闪购。然后到了激动人心的那一天，系统持续了三分钟，华丽丽的死掉了！花了二十分钟才恢复正常。

吸取经验后，支付中心进入重构优化阶段。由于公司人员的扩大，有时间、精力和能力重新收购和优化更健康的业务结构。

1、引入消息队列，支持流量调峰。比如支付回调高级消息队列，消息队列会通知业务。显着缩短单个请求的处理时间，提高并发能力。

其次，充分引入缓存，减轻数据库访问压力。对部分关键业务表启用缓存，性能指数级提升。

第三，引入专业的调度工具或者。可用于处理定时查询订单交易问题和退款问题。

第四，购买商业.net监控平台，例如听云。测试程序性能。

阿里沿用了新公司的技术体系，也对支付中心进行了升级。

支付平台回调通知后，首先转发到消息队列，通知业务处理。如果失败，则延迟并转发到消息队列继续执行。最多会重试5次，然后会发送短信或电子邮件通知负责人。

为了解决之前在线支付平台与自建平台不一致的问题，采用调度机制，每天晚上拉出一周的数据，与支付平台核对。保证了两个异构系统的一致性。

为了防止支付平台同时收到通知，导致产生两条支付日志，先在订单更新成功后，在队列中使用incr和decr的原子操作，保证一次只能操作一条订单同时，另一个通知被延迟。重复退款时，还必须保证同一时间只能退款一个订单号。 （不同订单号可以同时操作，但必须强制相同订单号，避免并发）

数据库启用读写分离并部署集群。

经过阿里和同事们两个月的协作和加班，新系统终于在客户第三次网上购买前一段时间上线了。经过网上抢购验证，新系统轻松顶住抢购，引得大家哄堂大笑。阿里看到十分钟XX万的交易额，惊呆了！ ，这真是金牌客户啊！

到了年底，微信红包变得非常流行。不少顾客申请开微信红包。一位客户拥有超过20万粉丝，并收到了一大笔钱。到时候，十万人摇手机抢红包。最后多次重启应用程序池也没有帮助。面对这样的流量我们该怎么办？每秒数万个请求目前不是小公司能够处理的。而且这种流量只发生在过年期间，相当于春运。人太多了，能抢到红包的人是有限的。百分之九十五的人都是无效流量。然后使用一个技巧，随机选择一些人的数据输入到服务器中，其他人的数据保留在本地。这种思维方式减少了很大一部分流量。

如果只考虑第一和第二阶段，上述关于支付中心的思维结构完全可以满足交易量。再说了，有多少企业能够成为独角兽呢？

想着天地漫漫的路途，我伤心地流下了眼泪！

第三阶段

上面的方法虽然是骗人的，但是对于具体的商家来说，基本上就是抢红包。大多数人都是无效的。可以说，如果主业务流程每秒有几万个请求，甚至每秒有几百万个请求，对于大多数人来说是无效的。我们应该做什么？阿里很困惑。

我听说过容器编排、CI/CD自动部署、微服务的力量、负载均衡，所有这些似乎都是方向。

海洋不能越过陆地，但台风却可以轻易越过陆地。大的可以化为小，复杂的可以化简，简单的可以化为综合。大规模微服务或许才是解决海量请求的出路！ （故事纯属虚构，请勿入座）

附录：最终一致性

说完了解决中小流量的问题，我们再来看看一致性问题。

1、关系型数据库事务追求ACID：

答： ，原子性

C: , 一致性

我：，隔离

D：，坚持

2.CAP（帽子理论）

C：一致性，数据一致更新，所有数据变化同步

A：可用性，响应性能好，完全可用性是指在任何故障模型下，服务都会在有限的时间内处理响应

P：，分区容错，可靠性

帽子理论证明任何分布式系统只能同时满足两点，而无法兼顾三点。

3. 基础型号：

BA： ，基本可用

S：Soft，软状态，状态可以在一段时间内不同步

E：，最终一致，只要最终数据一致，而不是时刻保持强一致性

采用查询模式、补偿模式、异步保证模式、定时校对模式可以实现分布式系统的最终一致性。

关于最终一致性更详细的用法，可以参考李彦鹏老师对分布式一致性的讲解。

后记

阿里解决了支付中心的稳定性问题后，又买了很多书。当他看到上面关于最终一致性的说法时，他心想，这些都是我已经做到的了。那么还有这么多的顾虑吗？ ？

阿里又看到了领域驱动设计这样的书，感叹：支付领域模型真是学习领域驱动设计的最佳实践。它具有独立的有界上下文，并通过回调 URL 与其他业务有界上下文进行通信。

最后我们用交易流程来做个总结吧！

交易流程

要点：

1、回调部分有消息队列通知，支持失败重试。

2、每晚定期拉取支付平台对象记录，保证最终一致性。

3、支付平台回调时，会根据支付日志判断是否重复支付。如果重复付款，将启动自动退款。

源代码

计划以领域驱动的方式完成上述设计。没有设定日期。