2. 风控网关架构总览：典型分层架构与 Champion Challenger 定位
风控网关作为实时决策的流量入口，其架构设计直接影响策略迭代效率与系统稳定性。本章从分层架构切入，明确 Champion Challenger 在其中的锚点位置。
2.1 典型分层架构：接入层 → 决策层 → 执行层
生产级风控网关通常采用三层解耦架构，每层职责清晰、可独立扩展：
| 层级 | 核心职责 | 典型组件 | 延迟要求 |
|---|---|---|---|
| 接入层 | 协议适配、流量整形、身份认证、请求去重 | Nginx/Kong、API Gateway、限流组件 | < 5ms |
| 决策层 | 规则引擎、模型推理、策略编排、冠军/挑战者实验 | Drools、TensorFlow Serving、策略编排引擎 | < 50ms |
| 执行层 | 结果持久化、异步通知、人工审核、处置动作 | Kafka、Elasticsearch、审批工作流 | < 200ms（异步可放宽） |
架构原则：接入层无状态、决策层可热更新、执行层可回放。Champion Challenger 实验只存在于决策层，不污染上下游。
2.2 分层架构中的请求流转
一次完整的风控请求经过三个层级，每个层级都有明确的输入输出契约：
- 接入层：接收 HTTP/gRPC 请求，完成参数校验、签名校验、流量染色（如按用户ID hash 分流），生成统一上下文对象。
- 决策层：根据上下文加载策略集，执行规则链与模型推理，输出决策结果（通过/拒绝/人工审核）及风险标签。
- 执行层：根据决策结果执行处置动作（写入数据库、发送消息、触发工单），并异步上报监控指标。
关键设计：决策层内部采用“策略编排 + 模型服务”双引擎。Champion Challenger 实验在策略编排阶段注入，不修改模型服务本身。
2.3 Champion Challenger 在架构中的定位
Champion Challenger 并非独立服务，而是嵌入决策层的一个实验框架。其核心定位如下：
- 位置：位于策略编排引擎与规则/模型执行器之间，作为策略路由的决策点。
- 职责：根据实验配置，将流量按比例分配给 Champion（当前最优策略）和 Challenger（候选策略），并记录实验日志。
- 边界：不参与特征计算、不修改模型权重、不直接触发处置动作，仅做策略路由与效果追踪。
2.4 实验流量路由机制
Champion Challenger 在决策层内部通过“流量染色 + 策略路由”实现实验隔离：
- 流量染色：接入层根据用户 ID、设备指纹或随机数生成实验分组标识（Group ID），透传到决策层。
- 策略路由：Champion Challenger 框架根据 Group ID 和实验配置，将请求路由到 Champion 策略链或 Challenger 策略链。
- 日志隔离：实验日志独立写入 Kafka Topic，与生产日志物理隔离，避免影响线上监控。
避坑提示：实验流量必须保证“同一用户始终进入同一实验组”，否则会导致策略效果评估失真。建议使用用户 ID 一致性哈希，而非随机数。
2.5 架构视角下的实验约束
从架构层面看，Champion Challenger 实验必须满足以下约束：
| 约束维度 | 具体要求 | 违反后果 |
|---|---|---|
| 延迟 | 实验路由耗时 < 2ms，不增加决策层 P99 延迟 | 网关超时，影响线上交易 |
| 一致性 | 同一用户在同一实验周期内始终进入同一分组 | 实验数据污染，效果不可信 |
| 可观测 | 实验日志包含完整上下文（特征快照、策略版本、模型版本） | 无法回溯分析实验失败原因 |
| 可回滚 | 实验配置支持秒级切换，Champion 策略可快速全量生效 | Challenger 策略异常时无法快速止血 |