1. 资损盲区随着有赞支付体量的增大,资产部门承担的资金管理,风险把控的责任也越大。我们一方面要小步快跑,快速支撑业务,又要稳住底盘,守好底线。支付业务底线就是守护用户的每一分钱,不能有资金损失。在我们搭建这套体系前,有赞支付资金类的线上监控是个盲区,缺乏自我发现的能力。业务成功了,但内部对用户的资金操作可能是错误的,导致资损。而且故障发生到发现的时间很长,且大部分是用户上报,导致故障的影响面扩大,用户的信任度降低。 预防资损有很多种手段,除了事前线下通过各种测试手段保障资金安全外,线上也是非常重要的一环。除了发现问题,相应的,出现故障时,资损止血的能力也需要配套跟上。 举一个最基本的支付业务场景,在有赞内部会经历以下几个系统之间的交互 1.jpg
通过上图可以看出每个系统的处理结果,会依据系统建立的模型存储在数据库中,部分关键信息会传输给下层系统。系统之间处理的重要信息如金额、账户不一致就会导致资损。目前我们也内部对账会发现这些问题,但是内部对账都是每天跑批执行一次。如果依靠内部对账来发现这个问题,资损早就发生了。需要调用很大的人力物力去追款,大部分情况下还追不回来。我们分析了有赞近一年来的资损场景,结合历史的经验,总结出资损类故障发生有几下几大类: 1)有正确的输入,错误的输出:比如系统与系统之间的金额存储单位不一致,或者自己处理金额正确,传输给下游的金额错误,导致后面交易金额错误; 2. 资损体系的诞生基于解决以上问题的目的,我们设计了实时防控资损体系。总体设计思路围绕以下几点: 1)发现问题的实时性,减少故障的影响面; 平台能力是基础,检测规则是其灵魂。基于对业务的丰富经验,我们可以沉淀一些业务资金规则,从旁路来约束和检测系统逻辑的正确性。比如支付金额-退款金额应该==结算金额,退款金额不能大于支付金额,凭证支付、现金支付无资金流类型不用调用账务,支付和账务之间会经过结算的处理,账务累计出入金额和支付的金额应该要相等。 3. 系统设计:3.1 总体设计的架构图如下:2.png
系统定位于事前线下测试环境兜底,事中一致性检测,事后资金兜底,不对业务造成入侵,完全旁路运行。触发点有 2 个,业务事件消息和数据库变更 binlog 信息。 分三类信息处理:
3.2 处理流程图如下:3.jpg
经过系统的沉淀之后,我们将过程中的数据存储到了 hbase,把整个支付过程落地成了可视化试图,可清晰的查看每个环节的数据形态,具体数据就不展示了。 4.png
退款完成环节支付、结算、计费、账务数据形态: 5.png
3.3 资金熔断:熔断的处理流程图如下: 6.png
基于我们之前建立的异常发现能力,同时我们需要具备资金止损能力。建立后台触发熔断操作入口,人工录入熔断配置或资损防控检测出异常新增并生效熔断配置,应急情况生效熔断,日常支付链路不会过熔断判断。
4. 总结:建立了这一整套体系后,半年时间内,我们已经在线下环境联调时就成功兜底资金处理 bug,线上也避免了多起问题。并定期的进行故障演练来检测平台能力。 有赞coder@2x.png
|
|