3. Serving系统架构设计：请求入口层、路由层、推理引擎层、模型仓库层、监控与日志层

低延迟因子评分系统的核心在于分层解耦与流水线并行。每一层承担明确的职责，并通过轻量级协议（如 gRPC、共享内存）进行通信。本章将详细拆解 Serving 系统的五层架构，并给出每层的设计要点与选型建议。

3.1 请求入口层（Ingress Layer）

请求入口层是系统的第一道防线，负责接收外部客户端的推理请求，并执行基础的预处理与流量控制。

• 协议适配： 支持 HTTP/REST、gRPC、WebSocket 等多种协议，并将外部协议统一转换为内部 RPC 调用。
• 身份认证与鉴权： 基于 API Key、JWT 或 mTLS 进行请求校验，拒绝非法请求。
• 限流与熔断： 使用令牌桶（Token Bucket）或漏桶算法，防止突发流量冲垮下游服务。当错误率超过阈值时，自动熔断。
• 请求校验与预处理： 检查请求体格式（如 JSON Schema）、字段完整性，并进行简单的数据清洗（如去除空值、截断超长文本）。

3.2 路由层（Routing Layer）

路由层根据请求的特征（如模型版本、业务线、用户 ID 哈希）将请求分发到正确的推理引擎实例。这是实现灰度发布、A/B 测试和多模型管理的核心。

• 模型版本路由： 根据请求头中的 model_version 或 canary 标签，将流量按比例（如 90% v1, 10% v2）分发。
• 一致性哈希路由： 对用户 ID 或请求 ID 进行哈希，确保同一用户的请求始终路由到同一推理实例，以利用本地缓存。
• 动态权重调整： 实时读取监控数据，自动将流量从高延迟或高错误率的实例迁移到健康实例。
• 请求复制（Shadow Traffic）： 将生产流量复制一份发送到新模型，用于在线验证而不影响线上结果。

3.3 推理引擎层（Inference Engine Layer）

推理引擎层是执行模型前向计算的核心。它负责加载模型、管理 GPU/CPU 资源、执行批处理（Batching）并返回结果。

• 模型加载与热更新： 支持动态加载/卸载模型，无需重启进程。使用共享内存或 RDMA 加速模型权重传输。
• 动态批处理（Dynamic Batching）： 将多个请求合并为一个批次，提高 GPU 利用率。需设置最大延迟容忍度（如 5ms），避免单个请求等待过久。
• 计算加速： 使用 TensorRT、ONNX Runtime、OpenVINO 等推理优化引擎，对模型进行图优化和量化（FP16/INT8）。
• 资源隔离： 通过 MPS（Multi-Process Service）或 MIG（Multi-Instance GPU）实现 GPU 显存和算力的隔离，防止模型间互相干扰。

3.4 模型仓库层（Model Repository Layer）

模型仓库层负责模型的版本管理、存储、分发与生命周期管理。它确保推理引擎能够快速、一致地获取到正确的模型文件。

• 版本化存储： 每个模型包含多个版本，每个版本对应一组权重文件、配置文件和预处理逻辑。使用语义化版本号（如 1.2.3）。
• 分布式存储后端： 支持 S3、GCS、HDFS 或本地 NAS。对于低延迟场景，推荐使用本地 SSD 缓存 + 远端对象存储的二级缓存架构。
• 模型拉取策略： 支持懒加载（Lazy Loading，首次推理时拉取）和预加载（Eager Loading，服务启动时拉取）。低延迟场景推荐预加载。
• 模型签名与校验： 使用 SHA256 校验模型完整性，防止文件损坏或篡改。

# 模型仓库目录结构示例
/models/
├── fraud_detection/
│   ├── 1.0.0/
│   │   ├── model.onnx
│   │   ├── config.json
│   │   └── preprocessor.py
│   ├── 1.1.0/
│   │   ├── model.onnx
│   │   ├── config.json
│   │   └── preprocessor.py
│   └── latest -> 1.1.0
└── credit_scoring/
    └── 2.0.0/
        └── model.pt

3.5 监控与日志层（Monitoring & Logging Layer）

监控与日志层是 Serving 系统的“眼睛”和“记忆”。没有可观测性，就无法定位延迟抖动和错误根因。

• 指标采集（Metrics）： 采集三大黄金信号：延迟（Latency）、流量（Traffic）、错误（Errors）。使用 Prometheus 客户端暴露 /metrics 端点。
• 分布式追踪（Tracing）： 为每个请求生成 Trace ID，贯穿入口层到推理引擎层。使用 OpenTelemetry 或 Jaeger 追踪各层耗时。
• 结构化日志（Logging）： 输出 JSON 格式的日志，包含 request_id、model_version、latency_ms、gpu_util 等关键字段，便于日志分析系统（如 ELK）检索。
• 告警与自愈： 当 P99 延迟超过阈值（如 50ms）或错误率超过 1% 时，触发告警并自动执行降级策略（如切换到备用模型）。