4. Serving系统架构：分层设计与交互流程

可疑交易推理链路对延迟、吞吐与可解释性要求极高。Serving系统采用四层解耦架构——接入层、编排层、推理层、存储层——每一层职责单一、可独立扩缩容，并通过标准协议交互。这种分层设计使得模型更新、特征扩展、规则调整互不干扰，是生产级推理链路的基石。

4.1 四层架构总览

下图展示了Serving系统的完整分层结构及各层之间的核心交互关系：

4.2 各层职责详解

4.2.1 接入层 (Access Layer)

接入层是系统的流量入口，负责将外部请求转化为内部标准格式，并完成安全与流量控制。

• 协议适配：支持 HTTP/REST、gRPC、WebSocket 等多种协议，统一转换为内部 RPC 调用。
• 鉴权与限流：基于 API Key、OAuth2 或 JWT 进行身份校验；使用令牌桶或滑动窗口算法做限流。
• 请求校验：校验必填字段、数据格式、字段范围，拒绝无效请求，避免脏数据进入下游。
• 日志与监控：记录请求入口时间、来源 IP、请求体摘要，供审计和延迟分析使用。

4.2.2 编排层 (Orchestration Layer)

编排层是整个推理链路的大脑，负责将单个请求转化为一个可执行的推理 DAG（有向无环图）。

• DAG 解析：根据请求中的交易类型、渠道、风险等级，动态加载对应的推理链路配置。
• 节点调度：按拓扑顺序依次调用推理层各节点（特征提取→规则判断→模型打分→后处理）。
• 上下文管理：维护请求级别的上下文对象，存储中间特征、中间结果、异常信息，供后续节点使用。
• 超时与重试：为每个推理节点设置独立超时时间；对可重试的失败（如网络抖动）执行指数退避重试。
• 结果聚合：收集所有节点的输出，组装成统一的响应结构返回给接入层。

4.2.3 推理层 (Inference Layer)

推理层是计算核心，承载模型加载、特征工程、规则执行与模型推理等计算密集型任务。

• 模型加载与管理：支持热加载/卸载模型，多版本管理（金丝雀发布、A/B 测试）。
• 特征计算：从原始交易数据中提取衍生特征（如交易频次、金额统计、设备指纹）。
• 规则引擎：执行专家规则（如“单笔金额 > 50 万且交易时间在凌晨”），支持规则热更新。
• 模型推理：调用机器学习模型（XGBoost、DNN、GraphSAGE 等）输出风险分数或分类标签。
• 结果后处理：对模型输出做校准、阈值判定、置信度过滤，生成最终决策建议。

4.2.4 存储层 (Storage Layer)

存储层为上层提供数据持久化与缓存能力，是推理链路的数据底座。

• 特征存储：存放离线预计算特征（如用户画像、历史行为统计），支持在线实时查询。
• 模型仓库：存储模型文件（PMML、ONNX、SavedModel）及元数据（版本、创建时间、评估指标）。
• 结果持久化：将每次推理请求的输入、中间结果、最终决策写入数据库，用于事后回溯与模型迭代。
• 缓存：对高频查询的特征（如黑名单、白名单）使用 Redis 或 Memcached 加速。
• 审计日志：记录所有数据变更操作，满足合规与监管要求。

4.3 层间交互流程

一次完整的可疑交易推理请求，在各层之间的典型交互时序如下：

4.4 分层架构的优势

四层架构在金融风控生产环境中带来的具体收益：

• 独立扩缩容：推理层是计算瓶颈，可单独增加 GPU/CPU 节点；接入层无状态，可快速水平扩展应对流量洪峰。
• 故障隔离：存储层宕机不影响推理层已加载的模型；编排层超时机制可快速熔断下游故障。
• 技术栈解耦：接入层用 Java/Go，推理层用 Python/C++，存储层用 Redis/MySQL，各层选择最适合的语言与框架。
• 可观测性：每层暴露独立的 metrics（QPS、P99 延迟、错误率），通过 Prometheus + Grafana 快速定位瓶颈。
• 灰度发布：推理层可同时部署 v1 和 v2 模型，编排层通过流量染色将部分请求路由到新版本，实现 A/B 测试。

4.5 典型部署拓扑

下图展示了一个生产环境中的物理部署拓扑，体现各层如何映射到实际服务实例：

4.6 层间通信协议选型