3. Serving架构总览：五层分层设计
低延迟风控模型在线Serving的核心挑战在于：在毫秒级时间内完成请求接入、特征加工、模型推理、结果判定与回传。为应对这一挑战，业界普遍采用五层分层架构，将不同职责的模块解耦，实现独立扩缩容与性能调优。
3.1 五层架构总览
下图展示了风控Serving系统的完整请求生命周期，从客户端发起请求到最终结果回传，依次经过五个层次：
3.2 各层职责与关键技术
下表详细对比了五层架构中每一层的核心职责、常用技术栈与延迟敏感度：
| 层次 | 核心职责 | 常用技术栈 | 延迟敏感度 | 扩缩容维度 |
|---|---|---|---|---|
| 请求入口层 | 协议转换、限流、鉴权、路由分发 | Nginx/Kong/Envoy + gRPC | 极高 | 按QPS |
| 预处理层 | 参数校验、特征提取、特征工程、黑白名单 | Python/Java + Redis + Feature Store | 高 | 按特征维度 |
| 模型推理层 | 模型加载、Batch推理、版本管理、热更新 | TensorRT/ONNX Runtime/Triton | 最高 | 按模型算力 |
| 后处理层 | 分数校准、规则叠加、决策融合、阈值判定 | Python/Go + 规则引擎 | 中 | 按规则数量 |
| 结果回传层 | 结果封装、异步回传、日志审计、监控打点 | Kafka/Redis + Prometheus | 低 | 按吞吐量 |
3.3 请求入口层：第一道防线
请求入口层是系统的第一道防线，负责接收外部请求并进行初步处理。该层通常部署在API Gateway或负载均衡器上，主要功能包括：
- 协议适配：将外部HTTP/HTTPS请求转换为内部gRPC或Thrift协议，统一内部通信格式。
- 限流熔断：基于令牌桶或漏桶算法，对突发流量进行削峰填谷；当下游出现故障时，快速熔断防止级联雪崩。
- 鉴权校验：验证请求的API Key、Token或签名，拦截非法请求。
- 路由分发：根据请求中的业务类型（如登录风控、交易风控），将请求路由到对应的预处理服务。
3.4 预处理层：特征工程的核心战场
预处理层是风控Serving中计算密度最高的层次之一，负责将原始请求数据转换为模型可用的特征向量。该层通常包含以下步骤：
- 参数校验与清洗：检查必填字段是否存在，对异常值、空值进行填充或剔除。
- 黑白名单匹配：基于设备指纹、IP、手机号等维度，快速命中黑名单或白名单，直接返回拒绝或放行。
- 特征提取：从请求中提取基础特征（如金额、时间、地理位置），并从外部存储（Redis、HBase）获取画像特征。
- 特征工程：执行离散化、归一化、交叉特征、时序特征等变换，生成最终的特征向量。
预处理层的性能优化重点在于特征缓存与并行计算。对于频繁使用的画像特征，使用本地缓存或Redis缓存可减少90%以上的外部存储访问延迟。
3.5 模型推理层：延迟瓶颈所在
模型推理层是整个Serving系统的延迟瓶颈，通常占总延迟的40%-60%。该层负责加载训练好的风控模型（如XGBoost、DNN、Graph Neural Network），并对预处理后的特征向量进行推理计算。
模型推理层的关键设计要点：
- 模型版本管理：支持多版本模型同时在线，通过灰度发布逐步切换流量，避免全量上线带来的风险。
- Batch推理优化：将多个请求的特征向量合并为一个Batch，利用GPU或SIMD指令集并行计算，显著提升吞吐量。
- 热更新机制：在不重启服务的情况下，动态加载新模型版本，保证Serving的连续性。
- 推理加速：使用TensorRT、ONNX Runtime或TVM对模型进行编译优化，减少推理延迟。
3.6 后处理层：决策融合与规则叠加
后处理层负责对模型推理结果进行二次加工，将原始模型分数转化为最终的风控决策。该层通常包含以下逻辑：
- 分数校准：将模型输出的原始分数映射到统一的置信度区间（如0-1000），便于跨模型比较。
- 规则叠加：在模型分数基础上叠加业务规则（如“金额大于10000且模型分数低于阈值则拒绝”），实现模型与规则的互补。
- 决策融合：当存在多个模型（如欺诈模型、信用模型、反洗钱模型）时，通过加权投票或Stacking策略融合多个模型的输出。
- 阈值判定：根据业务风险偏好，设定拒绝、人工审核、放行等不同阈值，输出最终决策。
后处理层虽然计算量不大，但规则逻辑的复杂度可能成为维护难点。建议将规则配置化、可视化，避免硬编码。
3.7 结果回传层：闭环与可观测性
结果回传层是Serving流程的最后一公里，负责将决策结果返回给调用方，并完成后续的审计与监控工作。该层的主要职责包括：
| 功能模块 | 说明 | 技术实现 |
|---|---|---|
| 结果封装 | 将决策结果、分数、原因码等字段组装为统一格式的响应体 | Protobuf / JSON |
| 异步回传 | 将决策结果异步写入消息队列，供下游风控分析、离线训练使用 | Kafka / Pulsar |
| 日志审计 | 记录完整的请求-响应日志，满足合规与溯源需求 | Elasticsearch / ClickHouse |
| 监控打点 | 统计延迟分布、QPS、错误率、模型分数分布等指标 | Prometheus + Grafana |
3.8 分层架构的扩展性设计
五层架构不仅解决了低延迟问题，还为系统的水平扩展提供了清晰边界。下图展示了各层独立扩缩容的典型场景：
通过这种分层设计，团队可以针对不同层次的瓶颈进行精准扩缩容：当模型复杂度增加时，只需扩容模型推理层；当业务规则增多时，只需扩容后处理层。这种灵活性是单体架构无法比拟的。