本文从支付流程入手分析下“支付宝故障”，猜测下支付宝的故障原因
一、故障背景
大家最直观的体验就是：在某些购物平台买东西，付款时显示支付失败，但是钱却被扣了。
整个故障持续时间从上午9点多持续到10点50。支付宝给出的解释是“系统消息库故障”导致。
二、整个系统交互分析
2.1 首先：我们先来看看一笔订单的支付流程。
参与方：
- 商户客户端：购物App（美团等）
- 支付宝客户端SDK：app里面集成的支付宝SDK
- 支付宝服务端：购物app通过支付宝SDK与支付宝服务端连接
- 商户服务端：购物app的server端。
核心流程：
- 步骤一：用户使用购物App发起支付操作；
- 步骤二：然后购物App向我们的服务端发起支付请求，这时候服务端把签名后的订单字符串返回给客户端；
- 步骤三：客户端拿到这个请求支付宝SDK调起支付，支付宝SDK这时候会连接到支付宝服务端；
- 步骤四：支付完成，支付宝服务端会将支付结果同步返回给购物里面的支付宝SDK，SDK会回调支付结果给购物；
结论：从用户体验来看，这次故障是猜测步骤四挂了，也就是交互图里的7至11。
2.2 猜测与推断
- 为什么说7-8挂了？
- 因为客户端一直没成功，返回的交易失败
- 为什么说12-13也挂了？
- 在此期间询问了公司内部的网关对接同学，按照他们的说法那段时间支付宝回调量级下降明显，查单也查不回来。
- 为什么本次故障不会对用户资金造成损失？
- 首先用户银行卡可以正常扣款，说明支付宝与“银行”交互正常，交互正常必然有“单据”留存，有据可查就不用担心，后续可以根据这些单据重新捞起发起补偿。
2.3 支付宝的止损方式
因为支付宝有故障期间的扣款单据，所以只需要尽快将扣款结果通知到购物app，这样购物app就能尽快处理没成功的订单（没成功的订单就能推到终态，用户体感就不会多扣了）
最后，针对这次故障我们能对自己的系统做点什么？
- 做好监控（正向+逆向）：不要等客诉进来才发现，这次估计好多购物app都是客诉反馈才知道
- 做好防控（降级处理）：做好通道的切换、降级能力（目前好多大厂这个处理的都不错，有的折叠，有的置灰，有友好提示）
欢迎关注程序员柴宝，获取更多技术干货~
