最近读了一些风控相关架构的文章，尝试做一些总结。原始文章来自 zhuanlan.zhihu.com/p/107975044。
相关paper总结在 github.com/linpingta/A…
网易
这是18年网易的一篇文章，首先对架构分层：
- 存储层：事件的原始数据，模型样本
- 计算层：指标计算，模型训练
- 引擎层：查询，规则，模型
- 服务层：对外提供的数据查询，风险监测，业务决策
规则引擎应用：举个例子，比如内审场景下，一个用户单日导出操作超过一定次数需要告警；登陆地不是正常登录地。这里会用到drools或者groovy。
事件接入中心：提供统一的对外接口，使得新业务很容易接入风控
指标计算模块：类似特征抽取，举个例子，100分钟内同一账户下单次数，这里会用到leveldb或者redis
蚂蚁
这个感觉是从业务角度划分风控的业务，并不太涉及技术架构。当然风控业务本身也非常复杂，或者说，相比搜广推更复杂，类似套现，捋羊毛，刷单，恶意占用库存或者点击，感觉需要比较深的业务理解。
携程
使用的也是主流的风控系统结构：
包含了决策引擎、Counter、名单库、用户画像、离线处理、离线分析和监控各主要模块。
- Counter类似pqm或者metric server这样提供一段时间内的时序数据，TSDB服务 == 时序数据库
- 数据层面提供比如用户画像的输入，订单的画像（用户等级、用户行为标签、订单资源标签等）
- 名单库服务，支持多个独立的名单库，优化了名单判断逻辑，使得单次查询（10个维度）的响应小于10ms
京东
也是分层角度看架构：数据层，模型层/工具层（应该是想说计算层），核心层（实际就是引擎层），最上面是服务层。
业务部分负责前台，然后风控中心提供中台服务（不过中台这个概念不知道现在还是不是在用，这似乎是20年左右的文章）。
规则引擎已经实现完全可视化配置。
美团
风控需要关注：谁、在什么时候、通过什么方式、对什么对象、做了什么。
风控和业务的解耦：让风控只和用户中心对接，因为它一定是对用户做的，业务本身只和用户中心对接，引入中间件。
架构看也是分层的：
总结
如果和搜广推对比，感觉风控场景是一个重离线（数据），轻在线（检索）的过程，或者说，风控更像是user profile这样的服务，或者user age/gender判断这样的服务。
风控场景也有高并发和低时延要求，但不会存在单个user + 众多物料（文章或者广告）场景，更像是user获取某个或者某些特征的服务，来进行决策的过程，所以也不存在类似搜广推的召回挑战，挑战更多在数据处理和准备上面。
