AICon 北京站 Keynote 亮点揭秘,想了解 Agent 智能体来就对了! 了解详情
写点什么

资损防控体系介绍

  • 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:204547

评论 1 条评论

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

Java网络编程之InetAddress类详解,URL和URI的区别,URLDecoder和URLEncoder,IPv6和IPv4区别,IPv6的三种表示方法

共饮一杯无

Java 9月月更 URL和URI

阿里云林小平:如何实现资源高效运维及成本分析

阿里云弹性计算

运维 资源管理

Linux系统安装配置jdk

Centos 7 jdk8 9月月更

源于加速,不止加速-阿里云加速引擎的10年演化之路

阿里云CloudImagine

CDN CDN加速 CDN技术

长沙!《学习的学问》长沙分享会

博文视点Broadview

行业案例|长安汽车质量管理数据分析实践

Kyligence

质量管理 数据管理 长安汽车

中文稀疏GPT大模型落地——通往低成本&高性能多任务通用自然语言理解的关键里程碑

阿里云大数据AI技术

自然语言处理 多任务 企业号九月金秋榜 GPT

易周金融分析 | 多家银行试水特色网点揽客;自动驾驶颠覆传统车险模式

易观分析

自动驾驶 金融 银行 网点

OpenHarmony中的HDF单链表及其迭代器

OpenHarmony开发者

Open Harmony

软件测试 | 测试开发 | 数据持久化技术(Java)

测吧(北京)科技有限公司

测试

LeetCode-28. 实现strStr()(java)

bug菌

9月日更 Leet Code 9月月更

LeetCode-27. 移除元素(java)

bug菌

9月日更 Leet Code 9月月更

i++需要多少QPS才能测出BUG

FunTester

Netty高并发处理架构设计介绍

孙大卫

架构 Netty 开发框架 9月月更

TOP 5!望繁信科技获评WAIC2022全球创新项目路演优胜项目

望繁信科技

WAIC2022

SAP UI5 ManagedObject 的 Association 讲解

汪子熙

JavaScript typescript SAP UI5 ui5 9月月更

软件测试 | 测试开发 | Jenkins 踩坑(三)| Email 配置与任务邮件发送

测吧(北京)科技有限公司

测试

「趣学前端」骨架屏,分享一波前端UI组件开发的经验

叶一一

JavaScript 前端 组件 9月月更

「工作小记」多个批量操作的链式实现

叶一一

前端 设计思维 React Hooks 9月月更

找准风口,如何从运维转向 DevOps?

飞算JavaAI开发助手

FreeRTOS记录(二、FreeRTOS任务API认识和源码简析)

矜辰所致

源码分析 FreeRTOS 9月月更 任务API

【iOS逆向】某营业厅算法分析

小陈

产品需求文档必须消亡

ShineScrum

Scrum 敏捷 产品开发 PRD

如何使用Postman调试HMS Core推送接口?

HarmonyOS SDK

移动推送

阿里云弹性计算技术专家樊毅伟:云上成本优化实践

阿里云弹性计算

自动化运维 资源利用

C语言_1 背景,和Hello world

泾箐

c 9月月更

蒙特卡洛方法与蒙特卡洛搜索树(一)

Joshua

机器学习 算法 蒙特卡洛

C语言_2 变量

泾箐

c 9月月更

数据治理的内核:数据标准

小鲸数据

数据治理 大数据平台 数据管理平台 数据标准 大数据仓库

P8大佬私藏的:微服务与分布式系统实践详解,YYDS!

程序知音

Java 分布式 SpringCloud 后端技术 微服务架构师

C语言_3 选择结构

泾箐

c 9月月更

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