3. 模型服务架构设计：整体架构、请求流程、组件职责

在授信场景中，模型服务架构需要同时满足高并发、低延迟、可解释性和灰度发布等核心要求。本节从整体架构、请求流程和组件职责三个维度展开，帮助理解生产级模型服务的运行机制。

3.1 整体架构分层

授信模型服务通常采用四层架构：接入层、路由层、计算层、存储层。各层职责清晰，通过异步消息与同步RPC混合通信，兼顾实时性与吞吐量。

3.2 请求流程详解

一次完整的授信模型调用请求，从客户端发起至结果返回，经历6个关键阶段。每个阶段都有明确的超时控制和异常处理策略。

3.3 组件职责与交互

各组件在架构中承担独立职责，并通过同步RPC（gRPC/Thrift）和异步消息（Kafka/RabbitMQ）两种方式协作。下面列出核心组件的职责边界。

• API Gateway： 统一入口，负责协议转换（HTTP/gRPC）、请求鉴权、限流降级、请求日志。无状态，支持弹性伸缩。
• Model Router： 维护模型版本注册表，根据路由策略（权重、灰度标签、AB Test）将请求分发到对应Worker。支持流量镜像用于线上验证。
• Model Worker： 模型推理的执行单元。每个Worker进程加载一个模型实例，支持热加载与优雅退出。内部包含特征工程模块、推理引擎、后处理模块。
• Feature Store： 实时特征存储，通常基于Redis或内存网格，提供毫秒级特征查询。支持特征版本管理与回滚。
• Result Store： 结果持久化存储，用于事后分析、报表、模型监控。通常使用Elasticsearch或ClickHouse。
• Monitor & Alert： 横切组件，采集各层指标（延迟、QPS、错误率、模型分数分布），触发告警规则。

3.4 关键设计要点

1. 灰度发布： 新模型版本先切 1% 流量，观察分数分布、拒绝率、逾期率等业务指标，确认无异常后再逐步放量。
2. 超时控制： 每个阶段设置独立超时（如特征查询 50ms、推理 200ms），避免单点故障拖垮整个链路。
3. 可解释性输出： 模型服务需同时返回分数和拒绝原因码（如 SHAP 值、特征贡献度），满足监管合规要求。
4. 降级策略： 当特征存储不可用时，使用离线预计算特征兜底；当模型 Worker 全部异常时，返回规则引擎评分作为降级方案。

3.5 架构对比：单体 vs 微服务