3. 实时推理引擎架构：请求入口、特征计算、模型加载、打分输出、日志落盘
实时推理引擎是风控 Model Serving 的核心执行单元，负责将上游传入的实时请求转化为最终的风险分数。本章从架构视角拆解推理引擎的五大关键环节：请求入口、特征计算、模型加载、打分输出、日志落盘。每个环节的设计直接决定系统的吞吐、延迟与可观测性。
3.1 整体架构总览
推理引擎采用流水线（Pipeline）模式，将请求处理拆解为串行与并行的混合阶段。下图展示了标准实时推理引擎的内部模块与数据流向：
3.2 请求入口：协议适配与流量治理
请求入口是推理引擎的第一道关卡，负责接收外部系统的实时调用。常见的接入方式包括：
| 协议/方式 | 适用场景 | 延迟 | 吞吐 |
|---|---|---|---|
| HTTP/REST | 外部 API 调用、调试 | 中等（~5ms） | 中等 |
| gRPC | 内部微服务间调用 | 低（~1ms） | 高 |
| Kafka / Pulsar | 异步事件流、高吞吐场景 | 低（~2ms） | 极高 |
工程建议：生产环境推荐gRPC + Kafka 双通道。gRPC 用于同步打分请求，Kafka 用于异步批量处理与离线重放。入口层需实现限流、熔断、鉴权等流量治理能力，防止突发流量打垮引擎。
3.3 特征计算：实时与离线的融合
特征计算是推理引擎中计算密度最高的环节。一个典型的风控请求需要聚合数十到数百个特征，包括：
- 实时特征：从请求参数中直接提取（如 IP、设备 ID、金额）。
- 离线特征：从外部存储（Redis、HBase、MySQL）中获取用户画像、历史行为统计。
- 衍生特征：基于实时与离线数据组合计算（如近 1 小时交易次数、设备关联风险分）。
特征计算阶段通常采用特征工程管道（Feature Pipeline），按依赖关系分步执行：
3.4 模型加载：版本管理与热更新
模型加载模块负责将训练好的模型文件加载到内存中，并提供高效的推理接口。核心设计要点包括：
- 模型仓库：统一存储模型文件（如 ONNX、PMML、Pickle），支持按版本号、时间戳检索。
- 热加载机制：模型更新时无需重启引擎，通过监听文件变更或 API 触发重新加载。
- 多版本共存：支持 A/B 测试场景，不同流量路由到不同模型版本。
- 资源隔离：每个模型实例独占内存与计算资源，避免相互干扰。
性能指标：模型加载时间应控制在 100ms 以内（含模型反序列化与预热）。生产环境建议使用共享内存（mmap）加载大模型，减少内存拷贝。
3.5 打分输出：结果封装与决策分发
打分输出阶段将模型推理结果封装为统一格式，并分发到下游系统。输出内容通常包含：
| 字段 | 类型 | 说明 |
|---|---|---|
| score | float | 风险分数（0~1） |
| decision | string | 决策标签（pass / review / reject） |
| confidence | float | 模型置信度 |
| model_version | string | 使用的模型版本 |
| features_hash | string | 特征指纹，用于离线调试 |
输出结果通过回调（Callback）或消息队列发送给决策引擎、风控中台、监控系统等下游模块。
3.6 日志落盘：异步非阻塞的可观测性基石
日志落盘是推理引擎的最后一道工序，记录每次请求的完整处理链路。设计原则：
- 异步写入：使用独立线程池或 RingBuffer 批量写入磁盘，不阻塞主推理链路。
- 结构化日志：采用 JSON 格式，包含请求 ID、时间戳、特征快照、模型版本、分数、耗时等字段。
- 日志分级：区分全量日志（用于离线分析）与采样日志（用于实时监控）。
- 存储策略：按天分片，支持自动压缩与归档，保留周期通常为 30~90 天。
避坑提醒：日志落盘切忌使用同步 I/O 或阻塞队列。推荐使用 LMAX Disruptor 或 Kafka Producer 异步发送，确保日志写入延迟 < 1ms，不影响主链路 P99 延迟。
3.7 各环节延迟预算参考
以下为典型实时风控场景下，推理引擎各环节的延迟预算分配：
| 环节 | 预算（ms） | 占比 |
|---|---|---|
| 请求入口（协议解析 + 鉴权） | 2 | 10% |
| 特征计算（实时 + 离线） | 8 | 40% |
| 模型加载与推理 | 6 | 30% |
| 打分输出与回调 | 2 | 10% |
| 日志落盘（异步） | 2 | 10% |
| 总预算 | 20 | 100% |
实际部署时需根据业务场景调整预算分配。例如，特征计算密集的场景可适当增加特征环节预算，压缩日志落盘开销。