订单接入支付宝流程实战与优化

概述

了解支付宝支付能力接入方式。
电商项目如何对支付流程进行设计及优化。
基于 RocketMQ 事务消息实现的订单确认机制，来完成订单超时回退功能。

支付宝接入流程简介

国内目前有支付牌照的公司总共只有两百来家，比如支付宝、云闪付、和包支付、翼支付等。

支付宝支付场景

支付宝提供了两个重要的服务开放平台，对外开放自己的核心支付能力。第三方企业都可以通过这两个服务开放平台接入支付宝，借助支付宝开发自己的支付场景。
面向商家的支付宝商家中心：https://b.alipay.com/page/portal/home；
面向开发者的支付宝开放平台：https://open.alipay.com；
我们这次更关心的是在技术层面如何快速接入支付宝，所以更关心的是后面的支付宝开放平台，后面简称支付宝平台。
支持的支付类型如下：

沙箱环境介绍

沙箱环境提供了一系列开发调试所需要的帐号以应用信息，这些测试帐号会定期改变。这里最重要的是 PID 和 APPID 两个参数。沙箱环境直接给出了对应的尝试数据，正式环境都需要向支付宝进行申请才能获取。
参数说明：
其中，PID 表示商家账户 ID，在正式环境中，需要由商户登录支付宝商家中心后获取。
而 APPID 表示在支付宝上注册的第三方应用的 ID。需要由开发者创建应用获取。
开发者登录支付宝开放平台后，进入控制台，需要在控制台创建对应的应用。
创建应用后还不算完，需要商户绑定应用，这样的 PID 和 APPID 才可以一起使用。商户登录商家平台后，在账户中心，选择 APPID 绑定，设置绑定开发者创建的应用。
沙箱环境还提供了一个沙箱版本的支付宝 APP，用于模拟正式支付宝 APP 进行相应测试。

支付宝的正式环境和沙箱环境的接口并不完全一样。真实应用在沙箱环境调试成功后，并不能保证在正式环境就一定没有问题，还需要迁移到正式环境重新测试验收。

优化订单支付流程

支付宝当面付预下单流程

流程说明：

用户在电商上选好商品，从购物车开始选择下单。
电商后台记录用户的订单数据后，会往支付宝进行一次预下单，可以理解为申请一个支付订单。
如果预下单没有问题的话，支付宝会给电商后台同步返回一个二维码图片。
电商后台将二维码图片保存到本地服务器上，并与自己的业务订单建立绑定关系。
电商系统将二维码图片展现给用户，用户使用自己的支付宝扫描二维码，完成登录、支付的一系列操作。
支付完成后，支付宝会给电商后台发送一个异步通知，告知订单支付完成。电商后台接收到这个通知，就可以完成订单后续的业务操作。

主流程是没有什么问题，基本上就照搬刚才的流程就可以了。但是，就按照这个流程实现订单管理，你会发现有个小问题，对于订单取消操作还没有进行设计。用户下完订单后是需要及时进行支付的，电商项目在用户下单时就需要锁定商品库存，如果用户长期不支付，锁定的商品就无法正常销售。

所以，通常对于订单都会设定一个支付时间，比如五分钟内需要完成支付。如果没有支付，就需要取消订单，释放库存。那应该如何设计订单的超时判断流程？

使用延迟任务实现支付超时判断

做个定时任务，五分钟后去支付宝查一下订单是否完成了支付。

流程说明：

下单时增加一个定时任务，在五分钟后对订单进行超时判断。
超时判断时，可以先去支付宝上查询订单支付状态。

如果已支付，则判断订单是否正常结束，这是因为在用户完成扫码支付后，支付宝正常会往电商后台发送支付成功的通知。但是这个通知是没有事务保证的，所以是非常有可能失败的，这时就需要在订单超时判断时对状态进行对齐。
如果未支付，则需要释放库存，取消本地订单，然后通知支付宝取消支付订单。

这种设计方式很自然，但是会有一个小问题，就是对订单状态的判断会不及时。订单支付状态只有在五分钟后的超时判断时才能最终确定，这就不太及时。这样对于一些并发量比较高的场景就不太合适，比如在 12306 抢火车票，是不是你一支付完成，12306 马上就知道了？就给你发火车票了？或者你回顾一下日常使用支付宝进行支付的场景，是不是你一支付，商家马上就知道了？更别说对于秒杀等超高并发的场景了。
那要如何优化呢？通常企业中的做法并不会等到订单超时时才去查询订单状态，而是在后台会多次频繁查询支付宝支付状态，这样可以更及时的获得支付结果。例如五分钟超时时间，至少需要半分钟或者一分钟去查一次支付宝订单状态，如果支付成功了，就及时结束后续等待处理过程。如果没有完成支付，就再开启下一个定时任务，等待下次检查。
比如通过定时扫描定时任务表，会存在几个问题，设置多久扫描一次比较合适？表记录变多时如何保证查询性能？
这样一分析，你会不会觉得这个定时任务光是流程控制就有点麻烦了？再跟业务逻辑绑定在一起，这个任务的逻辑会变得非常复杂。有没有现成的框架可以帮我们来优化这个复杂的定时任务逻辑，让我们只要专心关注业务逻辑呢？有，RocketMQ 的事务消息就是一个比较好的工具。

RocketMQ 事务消息改造支付超时

RocketMQ 事务消息机制的核心是对消息状态进行不断的确认。循环确认的过程就正好可以用来改造，解决上面说的频繁任务调度的问题。这样就可以专注于开发业务逻辑，而不用关注频繁复杂的任务调度逻辑。

在向支付宝进行预下单时，发送一条事务消息。只不过这里发送的消息，是用来通知下游服务进行本地订单取消的。

核心流程：

支付宝预下单成功后发送事务消息。
发送消息后，就会先执行本地事务。下单成功返回 RocetMQ 服务端 UNKOWN 状态，这样 RocketMQ 会在之后进行状态回查。
事务状态回查。回查逻辑会记录回查次数，超过最大次数就直接取消订单。

注意，这里最大回查次数需要根据业务要求进行定制。RocketMQ 的事务消息回查间隔可以通过参数 transactionCheckInterval 定制。
如果没有超过最大次数，并且本地支付状态未确定，就可以去支付宝中查询订单支付状态。
如果已经支付完成，则返回 ROLLBACK 状态，事务消息取消，后续就不会再进行本地订单取消了。
如果未支付，则记录回查次数后，返回 UNKNOWN 状态，等待下次回查。

如果事务消息最终发送出去，也就是订单已经超时，就会将消息发送到 RocketMQ 的指定 Topic 下。下游的消费者就会完成取消本地订单，释放库存等操作。

在这个流程中，表面上利用 RocketMQ 的事务消息机制将频繁的定时任务拆解成事务回查的过程，实际上是通过不断的事务回查来确保分布式事务的最终一致性。
这里要加一个设计点，在下单时要加一个分布式锁（可以用 redis 实现），后续取消订单时需要能拿到锁（redis 中的锁过期了）才能取消，防止并发。

流程扩展：

通过聚合支付进行分布式事务控制

当前电商项目，只完成了与支付宝的对接，而在对接过程中，是直接使用支付宝的二维码通知用户进行当面支付。而用户使用支付宝扫码支付的过程，电商系统都是完全不知道的，也就没有办法对用户的支付动作进行控制。比如如果电商系统本地的订单已经超时，就要阻止用户进行扫码支付。当前项目的处理方式是在支付宝的回调接口判断订单状态，如果订单已关闭，则发起订单回退。这样显然效率是不高的。
在很多电商项目中，会采用聚合支付的方式，统一对接多个第三方支付方。用户的支付动作就不是直接与支付宝这样的第三方支付公司交互完成，而是要经过电商后台转发请求完成。这时，就可以通过添加一些分布式锁机制，保证整个支付业务是串行执行的，以防止在电商进行订单超时回退后，用户再次扫码支付。

正向通知与反向通知

当前电商项目中，是通过事务消息通知下游服务订单取消，这其实就是一种反向通知的方式。但是其实最直观的方式还是使用正向通知，即通过事务消息通知下游服务进行订单支付确认，这样这个下单的消息就容易扩展更多的下游消费者。结合电商系统，订单下单确认是用户完成支付后，支付宝发起的通知来确认的。这时，如果订单确认的下游服务实现了幂等控制，就完全可以将事务消息机制改为正向通知。即在事务消息回查过程中，确认用户已经完成了支付，就发送消息通知下游服务订单支付成功。这样也可以防止支付宝通知丢失造成的订单状态缺失。
而用户订单超时判断，则可以在事务消息状态回查过程中，通过记录回查次数判断。如果已经超时，则返回 Rollback。同时启动另外一个消息生产者，往下游服务发送一个订单取消的消息，这样也是可以的。