模型服务化架构设计：整体架构图、请求入口、特征工程、模型推理、决策输出

实时风控引擎的模型服务化是将训练好的风控模型部署为低延迟、高可用的在线推理服务，并嵌入到业务决策链路中的关键环节。本章从架构全局出发，依次拆解请求入口、特征工程、模型推理与决策输出四个核心阶段，形成完整的服务化闭环。

2.1 整体架构分层

实时风控模型服务化架构采用四层解耦设计，每一层职责清晰、可独立扩缩容，确保端到端延迟控制在 50ms 以内（P99）。

2.2 请求入口：统一网关与协议适配

请求入口是风控服务的第一道防线，负责接收业务方（如交易、信贷、登录）的实时风控请求，完成协议转换、流量控制和初步校验。

• 协议适配：支持 HTTP/HTTPS（JSON）、gRPC（Protobuf）、MQ 异步消息三种接入方式，统一转为内部 RPC 调用。
• 限流熔断：基于令牌桶 + 滑动窗口实现单机限流，配合 Sentinel/Hystrix 做服务熔断，防止突发流量击穿下游。
• 请求校验：校验必填字段（如 userId、deviceId、场景码）、参数格式、签名合法性，拦截无效请求。
• 链路追踪：为每个请求注入 TraceId，贯穿特征、推理、决策全链路，便于问题排查。

2.3 特征工程：实时特征计算与特征中心

特征工程是模型服务化的核心瓶颈。实时风控场景下，特征必须在线计算、低延迟产出，且与离线训练时的特征逻辑严格一致。

2.3.1 特征分类与计算模式

2.3.2 特征中心设计要点

• 特征注册：所有特征在特征中心统一注册，包含特征名、类型、计算逻辑、依赖数据源。
• 特征缓存：对高频访问的静态特征（如设备指纹、IP 归属地）使用本地 LRU 缓存 + Redis 二级缓存。
• 特征对齐：在线特征计算逻辑必须与离线训练脚本一致，通过特征校验工具定期比对。
• 空值处理：特征缺失时采用默认值、均值填充或模型侧处理，避免推理异常。

2.4 模型推理：推理引擎与模型管理

模型推理层负责加载训练好的模型文件，接收特征向量并输出预测分数。推理引擎的选择直接影响延迟和吞吐。

2.4.1 推理引擎选型对比

2.4.2 模型管理关键能力

• 模型版本管理：支持 A/B 测试、灰度发布、一键回滚，模型文件存储在对象存储（S3/MinIO）中。
• 模型热加载：推理服务无重启切换模型版本，通过监听文件变更或 API 触发。
• 模型预热：新模型上线前使用历史请求数据预热，避免冷启动导致首次推理延迟飙升。
• 模型监控：实时监控推理延迟、QPS、内存/显存占用、模型分数分布，触发告警。

2.5 决策输出：后处理与结果回写

模型推理输出的原始分数需要经过决策引擎进行后处理，结合业务规则、阈值、策略编排，最终生成风控决策结果。

2.5.1 决策输出流程

1. 分数校准：将模型原始分数映射到业务可理解的 0-100 分或风险等级（低/中/高）。
2. 规则叠加：在模型分数基础上叠加硬规则（如黑名单命中直接拒绝、白名单直接通过）。
3. 策略编排：支持多模型投票、级联决策、分支策略，通过可视化策略引擎配置。
4. 结果回写：将决策结果（通过/拒绝/人工审核）写入业务数据库、消息队列，并触发后续动作（如短信验证、限权）。
5. 事件上报：将全链路日志（请求、特征、分数、决策）上报到数据湖，用于离线分析和模型迭代。

2.6 全链路延迟预算

实时风控服务端到端延迟预算分配如下，各阶段需严格控制在预算内，确保整体 P99 延迟 ≤ 50ms。