2、实时风控系统架构:数据采集层、实时计算层、规则引擎层、决策输出层
实时风控系统是异常交易人群切片的“作战指挥中心”。一个高可用、低延迟的实时风控架构,通常由四个核心层次构成:数据采集层、实时计算层、规则引擎层和决策输出层。每一层各司其职,又通过标准化的数据接口紧密协作,共同保障从交易事件发生到风险决策输出的端到端延迟控制在毫秒级。
架构设计原则:实时风控架构必须满足“高吞吐、低延迟、可扩展、不丢数”四大核心要求。数据采集层负责“接得住”,实时计算层负责“算得快”,规则引擎层负责“判得准”,决策输出层负责“打得通”。
2.1 数据采集层
数据采集层是整个风控系统的“传感器网络”,负责从各类业务系统、中间件和日志流中实时捕获交易事件、用户行为、设备指纹等原始数据。该层必须保证数据采集的完整性、实时性和可靠性,避免因数据丢失导致漏报。
| 数据源类型 | 典型数据内容 | 采集方式 | 延迟要求 |
|---|---|---|---|
| 交易系统 | 订单号、金额、商品、支付渠道 | MQ(Kafka/RocketMQ) | < 50ms |
| 用户行为 | 点击、浏览、停留时长、页面跳转 | 埋点SDK + 日志采集 | < 200ms |
| 设备指纹 | 设备ID、IP、MAC、浏览器指纹 | JS/App SDK 上报 | < 100ms |
| 黑名单/灰名单 | 历史风险实体(账号、IP、设备) | 缓存同步 + 增量更新 | < 1s |
关键指标:数据采集层需支持至少 10万 TPS 的写入能力,并具备数据去重、时间戳对齐、字段校验等预处理能力,避免脏数据进入下游计算层。
2.2 实时计算层
实时计算层是风控系统的“大脑”,负责对采集到的原始数据进行实时清洗、特征加工、聚合计算和上下文关联。该层通常基于 Flink、Spark Streaming 或 Storm 等流计算引擎构建,通过时间窗口、状态管理和CEP(复杂事件处理)技术,生成规则引擎所需的实时特征变量。
- 特征加工:将原始字段转换为标准化特征,如“近5分钟交易次数”、“跨设备登录次数”、“IP归属地变更频率”。
- 时间窗口聚合:支持滑动窗口(如过去1小时交易总额)和滚动窗口(如当日累计失败次数),窗口粒度可配置。
- 上下文关联:将当前交易与历史行为画像、设备指纹库、关系图谱进行实时关联,识别异常模式。
- 状态管理:维护用户、设备、IP等维度的实时状态,支持状态过期和快照恢复。
// 示例:Flink SQL 实时特征计算(近5分钟交易次数)
CREATE VIEW recent_txns AS
SELECT
user_id,
COUNT(*) AS txn_count_5min,
SUM(amount) AS txn_amount_5min
FROM transaction_stream
WHERE event_time BETWEEN CURRENT_TIMESTAMP - INTERVAL '5' MINUTE AND CURRENT_TIMESTAMP
GROUP BY user_id;
2.3 规则引擎层
规则引擎层是风控策略的“执行中枢”,负责将业务风控策略(如“单日交易超5笔且金额大于1万元”)转化为可执行的规则集,并基于实时计算层输出的特征变量进行高效匹配。规则引擎需要支持动态加载、热更新、优先级排序和规则冲突检测。
| 规则类型 | 示例 | 执行方式 | 典型响应时间 |
|---|---|---|---|
| 阈值规则 | 单笔金额 > 50000 | 数值比较 | < 1ms |
| 频率规则 | 近1小时交易次数 > 10 | 窗口计数比较 | < 5ms |
| 名单规则 | 设备ID命中黑名单 | 缓存查询 | < 2ms |
| 复合规则 | 新设备 + 异地IP + 大额交易 | 多条件组合 | < 10ms |
| 机器学习模型 | XGBoost 风险评分 > 0.8 | 模型推理 | < 20ms |
避坑提示:规则引擎层切忌“规则爆炸”。当规则数量超过500条时,需引入规则分组、决策树剪枝或RETE算法优化匹配效率,否则会导致CPU飙升、延迟恶化。
2.4 决策输出层
决策输出层是风控系统的“执行终端”,负责将规则引擎的判定结果(通过/拒绝/人工审核/增强验证)转化为具体的业务动作,并同步记录决策日志、触发告警、更新风险画像。该层需要与业务系统(交易、支付、账户)通过RPC或MQ进行松耦合对接,确保决策结果能够快速生效。
- 动作执行:阻断交易、要求短信验证、触发人脸识别、加入观察名单等。
- 日志回写:将决策结果、特征快照、规则命中详情写入离线数仓,用于事后分析和模型迭代。
- 告警通知:对高风险决策(如命中黑名单、金额异常)实时推送告警给风控运营人员。
- 画像更新:实时更新用户/设备/IP的风险标签和统计特征,供后续交易使用。
// 决策输出示例(伪代码)
if (riskLevel == HIGH) {
blockTransaction(orderId);
sendAlert("高风险交易拦截", orderId, riskScore);
updateUserRiskTag(userId, "high_risk");
} else if (riskLevel == MEDIUM) {
requireSmsVerification(orderId);
addToWatchList(userId);
} else {
approveTransaction(orderId);
}
2.5 架构分层对比与选型建议
不同业务规模和延迟要求下,各层的技术选型存在差异。下表总结了主流技术栈及其适用场景,帮助你在实际项目中做出合理选择。
| 架构层 | 主流技术栈 | 适用场景 | 注意事项 |
|---|---|---|---|
| 数据采集层 | Kafka、RocketMQ、Flume、Logstash | 高吞吐、异步解耦、多数据源 | 关注消息可靠性(ACK机制)和顺序性 |
| 实时计算层 | Flink、Spark Streaming、Kafka Streams | 复杂事件处理、状态管理、CEP | Flink 在低延迟和状态管理方面更优 |
| 规则引擎层 | Drools、EasyRules、自研规则引擎 | 动态规则、热更新、复杂条件组合 | 自研引擎更灵活,但需关注性能优化 |
| 决策输出层 | Dubbo、gRPC、Kafka、Redis | 高并发决策分发、日志持久化 | 输出动作需幂等设计,防止重复执行 |
架构选型口诀:采集用MQ保吞吐,计算用Flink保实时,规则用引擎保灵活,输出用RPC保可靠。四层联动,缺一不可。
实操建议:在搭建实时风控系统时,建议先以“数据采集层 + 规则引擎层”为核心快速上线,再逐步引入实时计算层进行特征增强。初期可复用业务系统的MQ和简单的阈值规则,降低架构复杂度。