Sentinel 实战：注解一贴，熔断上线

从手艺到配置

手写熔断器适合搞懂原理，生产不能靠手艺——多实例部署、几百个资源、规则天天调，需要的是三件事：注解一贴就能用、规则不发版就能改、监控不用自己搭。Java 圈两个主流答案：阿里的 Sentinel 与轻量的 Resilience4j。本篇以 Sentinel 为主，把生产配套过一遍。

Spring Cloud Alibaba 项目接入只要两步，引 starter、配控制台地址：

<!-- pom.xml -->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

# application.yml
spring:
  cloud:
    sentinel:
      transport:
        dashboard: localhost:8080

服务启动后自动注册到控制台，Controller 方法、Feign 调用、RestTemplate 请求都会被自动包装成资源，出现在簇点链路里。

@SentinelResource：一个注解的事

核心注解 @SentinelResource：value 定义资源名，blockHandler 接住「被限流/熔断拒绝」的请求，fallback 接住「业务异常」：

@SentinelResource(value = "queryOrder",
                  blockHandler = "queryOrderBlock",
                  fallback = "queryOrderFallback")
public Order queryOrder(Long orderId) {
    return orderClient.query(orderId);      // 出去的调用
}

// 被熔断/限流拒绝时走这里：参数一致，末尾多一个 BlockException
public Order queryOrderBlock(Long orderId, BlockException ex) {
    return Order.cached(orderId);           // 降级：返回缓存
}

// 业务异常时走这里
public Order queryOrderFallback(Long orderId, Throwable e) {
    return Order.cached(orderId);
}

为什么要分两个出口？BlockException 意味着「系统主动挡的」，业务异常意味着「调用真的失败了」——两者的监控、告警、处置动作完全不同。混在一个 catch 里，出了问题连是谁干的都查不清。

熔断规则：把参数表翻译成 JSON

上篇那张判定参数表，在 Sentinel 里就是一条 DegradeRule：

{
  "resource": "queryOrder",
  "grade": 0,                // 0=慢调用比例（控制台里还可选异常比例、异常数）
  "count": 0.5,              // 慢调用比例阈值：50%
  "slowRtThreshold": 800,    // RT 超过 800ms 记为慢调用
  "statIntervalMs": 10000,   // 统计窗口 10 秒
  "minRequestAmount": 20,    // 窗口内不足 20 个请求不判定
  "timeWindow": 10           // 熔断时长 10 秒，到点进半开
}

这条规则读出来就是：queryOrder 的调用统计 10 秒窗口，RT 超 800ms 算慢调用，慢调用比例过 50% 且样本够 20 个就熔断 10 秒——与上篇的判定参数一一对应。规则可以推到 Nacos/Apollo 持久化，大促前调紧、大促后调松，控制台点一点，不用发版。

控制台：看得见的熔断器

sentinel-dashboard 起起来之后：簇点链路页能看到每个资源的实时 QPS、RT、异常数；熔断规则页可视化增删改；实时监控页有每秒通过/拒绝曲线。跳闸不再是黑盒——什么时候跳的、跳了多久、半开探测几次成功，全有据可查。

两个实战提醒：控制台改的规则默认存内存，应用一重启就丢，生产必须接 Nacos/Apollo 做规则数据源；监控数据默认按秒聚合，看看趋势足够，别拿它当精准计费依据。

Resilience4j：轻量派的另一个答案

Hystrix 已进入维护模式，新项目别再选它。选型一句话：要控制台、要阿里系生态、流量大——Sentinel；要轻量、要函数式、配置即代码——Resilience4j。两者的熔断判定原理与前面讲的完全一致，学的是原理，不是 API。

到这里，熔断的原理、判定、框架都齐了。但熔断只是把伤害按了暂停键——跳闸之后，用户看到的是什么？返回缓存、给默认值、还是友好提示页？什么时候砍功能、砍哪块？下篇聊服务降级的门道：有损服务的艺术。