互联网风控系统架构分析
Posted tangsilian
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了互联网风控系统架构分析相关的知识,希望对你有一定的参考价值。
本文简单介绍风控具体是做什么的,以及一些常见的风控系统实现的架构。文章目录
前言
虽然都是从事安全相关工作,而风控一直都是比较神秘的存在。仅大概模糊了解一些风控规则,实际不知道风控系统具体如何实现,如何与业务打通,如何持续运营?带着这些问题,我抽空学习看了一些友商关于风控的实践及开源的风控引擎。把一些个人理解和大家分享一下。友商相关的风控实践:
网易严选风控实践:https://sq.163yun.com/blog/article/183304443737464832
携程在线风控系统架构:https://mp.weixin.qq.com/s/muufqznNNVidPgamlcurCQ
蚂蚁金服智能风控引擎AlphaRisk介绍:https://www.docin.com/p-2222786093.html
阿里风控大脑关于大数据应用的探索与实践:https://www.bilibili.com/read/cv4178932/
相关的风控开源项目如下:
风控项目 | 备注 |
---|---|
六道 —实时业务风控系统 | 同程应急安全响应中心 java系 |
radar实时风控引擎 | java系 |
陌陌风控系统静态规则引擎 | 陌陌 python |
星云(TH-Nebula)业务风控系统介绍 | 威胁猎人 java系 |
一、互联网风控是做什么的?
风控的定义
首先了解两个概念:风险管理和风险控制。
风险管理:是指如何在项目或者企业在一定的风险的环境里,把风险减至最低的管理过程。它的基本程序包括风险识别、风险估测、风险评价、风险控制和风险管理效果评价等环节。
风险控制:是指风险管理者采取各种措施和方法,消灭或减少风险事件发生的各种可能性,或者减少风险事件发生时造成的损失。所以其实风险控制是风险管理中的一个环节。
在互联网行业,风控是在各个业务场景(注册、登录、交易、活动等等)下风险控制的简称,一般称为业务安全风控团队。常根据不同的场景划分为账号安全风控、内容风控、支付风控、交易风控、活动风控等。
业务安全团队的职能就是在各个业务场景中对抗着各类的薅羊毛,欺诈、盗号、作弊、套现以及营销活动被恶意刷单、恶意抢占资源等风险行为,从而保障业务安全。采用的主要措施和手段就是在业务请求中识别出谁、在什么时间、通过什么方式、做了什么事,而风控系统就是为了帮助业务风控同学实现上述流程而构造的系统。
二、常见风控系统的实现架构
1.风控系统的架构
风控系统的定义:根据业务系统传来的数据或埋点信息来判断当前用户或事件有无风险;
早期简单的风控系统如上图:
- 服务架构:一般由springboot构建,通过RPC/HTTP 接口来接收业务传输的数据。
- 核心处理逻辑:在短时间内通过规则引擎中配置的规则对数据进行处理,将结果返回给业务方,最后由业务方决策阻断还是放行。
- 存储逻辑:使用redis高速缓存着黑白名单,redis、mongodb用于词频统计,排序,聚合等计算。mysql存储着风控配置开关。
而随着业务场景复杂,分析数据的体量变大,风控系统中慢慢引入更多功能,来满足各类型业务的需求。
2.风控的系统流程
现阶段风控系统处理流程一般分为: 实时引擎,近实时引擎和离线引擎。
实时引擎:
实时风控是整个系统的核心,被业务系统同步调用,完成对应的风控判断。一般风控接口的对处理耗时要求比较高,接口正常及格线T999在50ms左右,才能尽量降低风控逻辑对业务的影响。
准实时引擎(异步的实时计算):
这个流程一般后台逻辑,为风控系统服务,准备和统计实时计算需要的事实数据。
比如:有些规则判断需要事实的相关指标,比如最近一小时登陆次数,最近一小时注册账号数等等,这些指标通常有一段时间跨度,是某种状态或聚合,很难在实时风控过程中根据原始数据进行计算,因为风控的规则引擎往往是无状态的,不会记录前面的结果。从而通过近实时引擎汇总统计全局的检测状态,准备中间数据,以及更新设备及用户最近的交易时间和地点等属性。同时也可以对比同期指标,当某条规则的拦截率突然发生较大变化、全局通过率突然增高或降低等等。
由于近实时处理的原始数据量很大,用户活动的原始数据都要传过来进行计算,这部分往往由一个流式大数据系统来完成。常见的是使用Flink或者storm来对kafka中的消息进行处理。
离线引擎:业务对于风控策略误伤的容忍度低,需要离线流程对样本回溯分析、用历史数据来验证影响。同时离线流程对线上模型就行评估,并发现线上策略漏过的数据,补齐能力到线上模型。
离线引擎常用spark进行为H+1,T+1的定时任务调度来对hive数据分析来实现。
三、核心风险识别环节
从业界风险的案例来看,早期的风控的核心处理逻辑都是基于专家对异常用户的历史数据做统计分析,找出异于正常用户的特征编写成规则。而随着业务场景和数据量的增加。现阶段都利用生产力更高的算法模型对大数据进行分析,主动发现异常特征,提前识别。目前常见的风控系统是静态规则和模型两种技术的融合。
1.规则及规则引擎
什么是规则,规则的分类是什么,什么又是规则引擎?
风控的规则是什么?
举个列子:在一些登录场景,为了对抗账号登录的爆破,同一个账号密码输入错误超过三次,账号登录即会受到限制。对应的风控规则可能是同一天内,一个账号,连续登录失败三次。
常见的规则分类:
- 静态规则:基于某个静态值的限制性规则,比如是否命中黑名单、常用联系人验证、电信服务使用地理范围验证等
- 统计规则:用统计计算的值来作为验证的条件,如来自某个设备或者IP的申请次数大于某个值
- 关联规则:指用户在进行了某个操作之后,又执行另外一个操作,带来的风险。例如,修改账号密码后,进行交易操作
- 行为规则:指用户的异常行为,例如用户在非常驻地址,非常用的设备,非常用的时间,进行了交易操作,一般也认为具备一定的风险。
常用的开源规则引擎:
早起硬编码编写的规则方式不方便维护和协同开发,如果逻辑过多代码冗余且无法更改。遂在风控规则上,业界都将业务决策从应用程序代码中分离出来,使用规则引擎的方式来编写,并根据业务规则做出业务决策。
常见成熟的规则引擎有Drools和Groovy。
Drools规则:
Drools和Java环境结合的非常好,本身也非常完善,支持很多特性,不过使用比较繁琐,有较高门槛,规则都是用java语言编写,规则文件为rules/*.drl。如下是Drools编写的一条,单个IP上登录的手机号超过20风险值就加1的规则。
package rules; --规则包路径
import com.example.riskcontrol.model.LoginEvent --引入类
import com.example.riskcontrol.service.DimensionService
import com.example.riskcontrol.model.EnumTimePeriod
global DimensionService dimensionService --引入外部服务
rule "98_login_ip" --规则名称,全局唯一
salience 98 --规则优先级,值越大越先执行
lock-on-active true --事件不重复执行该规则
when --条件判断,是否需要进入action
event:LoginEvent() --判断事件对象是否是LoginEvent类
then --action
int count = dimensionService.distinctCount(event,new String[]LoginEvent.OPERATEIP,
EnumTimePeriod.LASTHOUR,LoginEvent.MOBILE); --近1小时内该事件ip上出现的mobile数量统计
if(event.addScore(count,20,10,1)) --如果统计结果超过20个,则记10分,并且结果每超1个,再多记1分
dimensionService.insertRiskEvent(event,"近1小时内同ip出现多个mobile,count="+count); --记录风险事件日志
end --结束规则
drools的详细文档,请参考官方 http://docs.jboss.org/drools/release/6.4.0.Final/drools-docs/html_single/index.html
Groovy规则:
groovy是一种基于jvm的脚步语言,由于其语法简单,对java程序员入手简单,且能无缝衔接使用java的开源库.在java中运行Groovy脚本,有三种比较常用的类支持:GroovyShell、GroovyClassLoader 以及 Java-Script引擎。
以GroovyShell为例:允许在Java类中(甚至Groovy类)求任意Groovy表达式的值。可使用Binding对象输入参数给表达式,并最终通过GroovyShell返回Groovy表达式的计算结果。
import groovy.lang.Binding;
import groovy.lang.GroovyShell;
import groovy.lang.Script;
public class Demo
public static void main(String[] args)
// 绑定变量到 groovy 执行环境
Binding binding = new Binding();
binding.setVariable("foo", new Integer(2));
// 构建 groovy script
GroovyShell shell = new GroovyShell();
Script script = shell.parse("println 'Hello World!'; x = 123; return foo * 10");
script.setBinding(binding); // 绑定
// 执行脚本
Object value = script.run();
// 执行结果
System.out.printf("执行结果:%s, 类型: %s\\n", value, value.getClass().getCanonicalName());
// 获取执行过程中的变量
System.out.printf("执行过程中的x变量:%s, 类型: %s\\n", binding.getVariable("x"), binding.getVariable("x").getClass().getCanonicalName());
执行结果:
Hello World!
执行结果:20, 类型: java.lang.Integer
执行过程中的x变量:123, 类型: java.lang.Integer
2.特征模型
受限于认知和生产力,人工提取规则只能识别到认知内的风险。而通过有监督和无监督学习的方式能自动化的分类和识别出未知的风险。目前还是LR模型最稳定常用,新的机器学习模型算法XGboost,FFM等模型或许还需要一段时间的实践和迭代。
总结
通过此文我们了解到了互联网公司业务风控具体介入的环节和场景,风控系统实现的架构,以及风控风险识别的实现方式及相关流程。
参考
以上是关于互联网风控系统架构分析的主要内容,如果未能解决你的问题,请参考以下文章