Spring Boot微服务限流降级实战：Sentinel规则持久化与集群流控配置

微服务限流降级为什么不能只靠Sentinel默认配置

Sentinel默认把规则存在内存中，服务重启规则全部丢失，这在生产环境是不可接受的。集群流控在默认模式下每个节点独立计数，无法实现全局限流。这两点是Sentinel从开发环境迁移到生产环境时必须解决的问题，配置不当会导致限流失效或规则漂移。

Sentinel规则持久化的三种方案对比

规则持久化解决的核心问题是：规则变更后在服务重启、扩容、滚动更新时不丢失。三种方案各有适用场景：

1. Nacos数据源（推荐）

Nacos既做配置中心又做规则存储，Sentinel监听Nacos配置变更实时推送规则，无需额外中间件：

// pom.xml
<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-datasource-nacos</artifactId>
    <version>1.8.8</version>
</dependency>

// application.yml
spring:
  cloud:
    sentinel:
      datasource:
        flow-rules:
          nacos:
            server-addr: nacos:8848
            namespace: production
            group-id: SENTINEL_FLOW
            data-id: ${spring.application.name}-flow-rules
            rule-type: flow
        degrade-rules:
          nacos:
            server-addr: nacos:8848
            namespace: production
            group-id: SENTINEL_DEGRADE
            data-id: ${spring.application.name}-degrade-rules
            rule-type: degrade

在Nacos控制台编辑规则JSON即可实时生效。多条规则用数组格式存放：

[
  {
    "resource": "/api/orders",
    "limitApp": "default",
    "grade": 1,
    "count": 200,
    "strategy": 0,
    "controlBehavior": 2,
    "clusterMode": false
  }
]

controlBehavior=2表示匀速排队，避免瞬间拒绝导致请求堆积。grade=1是QPS限流模式。

2. Apollo数据源

Apollo更适合已有Apollo配置中心的基础设施团队，配置生效粒度更细，支持灰度发布规则。但引入Apollo只为Sentinel规则持久化的话架构偏重。

3. 自定义Push模式

通过Sentinel的WritableDataSource SPI接口对接内部配置平台，适合有自研运维平台的大型团队。开发成本较高但集成度最好。

集群流控的Token Server部署方案

集群限流需要所有节点向Token Server请求令牌，Token Server做全局计数。部署模式有两种：

独立Token Server模式

// Token Server独立部署
java -jar sentinel-token-server.jar \
  --server.port=8719 \
  --project.name=sentinel-cluster-server

// 应用端配置集群客户端
spring:
  cloud:
    sentinel:
      transport:
        port: 8721
        dashboard: sentinel-dashboard:8080
      cluster:
        client:
          mode: true
          server-host: sentinel-token-server
          server-port: 8719
          request-timeout: 200

嵌入模式（小集群推荐）

选一个应用实例同时充当Token Server，省去独立部署。适合3-5个节点的小集群，大集群不建议——Token Server宕机会影响被嵌入的那个实例。

// 嵌入模式配置
spring:
  cloud:
    sentinel:
      cluster:
        server:
          mode: true
          port: 8719
          flow:
            max-allow-qps: 5000

熔断降级规则的精细化配置

熔断降级的配置要区分慢调用比例和异常比例两种策略，不同接口适用不同策略：

// 慢调用比例策略——适合RT敏感的对外API
{
  "resource": "/api/orders/create",
  "grade": 0,           // 慢调用比例
  "count": 500,         // RT超过500ms算慢调用
  "timeWindow": 30,     // 熔断持续30秒
  "minRequestAmount": 10,  // 最少10次请求才触发判断
  "slowRatioThreshold": 0.6  // 慢调用比例超60%触发熔断
}

// 异常比例策略——适合内部调用
{
  "resource": "UserService:getUser",
  "grade": 2,           // 异常比例
  "count": 0.3,         // 异常比例超30%触发
  "timeWindow": 20,
  "minRequestAmount": 5
}

minRequestAmount的设置很关键——请求量太少时统计无意义，容易误触发。线上建议不低于5，核心接口不低于10。

限流降级的监控与告警

Sentinel Dashboard提供的实时监控只保留最近1分钟的数据，生产环境需要持久化到时序数据库。通过Sentinel的MetricExtension SPI接口，把指标推送到Prometheus：

public class PrometheusMetricExtension implements MetricExtension {
    @Override
    public void addPass(String resource, int count, long rt) {
        PrometheusCollector.passTotal.labels(resource).inc(count);
        PrometheusCollector.rtHistogram.labels(resource).observe(rt);
    }

    @Override
    public void addBlock(String resource, int count, String origin, String ruleLimitApp) {
        PrometheusCollector.blockTotal.labels(resource, ruleLimitApp).inc(count);
    }
}

Grafana面板配置限流拒绝率、平均RT、熔断状态三个核心看板，设置拒绝率超5%或熔断触发时自动告警。限流降级的终极目标是：用户感知不到后端有故障发生。