1. 风控网关概述：定位、职责与架构演进
1.1 风控网关在金融科技中的定位
在金融科技体系中，风控网关（Risk Control Gateway）处于业务接入层与风控决策引擎之间的关键枢纽位置。它并非简单的反向代理或API网关，而是承载了实时风险识别、流量过滤、模型服务编排等核心能力的中间层基础设施。
从系统分层视角看，风控网关的定位如下表所示：
| 层级 | 典型组件 | 风控网关职责边界 |
|---|---|---|
| 接入层 | Nginx / Kong / APISIX | 协议转换、限流、鉴权，将请求转发至风控网关 |
| 风控网关层 | Risk Gateway | 特征提取、模型推理、规则预判、结果缓存 |
| 决策引擎层 | Drools / 自研决策流 | 复杂规则组合、策略编排、人工审核 |
| 模型服务层 | TensorFlow Serving / Triton / MLflow | 模型加载、GPU推理、版本管理 |
| 数据存储层 | Redis / HBase / ClickHouse | 特征存储、黑名单、历史行为画像 |
关键认知：风控网关不是“网关+风控”的简单叠加，而是将模型服务（Model Serving）的延迟敏感性与网关的流量管控能力深度融合，形成毫秒级风险决策闭环。
1.2 核心职责
风控网关承担以下六大核心职责，覆盖从请求进入至风险决策返回的全链路：
- 流量接入与协议适配：统一接收HTTP/gRPC/消息队列等异构协议请求，转换为内部风控标准格式。
- 实时特征提取：从请求头、设备指纹、用户上下文、时序行为中提取模型所需的原始特征，支持在线特征计算与缓存。
- 模型推理调度：根据路由策略将特征向量分发至对应的模型服务实例（如XGBoost、DNN、图模型），并聚合多模型结果。
- 规则预判与快速拒绝：在模型推理前执行轻量级规则（如黑名单、频次控制），拦截明显恶意流量，降低模型服务压力。
- 结果缓存与降级：对高频相同请求（如同一用户短时重复操作）缓存风险评分，避免重复计算；在模型服务不可用时提供降级策略。
- 全链路观测与日志：记录每次请求的特征、模型版本、推理耗时、决策结果，支撑离线分析和模型迭代。
工程实践要点：在金融场景中，风控网关的P99延迟通常要求控制在 20ms 以内，其中模型推理占比约60%~70%，特征提取与网络开销占30%~40%。因此，特征预计算、模型轻量化、连接池复用是优化重点。
1.3 整体架构演进
风控网关的架构经历了从单体到分布式、从规则驱动到模型驱动、从同步到异步的演进过程。以下为三个典型阶段的对比：
| 阶段 | 架构特征 | 模型服务方式 | 典型延迟 | 适用场景 |
|---|---|---|---|---|
| V1：单体风控网关 | 规则+模型耦合在同一个进程中，使用本地模型文件 | 进程内加载PMML/ONNX | 50~100ms | 业务量小、模型单一（如信贷审批） |
| V2：分布式模型服务网关 | 网关与模型服务分离，通过RPC调用远程推理集群 | 独立模型服务集群（TF Serving / Triton） | 10~30ms | 中等规模、多模型并存（如支付风控） |
| V3：AI原生风控网关 | 网关内置轻量推理引擎，支持端上模型+云端模型协同 | 边缘推理 + 云端大模型 + 动态路由 | 5~15ms | 高并发、毫秒级实时场景（如交易反欺诈） |
当前业界主流处于V2向V3过渡的阶段。以下为V3 AI原生风控网关的典型架构示意图：
架构演进避坑：从V1直接跳跃到V3时，常见误区是过度设计——在业务模型尚未稳定时引入边缘推理和动态路由，导致运维复杂度剧增。建议先完成V2的模型服务分离与缓存建设，再逐步引入边缘推理能力。
1.4 关键设计原则
基于上述定位与架构演进，风控网关的设计需遵循以下原则：
- 无状态化：网关节点不持有业务状态，所有特征与模型结果通过外部缓存或数据库共享，便于水平扩展。
- 模型服务与网关解耦：模型推理作为独立服务部署，网关通过服务发现与负载均衡调用，支持模型热更新。
- 降级优先于拒绝：当模型服务超时或异常时，网关应返回缓存结果或执行降级规则，而非直接拒绝请求。
- 可观测性内置：每个请求携带全局TraceID，覆盖特征提取、模型推理、规则执行全链路，便于问题定位。
总结：风控网关是金融科技实时风控体系的第一道防线，也是模型服务工程化的核心载体。理解其定位、职责与架构演进，是后续深入学习模型服务编排、特征工程、延迟优化等章节的基础。