第2章：风控系统架构：整体架构分层与核心组件介绍

大家好，我是你们的老朋友。今天咱们聊聊风控系统的整体架构。

说实话，我见过不少团队一上来就撸代码，结果做到一半发现数据对不上、规则跑不动、接口超时。嗯，这就是典型的「架构没想清楚就开干」。我个人习惯，做风控系统之前，先把分层架构画清楚。

2.1 整体架构分层：三层模型

风控系统的架构，说白了就是三层：接入层、决策层、数据层。每一层各司其职，互不干扰。你想想看，如果这三层混在一起，那调试起来简直是一场噩梦。

下面这张图是我自己画的架构图，你可以直观地看到三层之间的关系：

2.2 接入层：风控系统的「门卫」

接入层是风控系统的第一道关卡。所有业务请求，不管是注册、登录、下单还是提现，都得先经过这里。

接入层主要干三件事：

• 请求接收与校验：检查参数格式、签名、时间戳。我在项目中遇到过，有个合作方传过来的时间戳是字符串格式，解析直接抛异常，差点把整个风控打挂。
• 限流与熔断：防止突发流量把决策层冲垮。我曾经见过一个场景，双十一凌晨流量暴涨10倍，接入层没做限流，决策层直接OOM。
• 协议转换：把业务方的HTTP请求转成内部RPC调用，或者丢进消息队列做异步处理。

2.3 决策层：风控系统的「大脑」

决策层是整个风控系统的核心。说白了，就是「给请求打分，然后决定怎么处理」。

决策层包含以下几个核心组件：

组件名称	功能说明	我的踩坑记录
规则引擎	执行if-then规则，比如「如果IP属于黑名单，则拒绝」	我曾经把规则写死在代码里，每次改规则都要发版，后来改用Drools才解脱
模型推理	加载机器学习模型，计算风险分数	模型文件太大，加载时内存爆了。后来改成按需加载+模型热更新
策略编排	组合多条规则和模型，形成完整的决策流程	策略编排的顺序很重要，我曾经把「白名单」放在「黑名单」后面，结果误杀了白名单用户
名单匹配	快速匹配黑白名单、灰名单	名单数据量大了之后，用MySQL查太慢，后来换成Redis的Set结构

决策层的输出一般有四种结果：通过、拒绝、人工审核、增强验证（比如发短信验证码）。

2.4 数据层：风控系统的「仓库」

数据层负责存储和提供风控所需的各种数据。没有数据，决策层就是瞎子。

数据层主要包含以下几类存储：

• 特征存储：存放用户画像、设备指纹、IP地理信息等。一般用Redis或HBase，要求毫秒级响应。
• 事件存储：记录每一次风控请求的原始数据，用于事后回溯和离线分析。我习惯用Kafka + ClickHouse。
• 离线数仓：存放历史数据，用于训练模型和生成报表。一般用Hive或Spark。
• 缓存：加速高频查询，比如名单数据、规则配置。Redis是标配。

嗯，这里要注意一点：数据层不要和业务数据库混在一起。我见过有人把风控特征直接写在业务库的user表里，结果业务方改表结构，风控直接崩了。数据层一定要独立部署。

2.5 核心组件之间的交互流程

咱们用一个实际场景串一下：用户发起一笔转账请求。

1. 接入层收到请求，校验参数和签名，没问题就转发给决策层。
2. 决策层先查名单匹配，发现用户不在黑名单里。
3. 接着执行规则引擎，检查转账金额是否超过单笔限额。没超，继续。
4. 然后调用模型推理，模型从数据层拉取用户近30天的交易特征，算出一个风险分数0.2（低风险）。
5. 策略编排综合判断：低风险 + 未命中黑名单 = 通过。
6. 决策层返回「通过」给接入层，接入层再返回给业务方。

整个过程，理想情况下应该在 100ms以内 完成。如果超过这个时间，用户体验就会变差。

2.6 架构设计的几个关键原则

最后，我总结几条实战中沉淀下来的原则：

• 无状态设计：每一层都不要保存业务状态，方便水平扩展。我见过有人把用户会话存在决策层内存里，扩容后全丢了。
• 异步优先：非核心路径（比如日志记录、离线分析）走异步，不要阻塞主流程。
• 降级兜底：每个组件都要有降级方案。比如名单服务挂了，就默认放行（或者默认拒绝，看业务场景）。
• 可观测性：每一层都要输出日志、指标、链路追踪。不然出了问题，你连锅都找不到。

好了，这一章的内容就到这里。架构分层是风控系统的骨架，骨架搭好了，后面填肉（具体实现）就轻松多了。

---