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

4. 模型服务架构演进：从单体模型到微服务，限流熔断的引入位置

模型服务架构的演进路径，直接决定了限流与熔断机制在系统中的部署位置与策略粒度。从早期的单体推理服务到现代的微服务化模型网格，每一阶段的架构特征都对应着不同的流量治理挑战。理解这一演进过程，是正确设计限流熔断方案的前提。

4.1 架构演进三阶段概览

阶段	架构特征	限流熔断引入位置	典型问题
单体模型服务	单进程加载所有模型，共享内存与GPU资源	服务入口（API网关或反向代理层）	资源争抢、单点故障、模型级隔离缺失
垂直拆分模型服务	按模型类型拆分为独立服务（如NLP、CV、推荐）	每个模型服务独立入口 + 网关层	服务间调用链变长、级联失败风险上升
微服务化模型网格	模型推理、预处理、后处理、特征工程拆分为独立微服务	每个微服务端点 + 服务间调用链路	调用拓扑复杂、熔断策略需逐跳配置

  关键认知：限流熔断的引入位置，本质上是随着架构拆分粒度从"入口集中"向"链路分散"迁移。单体阶段只需守大门；微服务阶段需要在每一扇门后都部署哨兵。

4.2 单体模型服务阶段

在早期或小规模部署场景中，所有模型推理逻辑打包在同一个进程中，通过不同的路由路径（如 /v1/model/bert、/v1/model/resnet）对外暴露。此时限流熔断的引入位置非常单一：服务入口。

限流位置：Nginx / Envoy 反向代理层，基于 IP、Token、URL 路径做全局 QPS 限制。
熔断位置：应用层健康检查 + 进程级看门狗，检测到模型加载失败或 OOM 时直接拒绝新请求。
缺点：无法区分模型优先级；一个模型流量突增可能拖垮所有模型。

# 单体模型服务入口限流示例（基于 Flask + 令牌桶）
from flask import Flask, request, jsonify
from time import time

app = Flask(__name__)
tokens = 100  # 全局令牌桶容量
last_refill = time()

def rate_limit():
    global tokens, last_refill
    now = time()
    tokens = min(100, tokens + (now - last_refill) * 10)
    last_refill = now
    if tokens < 1:
        return False
    tokens -= 1
    return True

@app.route('/v1/model/bert', methods=['POST'])
def bert_infer():
    if not rate_limit():
        return jsonify({"error": "rate limit exceeded"}), 429
    # 模型推理逻辑...
    return jsonify({"result": "bert output"})

避坑提示：单体阶段最常见的错误是使用全局限流而非模型级限流。当 BERT 模型被高频调用时，ResNet 模型的请求也会被无辜限流。务必在路由层按 URL 前缀分配独立令牌桶。

4.3 垂直拆分模型服务阶段

随着模型数量增长，团队开始按业务域或模型类型将服务拆分为独立进程。每个模型服务拥有独立的 GPU 资源、独立的部署单元。此时限流熔断的引入位置扩展为两层：

网关层：统一入口限流，防止 DDoS 或客户端异常重试。
服务层：每个模型服务独立配置限流阈值与熔断规则，实现模型级隔离。

这一阶段引入了服务间调用（如 NLP 服务调用公共分词服务），熔断策略需要覆盖 RPC 调用链路。

# 垂直拆分后，每个模型服务独立限流（基于 FastAPI + Redis 滑动窗口）
from fastapi import FastAPI, HTTPException
from redis import Redis
import time

app = FastAPI()
redis = Redis(host='redis', port=6379)

def sliding_window_rate_limit(key: str, max_requests: int, window: int) -> bool:
    now = int(time.time())
    window_start = now - window
    redis.zremrangebyscore(key, 0, window_start)
    current_count = redis.zcard(key)
    if current_count >= max_requests:
        return False
    redis.zadd(key, {now: now})
    redis.expire(key, window)
    return True

@app.post('/v1/ner/infer')
async def ner_infer():
    if not sliding_window_rate_limit("ner:user:ip", 100, 60):
        raise HTTPException(status_code=429, detail="Too Many Requests")
    # NER 模型推理...
    return {"entities": []}

4.4 微服务化模型网格阶段

在大型 AI 平台中，模型推理被进一步拆解为多个微服务：请求预处理（文本清洗、图像缩放）、特征工程（Embedding 查询、特征拼接）、模型推理（多模型 Ensemble）、后处理（结果排序、阈值过滤）。每个微服务独立部署、独立扩缩容。

限流熔断的引入位置变为全链路分布式：

层级	限流熔断策略	典型实现
入口网关	全局 QPS + 客户端级限流	Kong / APISIX 插件
预处理服务	基于请求体大小的限流 + 熔断	Resilience4j / Sentinel
特征服务	基于 Embedding 维度的限流 + 缓存降级	Hystrix 线程池隔离
模型推理服务	基于 GPU 显存利用率的动态限流 + 熔断	自定义指标 + K8s HPA
后处理服务	基于结果大小的限流 + 快速失败	gRPC 拦截器 + 超时熔断

实战建议：在微服务模型网格中，推荐使用 Service Mesh（如 Istio + Envoy）实现无侵入的限流熔断。通过 EnvoyFilter 配置每个服务的连接池大小、请求超时和熔断阈值，避免在业务代码中重复实现流量治理逻辑。

4.5 架构演进与限流熔断引入位置对照图

下图展示了从单体到微服务的演进过程中，限流熔断组件（以红色标记）的部署位置变化：

4.6 引入位置选择的决策原则

在实际项目中，限流熔断的引入位置并非越分散越好。以下原则可帮助团队做出合理决策：

入口层必做：无论架构如何演进，API 网关层必须配置全局限流，防止恶意流量穿透到后端服务。
有状态服务优先：模型推理服务通常持有 GPU 显存或大模型权重，这类有状态服务必须配置熔断，防止资源耗尽导致雪崩。
调用链关键路径：对延迟敏感的关键路径（如实时推荐、在线翻译）上的每个微服务都应配置熔断，避免单点故障扩散。
非关键路径可降级：对于日志、监控、特征缓存等非关键服务，可采用降级策略而非熔断，减少运维复杂度。

  架构师视角：限流熔断的引入位置本质上是信任边界的划分。在单体阶段，信任边界在进程边界；在微服务阶段，信任边界在每一次 RPC 调用之间。每跨越一次信任边界，就需要重新评估是否需要部署限流熔断。

4.7 本章小结

单体模型服务：限流熔断集中在入口网关，实现简单但隔离性差。
垂直拆分模型服务：网关层 + 服务层双层部署，实现模型级隔离。
微服务化模型网格：全链路分布式部署，每个微服务端点及服务间调用均需配置。
引入位置的选择应遵循入口层必做、有状态服务优先、关键路径全覆盖、非关键路径可降级的原则。