2. 实时风控系统架构：五层核心体系
实时风控系统需要在高并发、低延迟的苛刻环境下，完成从数据接入到决策输出的全链路处理。本章将系统拆解为数据采集层、特征计算层、模型推理层、决策引擎层、看板展示层五个核心层次，并阐述各层之间的数据流与协作关系。
2.1 五层架构总览
下图展示了实时风控系统的完整架构，数据从左至右依次流经各层，最终形成决策结果并反馈至看板。
2.2 各层职责与关键技术
| 层级 | 核心职责 | 关键技术 / 组件 | 延迟要求 |
|---|---|---|---|
| 数据采集层 | 接收用户行为、交易、设备等原始事件 | SDK 埋点、Kafka / Pulsar、Flume、Logstash | < 100ms |
| 特征计算层 | 对原始数据进行实时聚合、窗口计算、特征衍生 | Flink / Spark Streaming、Redis、CQEngine | < 50ms |
| 模型推理层 | 加载规则、评分卡、机器学习模型进行推理 | PMML / ONNX、TensorFlow Serving、规则引擎 | < 30ms |
| 决策引擎层 | 组合策略、执行熔断、降级、输出最终决策 | Drools、自研策略引擎、Sentinel | < 20ms |
| 看板展示层 | 实时展示指标、告警、样本回流状态 | Grafana、ECharts、Elasticsearch | 秒级刷新 |
2.3 数据采集层详解
数据采集层是风控系统的“触角”，负责将分散在各端的原始事件统一接入。常见的数据源包括：
- 客户端 SDK：采集设备指纹、GPS、APP 行为序列。
- 服务端日志：记录登录、注册、交易等业务事件。
- 消息队列：Kafka / Pulsar 作为缓冲层，削峰填谷，保证数据不丢失。
实践建议：数据采集层应具备幂等性和顺序性保障。对于关键事件（如支付），建议使用 Kafka 的 exactly-once 语义，避免重复或乱序导致特征计算错误。
2.4 特征计算层详解
特征计算层将原始事件转化为模型可用的数值特征。核心计算模式包括：
- 滑动窗口聚合：过去 5 分钟内的交易次数、金额总和。
- 行为序列特征：用户最近 10 次操作的时间间隔、设备切换频率。
- 外部数据关联：查询黑名单库、设备指纹库、IP 地理信息。
特征计算层通常使用 Flink 或 Spark Streaming 实现，配合 Redis 存储高频访问的中间结果。
2.5 模型推理层详解
模型推理层是风控系统的“大脑”，负责加载并执行风控模型。常见的模型类型包括：
| 模型类型 | 适用场景 | 推理方式 | 延迟敏感度 |
|---|---|---|---|
| 规则模型（决策树 / 评分卡） | 黑白名单、阈值判断 | 内存规则引擎 | 极高 |
| 机器学习模型（XGBoost / LR） | 欺诈检测、信用评分 | PMML / ONNX 推理 | 高 |
| 深度学习模型（RNN / GNN） | 序列异常检测、团伙识别 | TensorFlow Serving | 中 |
注意：模型推理层必须支持热加载和版本回滚。线上模型更新时，不能中断正在处理的请求，建议采用蓝绿部署或灰度发布策略。
2.6 决策引擎层详解
决策引擎层将模型推理结果与业务策略结合，输出最终决策。典型决策流程如下：
- 策略编排：按优先级依次执行规则（如：命中黑名单 → 直接拒绝）。
- 熔断机制：当模型超时或异常时，自动降级为备用规则。
- 决策输出：返回“通过 / 人工审核 / 拒绝”及对应的风险等级。
2.7 看板展示层详解
看板展示层是风控系统的“仪表盘”，为运营和算法团队提供实时监控能力。核心指标包括：
- 实时流量：QPS、TPS、请求成功率。
- 模型分布：各模型评分分布、拒绝率、通过率。
- 样本回流：已标注样本量、正负样本比例、模型漂移检测。
- 告警事件：特征异常、模型超时、策略命中率突变。
看板通常基于 Grafana + Prometheus 或 Elasticsearch + Kibana 构建，支持秒级刷新和自定义告警规则。
2.8 层间交互与数据流
下图展示了各层之间的数据流与关键交互接口：
2.9 架构设计要点总结
实时风控架构设计核心原则：
- 低延迟：全链路延迟需控制在 200ms 以内，特征计算和模型推理是主要瓶颈。
- 高可用：每层都需支持水平扩展和故障转移，避免单点故障。
- 可观测：看板层必须覆盖所有层的核心指标，支持快速定位问题。
- 可迭代：模型和策略需支持热更新，样本回流机制保证模型持续优化。