前几篇我们把网关做成"动态路由 + 动态实例 + 统一鉴权"的坚固入口。但还有一类风险拦不住：**流量洪峰**。大模型推理是昂贵的 GPU 算力，一个失控的脚本、一次热点事件、或一个没限速的租户，就能把整池 GPU 打满，导致所有用户请求排队超时。更糟的是，下游超时又会拖垮网关线程，形成雪崩。

本篇给网关装"保险丝"——**Sentinel 与 Gateway 整合，在网关层做限流 + 熔断**，把异常流量挡在最前面，保护昂贵的大模型算力。而且限流规则、熔断阈值全部交给 **Nacos 配置治理**，可热更新、可分级。

1. 为什么要给大模型接口限流熔断
2. Sentinel 核心概念（资源/规则/插槽）
3. Sentinel 与 Gateway 整合原理
4. 实战：网关接入 Sentinel 限流
5. 实战：基于 Nacos 的动态限流规则
6. 熔断降级保护下游推理
7. 最佳实践与踩坑点
8. 本篇小结

1. 为什么要给大模型接口限流熔断

大模型接口和普通的 CRUD 接口有本质区别，限流熔断的必要性更高：

• **算力极贵且稀缺**：一块 A100 同时只能跑有限并发，超额请求只能排队，延迟飙升；
• **单请求耗时长**：一个 32K 上下文的生成可能要 20 秒，网关连接被长期占用；
• **易雪崩**：下游慢 -> 网关连接池耗尽 -> 上游全堵 -> 整个网关不可用；
• **需按租户/模型额度隔离**：不能让一个大租户把别人的额度吃完。

没有防护时，一次异常调用就能让所有用户"集体超时"。限流（Rate Limit）控制"进来多少"，熔断（Circuit Break）控制"下游不行就快速失败"，二者配合，才能保证大模型服务的可用性基线。

手段	解决什么	大模型场景价值
---	---	---
限流	控制并发/QPS 上限	防止 GPU 被瞬时报废式打满
熔断	下游异常时快速失败	防止慢调用拖垮网关连接池
隔离	不同租户/模型资源隔离	防止单租户挤占全局额度
降级	异常时返回兜底	高峰期保核心、牺牲边缘

2. Sentinel 核心概念（资源/规则/插槽）

Sentinel 的三个基石：

• **资源（Resource）**：被保护的逻辑单元，可以是一个 URL、一个方法、一段代码。Gateway 场景下，每条路由、每个 API 分组都是资源。
• **规则（Rule）**：作用于资源的控制策略，如 `FlowRule`（限流）、`DegradeRule`（熔断）、`AuthorityRule`（授权）。
• **插槽链（Slot Chain）**：Sentinel 把每个资源访问串成一条过滤器链，依次做统计、限流、熔断、降级等。

// 资源用 SphU.entry 包裹，超规则抛 BlockException
try (Entry entry = SphU.entry("llm-openai-chat")) {
    // 被保护的逻辑：转发到大模型服务
} catch (BlockException e) {
    // 被限流/熔断，返回 429 或降级响应
}
 

Gateway 整合后，你**几乎不用手写 `SphU.entry`**——`SentinelGatewayFilter` + `SentinelGatewayBlockExceptionHandler` 会自动把每个路由/API 分组包成资源，并在触发规则时返回统一响应。

3. Sentinel 与 Gateway 整合原理

Spring Cloud Alibaba Sentinel 为 Gateway 提供了两个核心组件：

1. `SentinelGatewayFilter`：作为 Gateway 的 `GlobalFilter`，在请求匹配到路由后，按"API 分组 -> 资源"维度进入 Sentinel 插槽链统计与限流；
2. `SentinelGatewayBlockExceptionHandler`：捕获 `BlockException`，返回自定义限流/熔断响应（默认 429）。

整合时有两个关键抽象：

• **网关流控规则 `GatewayFlowRule`**：针对"路由 ID"或"API 分组"配置限流，支持**针对请求属性（如某 Header、某参数）做精确限流**——这正好用来做"按租户限流"。
• **API 分组 `ApiDefinition`**：把多个路由归为一组（如"所有 chat 接口"），一组一个规则统一管理。

// 针对路由 llm-openai 配置 QPS=20 的限流
GatewayFlowRule rule = new GatewayFlowRule("llm-openai")
        .setCount(20)                 // 阈值
        .setIntervalSec(1)            // 统计窗口 1 秒 -> QPS=20
        .setBurst(5);                 // 突发允许 5
GatewayRuleManager.loadRules(List.of(rule));
 

针对请求参数限流（按租户维度）：

GatewayFlowRule tenantRule = new GatewayFlowRule("llm-openai")
        .setCount(5)
        .setIntervalSec(1)
        .setResourceMode(SentinelGatewayConstants.RESOURCE_MODE_ROUTE_ID)
        // 按 X-Tenant-Id 这个 Header 做细粒度限流（每租户 5 QPS）
        .setParamItem(new GatewayParamFlowItem()
            .setParseStrategy(SentinelGatewayConstants.PARAM_PARSE_STRATEGY_HEADER)
            .setFieldName("X-Tenant-Id"));
 

4. 实战：网关接入 Sentinel 限流

**pom.xml 依赖**：

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-alibaba-sentinel-gateway</artifactId>
</dependency>
<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-datasource-nacos</artifactId>
</dependency>
 

**application.yml 配置**：

spring:
  cloud:
    sentinel:
      transport:
        dashboard: 127.0.0.1:8080      # Sentinel 控制台（可选，看监控）
      scg:                             # spring-cloud-gateway 整合开关
        filter:
          enabled: true
      datasource:
        flow:
          nacos:
            server-addr: 127.0.0.1:8848
            namespace: llm-prod
            data-id: gateway-sentinel-flow
            group-id: SENTINEL_GROUP
            rule-type: flow            # 限流规则
        degrade:
          nacos:
            server-addr: 127.0.0.1:8848
            data-id: gateway-sentinel-degrade
            group-id: SENTINEL_GROUP
            rule-type: degrade         # 熔断规则
 

**自定义限流响应**（返回中文 JSON 而非默认 429 文本）：

@Configuration
public class SentinelGatewayConfig {
    @PostConstruct
    public void init() {
        // 统一 Block 异常处理
        SentinelGatewayBlockExceptionHandler handler = new SentinelGatewayBlockExceptionHandler(
            viewResolvers, serverCodecConfigurer);
        // 也可自定义 GatewayCallbackManager 的 blockHandler
        GatewayCallbackManager.setBlockHandler((exchange, t) -> {
            ServerHttpResponse resp = exchange.getResponse();
            resp.setStatusCode(HttpStatus.TOO_MANY_REQUESTS);
            resp.getHeaders().add("Content-Type", "application/json");
            String body = "{\"code\":429,\"msg\":\"请求过于频繁，请稍后重试\"}";
            DataBuffer buf = resp.bufferFactory().wrap(body.getBytes(StandardCharsets.UTF_8));
            return resp.writeWith(Mono.just(buf));
        });
    }
}
 

5. 实战：基于 Nacos 的动态限流规则

这正是"配合 Nacos 配置治理"的核心：限流规则不再写死在代码，而是放在 Nacos 的 `dataId=gateway-sentinel-flow`，改 Nacos 即全网关生效。

**Nacos 中 `gateway-sentinel-flow` 内容（JSON）**：

[
  {
    "resource": "llm-openai",
    "count": 20,
    "intervalSec": 1,
    "burst": 5,
    "controlBehavior": 0,
    "grade": 1
  },
  {
    "resource": "llm-vllm",
    "count": 8,
    "intervalSec": 1,
    "paramItem": {
      "parseStrategy": 2,
      "fieldName": "X-Tenant-Id"
    }
  }
]
 

这样：

• `llm-openai` 整体 QPS 限制 20，应对外部供应商按调用次数计费；
• `llm-vllm` 按 `X-Tenant-Id` 做**每租户 8 QPS** 的精细限流，防止某租户独占本地 GPU。

当业务需要临时调高阈值（如大促），只改 Nacos 的 `count`，`sentinel-datasource-nacos` 监听变更、自动 `loadRules`，**无需重启网关**。结合第 08 篇，网关在鉴权阶段已把 `X-Tenant-Id` 写入 Header，这里才能按租户限流——两篇能力串联。

6. 熔断降级保护下游推理

限流防"入口过载"，熔断防"下游拖死"。当下游大模型服务 RT 飙高、错误率上升，继续转发只会堆积连接。Sentinel 的 `DegradeRule` 可基于 RT / 异常比例 / 异常数触发熔断，熔断期间请求直接快速失败。

**Nacos 中 `gateway-sentinel-degrade` 内容**：

[
  {
    "resource": "llm-openai",
    "grade": 0,
    "count": 2000,
    "timeWindow": 10,
    "statIntervalMs": 1000,
    "minRequestAmount": 5,
    "slowRatioThreshold": 0.5
  }
]
 

含义：对 `llm-openai` 资源，若 1 秒内请求数 >= 5 且慢调用（RT > 2000ms）比例超过 50%，则**熔断 10 秒**，期间请求直接失败（返回降级响应），给下游推理服务喘息空间。

// 降级响应：返回兜底内容而非一直等待
GatewayCallbackManager.setBlockHandler((exchange, t) -> {
    if (t instanceof DegradeException) {
        ServerHttpResponse resp = exchange.getResponse();
        resp.setStatusCode(HttpStatus.SERVICE_UNAVAILABLE);
        String body = "{\"code\":503,\"msg\":\"大模型服务暂不可用，请稍后重试\"}";
        DataBuffer buf = resp.bufferFactory().wrap(body.getBytes(StandardCharsets.UTF_8));
        return resp.writeWith(Mono.just(buf));
    }
    return Mono.empty();
});
 

熔断策略	count 含义	大模型场景建议
---	---	---
RT（grade=0）	慢调用阈值 ms	2000ms，超过即算慢
异常比例（grade=1）	异常占比	0.5，一半失败即熔断
异常数（grade=2）	异常次数	配合 minRequestAmount 使用

7. 最佳实践与踩坑点

踩坑点	现象	正确做法
---	---	---
限流 key 选错	整体限流挡不住单租户刷量	用 `paramItem` 按 `X-Tenant-Id` 细粒度限流
阈值写死	大促/故障需重启调整	规则放 Nacos，热更新
熔断后无降级	用户拿到裸 503	自定义 `blockHandler` 返回友好兜底
限流与鉴权顺序	被限流请求仍走了鉴权	限流过滤器排前，但鉴权失败应优先返回 401
忽略热点参数	某参数值被疯狂请求	用热点参数限流 `ParamFlowRule`
流控规则与路由不同步	Nacos 路由删了，限流规则还在	路由 CRUD 时联动清理 Sentinel 规则

工程建议：

• **分级限流**：网关入口做全局 QPS，再按 `X-Tenant-Id` 做租户级，再按 `model` 做模型级，三层递进；
• **限流要和额度挂钩**：第 08 篇 JWT 里的 `model_quota` 可作为限流 count 的来源，由 Nacos 统一治理；
• **熔断时间窗别太长**：大模型恢复通常快，10s 级别即可，避免长期不可用；
• **监控闭环**：接 Sentinel 控制台看实时 QPS/阻断数，异常陡增时联动告警；
• **与第 06 篇联动**：删除 Nacos 路由时，同步删除对应 Sentinel 资源规则，避免"幽灵规则"。

8. 本篇小结

本篇给"网关统一路由大模型接口 + Nacos 配置治理"装上稳定性保险——**限流熔断**：

1. 大模型算力稀缺且易雪崩，必须在网关入口做限流 + 熔断；
2. Sentinel 通过 `SentinelGatewayFilter` 把每条路由/API 分组变资源，`GatewayFlowRule` 配置限流（支持按 Header/参数细粒度，如按租户）；
3. 限流/熔断规则全部接入 Nacos 数据源，改 Nacos 即全网关生效，无需重启；
4. 熔断规则基于 RT/异常比例保护下游推理，熔断期间返回友好降级响应；
5. 与第 08 篇鉴权串联：`X-Tenant-Id` 由网关注入，本篇据此做租户级限流。

至此网关已具备"动态路由 + 动态实例 + 统一鉴权 + 限流熔断"四重能力。下一篇（第 10 篇）我们做最后一块拼图——**请求聚合编排：网关层组合调用多个大模型微服务**，让一次客户端请求背后协同多个模型能力。