2. 风控网关整体架构：请求入口、策略引擎、决策流、数据管道、回放模块的拓扑关系

实时风控网关并非单一服务，而是一套由多个高内聚、低耦合模块组成的拓扑结构。理解各模块之间的数据流向与依赖关系，是进行效果评估与回放对比的前提。本章从请求入口开始，沿决策链路逐步展开，直至回放模块的闭环反馈。

2.1 拓扑总览：五层核心模块

风控网关整体采用“管道-过滤器”架构风格，核心模块按数据流动顺序分为五层：

2.2 请求入口：网关的第一道防线

请求入口是风控网关对外的统一门面，负责接收所有业务请求（HTTP/gRPC/消息队列），并完成以下预处理：

• 协议适配： 将不同协议转换为内部统一的事件格式（Event Envelope）。
• 流量整形： 基于令牌桶或漏桶算法进行限流，防止突发流量击穿下游。
• 身份认证： 校验 API Key、签名、Token，拒绝非法请求。
• 上下文注入： 附加请求 ID、时间戳、来源 IP 等元数据，供后续链路追踪。

请求入口不执行任何风控逻辑，只做“快速通过或拒绝”的二元决策，其延迟通常控制在 1ms 以内。

2.3 策略引擎与决策流：核心决策中枢

策略引擎负责加载和执行具体的风控策略，而决策流则负责编排这些策略的执行顺序与条件分支。两者协同工作，形成完整的决策链路。

2.3.1 策略引擎的内部结构

• 规则库： 存储 if-then 规则，支持正则、数值范围、名单匹配。
• 模型容器： 加载机器学习模型（XGBoost、神经网络），提供推理接口。
• 名单缓存： 本地 LRU 缓存 + 远程 Redis，用于黑/白/灰名单快速校验。
• 版本管理： 每个策略都有独立版本号，支持 A/B 测试和灰度发布。

2.3.2 决策流的执行模型

决策流采用有向无环图（DAG）执行模型，每个节点代表一个策略或一个条件分支：

1. 开始节点： 接收请求入口传递的事件。
2. 策略节点： 调用策略引擎执行具体规则或模型。
3. 条件节点： 根据策略结果（通过/拒绝/人工审核）路由到不同分支。
4. 聚合节点： 合并多个策略的输出，生成最终决策（Pass / Reject / Review）。
5. 结束节点： 将决策结果写回响应，并触发数据管道。

2.4 数据管道：全量事件的可回溯基石

数据管道是风控网关的“黑匣子”，负责将每个请求的完整上下文、中间特征、最终决策持久化到存储层，供后续离线分析、模型训练和回放对比使用。

数据管道采用“异步写 + 批量刷盘”策略，避免对在线决策链路产生性能影响。当回放模块启动时，直接从数据管道读取历史快照，无需侵入在线服务。

2.5 回放模块：离线对比的闭环

回放模块是风控网关区别于普通规则引擎的关键组件。它允许工程师将历史流量“重放”到新的策略版本或模型上，对比新旧决策的差异，从而量化评估效果。

2.5.1 回放流程

1. 流量录制： 从数据管道中按时间范围拉取请求快照和特征日志。
2. 时间戳对齐： 确保回放时的系统时间与录制时的相对顺序一致，避免因时间依赖特征（如频次统计）导致偏差。
3. 重演执行： 将请求依次送入目标策略版本，记录每个节点的输出。
4. 差异比对： 将新结果与原始决策结果进行逐字段对比，生成差异报告。
5. 结果快照： 将回放结果持久化，供后续可视化分析。

2.5.2 回放模块的拓扑位置

回放模块在逻辑上独立于在线决策链路，它通过“旁路”方式接入数据管道，不干扰生产环境。其典型部署方式为：

• 离线集群： 与在线服务物理隔离，使用独立的计算资源。
• 数据源： 只读副本，避免对在线存储产生写入压力。
• 输出： 差异报告写入回放索引库，供前端评估面板查询。

2.6 拓扑关系 SVG 图

下图展示了风控网关五层模块之间的数据流向与依赖关系，重点突出请求入口→策略引擎→决策流→数据管道的在线链路，以及回放模块的离线旁路接入方式。

2.7 模块间交互时序

为了更清晰地展示各模块在单个请求生命周期中的交互顺序，下图以时序图形式呈现：

2.8 拓扑设计的关键考量

• 解耦原则： 请求入口与策略引擎之间通过事件总线通信，任一模块的升级不影响其他模块。
• 可观测性： 每个模块必须暴露延迟、吞吐量、错误率三个黄金指标，数据管道负责统一采集。
• 回放隔离： 回放模块必须使用独立的数据源副本，避免对在线存储产生读放大效应。
• 版本兼容： 数据管道存储的事件格式需包含 schema 版本号，确保旧版本回放时能正确解析。