基于双引擎与灰度发布的实时风控方法及系统与流程

摘要: 本发明涉及风控决策,尤其涉及一种基于双引擎与灰度发布的实时风控方法及系统。背景技术:1、实时风控引擎是互联网业务反欺诈体系的核心基础设施,承担着对用户登录、交易...
基于双引擎与灰度发布的实时风控方法及系统与流程

本发明涉及风控决策,尤其涉及一种基于双引擎与灰度发布的实时风控方法及系统。

背景技术:

1、实时风控引擎是互联网业务反欺诈体系的核心基础设施,承担着对用户登录、交易支付、营销活动等关键业务场景进行毫秒级风险决策的职责。随着黑产攻击手段的不断升级,风控策略需要频繁更新以应对新型风险模式,这对风控引擎的规则动态配置能力和实时生效能力提出了极高要求。

2、目前,业界主流的实时风控引擎通常采用groovy脚本作为规则动态执行的核心技术方案。groovy作为一种与java无缝兼容的动态脚本语言,凭借其语法灵活、与java生态集成良好、支持运行时动态编译等优势,被广泛应用于风控规则引擎的构建中。风控运营人员可以通过管理后台实时编辑和发布groovy规则脚本,引擎在运行时动态加载并编译执行,从而实现规则的秒级生效。

3、groovy脚本在执行时,由groovyclassloader动态生成脚本类对象并加载至jvm元空间中。在风控场景下,规则策略的变更频率极高——新规则上线、旧规则调整、ab实验策略切换等操作均会触发新的groovy脚本编译。每次编译都会在元空间中产生新的class对象,而这些动态生成的脚本类对象由于被groovyclassloader的内部缓存所引用,无法被垃圾回收器正常回收。随着规则迭代次数的累积,元空间中被“废弃”的脚本类对象持续膨胀,最终触发`java.lang.outofmemoryerror: metaspace`异常,导致服务卡顿甚至宕机。业界虽有通过升级groovy版本、调整jvm元空间参数或定时重启服务等手段进行缓解的尝试,但这些方案要么治标不治本,要么以牺牲服务可用性为代价。apache groovy官方问题跟踪系统中亦有大量关于此问题的报告(如groovy-9068、groovy-7733),表明该问题是groovy脚本引擎在长期生产环境中普遍面临的顽疾。

4、风控引擎的预处理阶段包含大量简单的数学表达式计算,例如阈值比较(`amount>1000`)、算术运算(`price * quantity`)、逻辑组合(`age>= 18&&score>600`)等。这些表达式逻辑简单、计算量小,但若统一交由groovy脚本引擎处理,每次均需经历完整的脚本编译和类加载过程,编译开销远大于表达式本身的执行开销。同时,groovy脚本引擎缺乏针对表达式执行时长的细粒度超时控制机制,一旦某条表达式因数据异常或逻辑缺陷执行超时,可能长时间占用引擎线程,影响整体吞吐量。

5、针对groovy脚本内存泄漏问题,现有技术中已有部分改进方案被提出。有方案提出通过复用已编译脚本类并控制类加载器生命周期来缓解元空间压力,例如使用单例groovyclassloader、按脚本内容哈希值缓存编译产物等。然而,这些方案多聚焦于通用场景下的缓存复用,未能解决风控场景中规则频繁变更时“旧脚本如何精准清理”这一核心难题——仅靠缓存复用只能延缓内存增长,无法从根本上回收已失效脚本类所占用的元空间。另有方案提出通过lru缓存(容量1000)管理已编译脚本,但在规则高频变更场景下,lru淘汰策略无法保证被淘汰的脚本确实不再被使用,可能误淘汰仍处于灰度验证阶段的新规则脚本,导致缓存命中率下降和重复编译开销。

6、此外,现有风控系统大多采用单一脚本引擎架构,缺乏将轻量级表达式引擎与重型规则引擎按风控流水线层级进行职能分工的系统性方案设计。aviator等轻量级表达式引擎虽已具备高性能数学表达式计算能力,但现有技术中尚未见将其与groovy脚本引擎在风控流水线中进行分层协同、按场景分流的完整技术方案。

技术实现思路

1、有鉴于此,本发明实施例提供了基于双引擎与灰度发布的实时风控方法及系统,用以解决现有技术中因业务规则动态脚本化与高并发实时决策叠加,导致风控引擎在频繁热加载下易引发内存泄漏及服务卡顿,且单一脚本引擎无法兼顾轻量级数学表达式的高效计算与复杂逻辑判断,导致的系统稳定性差与决策响应延迟高的技术问题。

2、第一方面,本发明实施例提供一种基于双引擎与灰度发布的实时风控方法,包括以下步骤:

3、s1:配置风控元数据,所述风控元数据至少包括模型配置、字段定义、预处理项、抽象处理定义、规则定义和策略定义,并将所述风控元数据存储至元数据库,并通过redis发布订阅将配置变更同步至各风控引擎节点的本地缓存;

4、s2:接收业务系统提交的风控事件数据,所述风控事件数据至少包含事件标识和事件字段信息;

5、s3:对所述风控事件数据执行四层风控流水线处理;

6、s4:在执行策略决策层处理时,获取目标策略的线上版本标识和预发布版本标识以及灰度比例值,生成随机数,根据所述随机数与所述灰度比例值的比较结果,从所述线上版本和所述预发布版本中择一执行,输出风险等级决策结果;

7、s5:将所述风险等级决策结果返回至所述业务系统。

8、第二方面,本发明实施例提供一种基于双引擎与灰度发布的实时风控系统,包括一种计算机可读存储介质和处理器,存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现如上任一项所述的方法;还包括:

9、元数据管理模块,用于配置风控元数据并将所述风控元数据存储至元数据库;

10、缓存同步模块,用于通过redis发布订阅将所述风控元数据的配置变更同步至各风控引擎节点的本地缓存;

11、事件接入模块,用于接收业务系统提交的风控事件数据;

12、风控引擎模块,用于对所述风控事件数据执行四层风控流水线处理,所述四层风控流水线包括预处理层、抽象处理层、规则判断层和策略决策层;

13、所述预处理层包含aviator表达式引擎,用于执行轻量级数学表达式计算;

14、所述规则判断层包含groovy脚本引擎,用于执行规则脚本;

15、策略版本管理模块,用于维护各策略的线上版本标识、预发布版本标识和灰度比例值;

16、灰度分流模块,用于生成随机数并根据所述随机数与所述灰度比例值的比较结果从所述线上版本和所述预发布版本中择一执行;

17、决策输出模块,用于将风险等级决策结果返回至所述业务系统。

18、本发明提供的基于双引擎与灰度发布的实时风控方法及系统具有以下有益效果:

19、在本发明中,通过aviator表达式引擎与groovy脚本引擎在四层风控流水线中的分层协同与职能分工,实现了轻量级数学表达式高效计算与复杂规则逻辑判断的性能解耦;通过groovy脚本缓存池结合变更感知驱动的主动失效清理机制,在规则高频变更场景下有效控制了metaspace内存增长,消除了因脚本频繁热加载导致的full gc风险,解决了现有技术中动态脚本化与高并发决策叠加所引发的系统稳定性问题;同时,通过策略版本双轨模型与随机比例分流机制,实现了1%精度的流量灰度控制与一键回滚能力,并结合redis发布订阅的本地缓存热更新架构,在保障毫秒级决策延迟的前提下,实现了配置变更的实时生效与策略的安全发布;此外,离线回扫模块复用实时引擎核心逻辑,通过断点续跑、多节点终止与动态限流机制,实现了离线批量决策与实时决策的一致性和资源隔离。