支付在业务中很重要，这里我根据自己做过的一些支付模块和大家讨论一下支付的一些事
支付什么最重要？
-
安全性：可通过签名验签保证
-
健壮性：商户通知系统若挂掉，影响发货，所以通知系统要保证其可用性
-
及时性：及时通知，对商户的发货和订单扭转至关重要
下面我画了一种方案的时序图大家可以借鉴，当然具体业务具体分析，也有其他好的方案
时序图解释如上
- 客户端下单，业务方存好订单以及订单详情，待支付，返回sign，来源标识以及订单号和附加信息
- 客户端跳转到待支付页，调用支付服务，支付服务验证sign（来源），封装好model返回给客户端
- 客户端调起支付，支付后同步返回结果成功/失败，成功则可以跳转
- 第三方支付异步返回支付服务，支付服务验签，保存结果更改状态，然后可以通过mq通知业务方支付结果后，更新本地通知状态
- 业务方验证sign，保存支付请求，更新订单支付结果
- 如果客户端想要确认是否真正支付成功，可以主动查单，如果查单在通知业务方完成之后，则直接查询业务方的本地订单状态即可确认成功/失败，返回给客户端；如果是之前，则去主动去第三方查询订单状态，返回后更新订单状态返回给客户端
这里有几个点说一下：
- 客户端下单后去调用支付服务，相当于调用一个控件，业务方不用关心其过程，只等待支付成功/失败的通知即可，可以很大程度的解耦；
- 如果是多个业务方调用支付服务也没有问题，因为支付服务维护了各自的业务来源以及通知路径等配置，集成即可
- 如果想各个业务方分别维护controller，可以客户端调用各个业务方的api，由各个业务方去调用公共支付接口，业务回调也可以由业务方来维护，这样和支付的耦合就比较大了，没有更好的使支付独立，还是推荐使用时序图的架构
- 下单的时候会返回一个加密的sign，支付服务验证是否真是自己的业务来源，包括通知业务方也是如此
- 这个时序图比较符合微信、支付宝和paypal的支付流程，像Braintree可以直接在server支付，支付后就返回及时处理业务，流程和这个有些出入可以单独查看
- 在通知业务方这块可能失败：怎么办？
- 悲观策略：
- 失败 / 超时间隔10s自动发起补偿，如果通知成功，则往mq中写一条成功消息，补偿机制收到消息后放弃补偿，这种机制会比较及时。缺点：大批量请求会给系统带来压力 ，浪费资源，造成雪崩
- 可通过定时任务检查没有通知的订单重新补偿通知，限制通知次数，缺点是这样可能不够及时；
- 采取乐观策略：成功则无需做任何事情，失败/超时则往mq中写入一个通知失败的消息，补偿服务只有收到消息才去补偿行动；因为通知成功率一般都99%，所以雪崩的可能性就会大大降低
- 悲观策略：
- 在业务方接收到通知可能失败：在通知入口处已记录通知信息记录，如果业务处理失败可通过定时任务定时扫描通知记录以及时处理业务
上面所说既是精华，大家可以体会思路，针对自己的业务以及微服务进行合理的设计
谢谢