📚 课程目录第3章模型服务化架构演进

3. 模型服务化架构演进：从单体模型到微服务API网关的流量控制挑战

模型从离线训练到在线推理的部署过程，本质上是软件架构不断解耦、服务粒度持续细化的演进史。每一次架构升级都带来了新的流量控制难题，尤其是在模型风险管理（MRM）的合规视角下，流量控制不仅是性能问题，更是模型行为可观测、可审计、可熔断的治理问题。

早期模型服务通常以单体应用（Monolithic）形式部署，模型逻辑、特征工程、预处理、后处理全部打包在同一个进程中，通过单一 HTTP 端点对外暴露。

  典型特征：
  所有请求命中同一个进程，无内部路由
流量控制依赖外部负载均衡器（如 Nginx）的简单限流
模型版本更新需全量重启，蓝绿部署是最高级的流量切换手段

MRM 视角的隐患：单体架构下，模型风险无法独立隔离。若某个模型版本出现推理异常（如输出 NaN 或置信度崩溃），会污染整个服务的响应质量。流量控制只能做全局“开/关”，无法按模型、按版本、按用户维度做精细化熔断。

随着模型数量增多，单体架构的耦合问题日益突出。业界开始将模型推理拆分为独立的微服务，每个模型拥有独立的部署单元、独立的扩缩容策略和独立的流量入口。

微服务化虽然解决了隔离性问题，但引入了新的流量控制挑战：

为了解决微服务化带来的碎片化问题，API 网关（API Gateway）作为统一的流量入口被引入模型服务架构中。网关承担了路由、限流、认证、监控、熔断等横切关注点。

在模型风险管理场景下，API 网关的流量控制面临以下五个关键挑战：

模型级限流粒度：网关需要识别请求中的模型 ID、版本号、甚至特征维度，实现比服务级更细的限流。例如，限制某个高风险模型版本的 QPS 不超过 100，而其他版本可以到 1000。
动态模型路由：模型灰度发布时，网关需要根据流量比例（如 5% 流量到新版本 v2.1）动态分发请求，同时保证同一用户的请求始终路由到同一版本（会话保持）。
推理超时与熔断：模型推理时间可能因输入数据量级差异而波动（如 NLP 模型处理长文本）。网关需要设置合理的超时阈值，并在超时率达到告警线时自动熔断，防止慢请求堆积导致级联故障。
审计日志与可观测性：MRM 要求所有模型调用可追溯。网关必须在流量控制的同时，记录每个请求的模型 ID、版本、输入/输出摘要、响应时间、限流/熔断事件，输出到审计系统。
多租户隔离：不同业务线（如信贷风控、营销推荐）共享同一套模型服务集群时，网关需要按租户维度分配配额，防止某个租户的突发流量挤占其他租户的模型资源。

实践建议：在网关层引入“模型路由表”概念——将模型名称、版本、部署实例列表、限流阈值、熔断策略等元数据集中管理。路由表支持热更新，流量控制策略变更无需重启网关。推荐使用 etcd 或 Consul 作为路由表的配置中心。