3. 实时风控系统架构设计：整体架构分层与数据流闭环

实时交易风控系统对延迟和准确性有极高要求，通常采用分层解耦的架构设计。每一层承担明确的职责，通过标准化的接口进行通信，从而支持高并发、低延迟和持续迭代。本章将详细阐述接入层、计算层、存储层、决策层的核心设计，以及贯穿其中的数据流与反馈闭环机制。

3.1 整体架构分层总览

实时风控系统架构自上而下分为四个核心层次，各层之间通过消息队列或RPC进行异步或同步调用，确保系统的高可用与可扩展性。

3.2 接入层：流量入口与第一道防线

接入层是风控系统的第一道关卡，负责接收来自交易系统、支付网关、移动端SDK等上游的请求。其核心设计要点包括：

• 协议适配： 统一将HTTP/gRPC/Thrift等不同协议转换为内部标准协议（如Protobuf），屏蔽上游差异。
• 流量整形： 使用令牌桶或漏桶算法进行限流，防止恶意流量或突发峰值压垮下游计算层。
• 请求鉴权： 校验请求签名、AppKey、时间戳等，拦截非法请求。
• 初步清洗： 过滤明显异常的字段（如空值、超长字符串、非法字符），降低计算层无效负载。

3.3 计算层：特征与模型的核心战场

计算层是实时风控的“大脑”，负责在毫秒级时间内完成特征提取、规则匹配和模型推理。该层通常分为三个子模块：

1. 实时特征计算： 基于Flink或Spark Streaming，对交易事件进行滑动窗口聚合（如“过去5分钟该用户交易次数”、“过去1小时该设备登录IP数”），输出实时特征。
2. 规则引擎： 执行由风控专家配置的决策树、评分卡或阈值规则（如“交易金额 > 5000 且 设备为新设备”）。规则引擎通常支持热更新，无需重启服务。
3. 模型推理： 调用Model Server（如Triton Inference Server、TorchServe）加载的机器学习模型（XGBoost、DNN等），输出风险概率或分数。

3.4 存储层：多级缓存与冷热数据分离

存储层需要同时满足高吞吐写入和低延迟读取的需求。设计上采用冷热数据分离策略：

• 热数据（毫秒级）： 使用Redis Cluster存储用户画像、设备指纹、实时计数器、黑/白名单。所有数据均设置TTL，自动过期。
• 温数据（秒级）： 使用HBase或Cassandra存储近期的交易流水、特征快照，支持按时间范围快速扫描。
• 冷数据（分钟级+）： 使用Elasticsearch或ClickHouse存储历史交易明细、模型日志，用于离线分析和模型训练。

3.5 决策层：综合评分与处置闭环

决策层接收计算层输出的规则结果和模型分数，进行综合评分，并执行最终处置动作。其核心流程如下：

• 综合评分： 将规则命中结果、模型分数、设备指纹、IP信誉分等通过加权融合或决策矩阵，生成最终风险等级（如：低风险、中风险、高风险）。
• 处置动作： 根据风险等级执行对应动作：放行、人工审核、增强验证（如短信OTP）、拒绝交易。
• 结果输出： 通过回调接口或消息队列将决策结果返回给上游交易系统，同时将决策日志写入存储层。

3.6 数据流与反馈闭环

实时风控系统的生命力在于反馈闭环。一次完整的交易风控数据流包含以下环节：

1. 请求进入： 交易请求经接入层清洗后，生成标准事件。
2. 特征计算： 计算层从存储层读取实时状态，结合当前事件计算特征。
3. 规则+模型： 特征送入规则引擎和模型推理，输出中间结果。
4. 决策输出： 决策层综合判断，输出处置动作，并异步写入日志。
5. 反馈回流： 人工审核结果、用户后续行为（如是否申诉成功）被采集，反馈至特征存储和模型训练管道，用于更新规则阈值或重新训练模型。

3.7 关键设计要点总结

• 异步解耦： 层间通信优先使用消息队列（Kafka/Pulsar），避免同步调用链路过长导致延迟雪崩。
• 降级与熔断： 当存储层或模型推理出现故障时，计算层应具备降级策略（如跳过模型推理，仅使用规则），确保核心交易链路不中断。
• 可观测性： 每一层都需要暴露延迟、吞吐量、错误率等核心指标，配合分布式追踪，实现端到端的延迟分解和故障定位。
• 灰度发布： 规则和模型的更新应支持灰度切换，先在小比例流量中验证效果，再全量上线。