《HarmonyOS:领航者说》技术公开课来啦,大咖分享、实战解码,不容错过 了解详情
写点什么

资损防控体系介绍

  • 2020-03-11
  • 本文字数:2038 字

    阅读完需:约 7 分钟

资损防控体系介绍

一、资损盲区

随着有赞支付体量的增大,资产部门承担的资金管理,风险把控的责任也越大。我们一方面要小步快跑,快速支撑业务,又要稳住底盘,守好底线。支付业务底线就是守护用户的每一分钱,不能有资金损失。在我们搭建这套体系前,有赞支付资金类的线上监控是个盲区,缺乏自我发现的能力。业务成功了,但内部对用户的资金操作可能是错误的,导致资损。而且故障发生到发现的时间很长,且大部分是用户上报,导致故障的影响面扩大,用户的信任度降低。


预防资损有很多种手段,除了事前线下通过各种测试手段保障资金安全外,线上也是非常重要的一环。除了发现问题,相应的,出现故障时,资损止血的能力也需要配套跟上。


举一个最基础的支付业务场景,在有赞内部会经历以下几个系统之间的交互:



通过上图可以看出每个系统的处理结果,会依据系统建立的模型存储在数据库中,部分关键信息会传输给下层系统。系统之间处理的重要信息如金额、账户不一致就会导致资损。目前我们内部对账也会发现这些问题,但是内部对账是每天执行一次,依靠内部对账来发现问题,时效性太低,会导致影响面扩大。且需要调用很大的人力物力去追款。我们分析了有赞近一年来的资损场景,结合历史的经验,总结出资损类故障发生有几下几大类:


1)正确的输入,错误的输出:比如系统与系统之间的金额存储单位不一致,或者自己处理金额正确,传输给下游的金额错误,导致后面交易金额错误


2)上下游系统的数据不一致:该处理的没处理,该到达终态的单据没有到达终态


3)幂等控制失效,多扣款或多入账


4)系统内部逻辑错误,无对外输出


5)人工修复异常场景,产生资损

二、资损体系的诞生

基于解决以上问题的目的,我们设计了实时防控资损体系。总体设计思路围绕以下几点:


1)发现问题的实时性,减少故障的影响面


2)信息流一致性两两比对、资金流平衡型检查


3)全方位监控:业务触发、人工变更资金检测、历史数据检测


4)检测的准确性,无误报


5)和支付链路解藕,不影响主链路


平台能力是基础,检测规则是其灵魂。基于对业务的丰富经验,我们可以沉淀一些业务资金规则,从旁路来约束和检测系统逻辑的正确性。比如支付金额-退款金额应该=结算金额,退款金额不能大于支付金额,凭证支付、现金支付无资金流类型不用调用账务,支付和账务之间会经过结算的处理,账务累计出入金额和支付的金额应该要相等。

三、系统设计

  1. 总体设计的架构图如下:



系统定位于事前线下测试环境兜底,事中一致性检测,事后资金兜底,不对业务造成入侵,完全旁路运行。触发点有 2 个,业务事件消息和数据库变更 binlog 信息。


分三类信息处理:


  1. 基于各个业务事件比如支付完成事件、退款完成事件、确认收货时结算完成事件,账务收支明细变更事件等,触发运行系统内配置的依赖此事件的规则

  2. 通过监听 binlog 变更,可以检测到人为操作类变更, 按定义好的逻辑生成对应的检查点, 每个检查点有包含多个链路检测。触发对应的规则运行检测全链路数据的一致性、资金的平衡性

  3. 人工处理历史数据前,对历史数据的质量进行前置检测。保证不产生二次资损


通过系统间两两核对数据一致性,或者抽象出系统内的业务规则、资金规则旁路自检来发现故障。并且实时获取数据,实时运行,对于业务处理上有滞后和缓冲的场景,我们提供了异步运行的机制,以及三次重试的机会。全面提供系统整体的容错性,无因系统设计问题导致的误报。


  1. 处理流程图如下:



经过系统的沉淀之后,我们将过程中的数据存储到了 hbase,把整个支付过程落地成了可视化试图,可清晰的查看每个环节的数据形态,具体数据就不展示了。


比如一笔订单可以看到,当前已经是退款完成状态,对应的支付成功时支付、结算、计费、账务数据形态:



退款完成环节支付、结算、计费、账务数据形态:



  1. 资金熔断:


熔断的处理流程图如下:



基于我们资金异常发现能力建设完成后,我们开始逐步将整个体系完善,补充了发现异常后资金熔断止损能力。通过建立后台触发熔断操作入口,并在业务关键节点进行埋点,人工录入熔断配置或资损防控规则检测出异常自动生效熔断配置,异常应急生效熔断。日常支付链路则不会过熔断判断,以免系统稳定性对主链路造成影响。支持按业务码、指定的单号、商户号纬度来熔断。


目前在业务方接入的熔断埋点有 3 个点:退款、结算、出金。为什么考虑这三个地方埋点呢?


  1. 我们整个系统的定位都是不侵入主链路,对用户无感知的,所以支付环节不考虑埋点。且钱不能流出有赞的体系外,一旦流出则无法追回

  2. 在支付链路产生的故障,考虑在退款、结算环节来做拦截,且支付完成后,钱停留在有赞的中间户,此时订正支付链路数据,对商户来说无感知

  3. 一旦在结算环节出现问题,则考虑最后一道兜底,出金报送银联前进行拦截。


确认无误或故障处理完成后,触发解熔断操作,业务继续处理或驳回

四、总结

建立了这一整套体系后,半年时间内,我们已经在线下环境联调时就成功兜底资金处理 bug,线上避免了多起问题。并定期的进行故障演练来检测平台能力。


本文主要介绍大体的设计和实现思路,后续会有详细的技术细节介绍,敬请期待。资损防控路漫漫,共勉。


2020-03-11 22:204573

评论 1 条评论

发布
用户头像
点赞
2020-05-27 11:40
回复
没有更多了
发现更多内容

万界星空科技|免费开源MES系统|自动排产管理

万界星空科技

开源 MES系统

PHP/MySQL开发环境 MAMP Pro for Mac激活安装

胖墩儿不胖y

Mac软件

基于装饰器——我劝你不要在业务代码上装逼!!!

Immerse

生成式AI:助力网络安全,挑战与机遇并存

百度开发者中心

人工智能 网络安全、 生成式AI 文心一言

生成式AI:重新定义生产力与创造力

百度开发者中心

人工智能 ChatGPT 生成式AI 文心一言

Clang编译数据库信息扩展

maijun

Clang 编译数据库

大数据平台三大优势详解-行云管家

行云管家

数据库 大数据 数据安全 大数据平台

Graph + LLM 实践指南|如何使用自然语言进行知识图谱构建和查询

悦数图数据库

数据库 图数据库

HarmonyOS“一次开发,多端部署“优秀实践——玩机技巧,码上起航

HarmonyOS开发者

HarmonyOS

软件测试/测试开发丨Python 学习笔记 之 链表

测试人

Python 程序员 软件测试 自动化测试 测试开发

生成式AI领先,实现客服机器人真智能

百度开发者中心

人工智能 机器人 生成式AI 文心一言

Presto 设计与实现(十二):SQL 逻辑计划

冰心的小屋

数据湖 presto 设计与实现 SQL Plan

面试了38位Java候选人之后,我总结出了他们关于面试中的16条通病

程序员小毕

Java 程序员 面试 简历 八股文

生成式AI助力文学艺术创作

百度开发者中心

人工智能 艺术 文心一言

Graph + LLM|图数据库技术如何助力行业大语言模型应用落地

悦数图数据库

数据库 图数据库

打造千亿文件量级的大规模分布式文件系统

Baidu AICLOUD

文件系统 分布式文件存储 元数据

大数据平台与数据仓库的五大区别

行云管家

大数据 数据仓库 数据安全 大数据平台

TDD、BDD、ATDD都是什么、有什么区别?(上)

禅道项目管理

MegEngine 使用小技巧:Profiler使用手册

MegEngineBot

开源 性能优化

​iOS上架审核宝典:如何避免被拒一次提交成功

ios

生成式AI:业务流程的变革与机遇

百度开发者中心

人工智能 生成式AI 文心一言

2023年广州国际大健康产品及健康食品展会

秋硕展览

2023健博会 保健用品展 护理用品

如何使用io_uring构建快速响应的I/O密集型应用?

华为云开发者联盟

开发 华为云 华为云开发者联盟 企业号 8 月 PK 榜

没有永远的王者…Zig替代C,将成定局!

互联网工科生

C语言 C++ Zig语言

资损防控体系介绍_文化 & 方法_有赞技术_InfoQ精选文章