在微服务系统中，有一种失败比“直接报错”更危险：

请求还能进来，但服务已经慢到不正常了。

线程在等待、连接在堆积、调用在排队。
表面上系统“还活着”，实际上已经在走向雪崩。

这一天，我们聊 Sentinel 的熔断能力，以及它在 AegisCloud 中扮演的角色。

为什么“限流”解决不了所有问题？

在上一篇的学习中我们已经为接口加上了限流规则，用来应对突发流量。

但现实中还有另一类问题：

  • QPS 不高
  • 并发不大
  • 但接口 越来越慢
  • 或者 异常开始频繁出现

例如：

  • 下游数据库变慢
  • 依赖服务网络抖动
  • 第三方接口偶发超时

这时候你会发现一个事实：

限流是“入口控制”，但问题发生在“执行过程”。

这正是熔断要解决的问题。

什么是熔断？

很多人第一次听到“熔断”，会误以为：

“是不是服务直接挂了？”

实际上恰恰相反。

熔断的本质是：

当系统判断某个服务“已经不健康”时，
主动停止继续消耗资源，保护整体系统的可用性。

不是拒绝用户，
而是避免把问题扩大成系统级事故。

一个典型的雪崩场景

假设有这样一条调用链：

1
2
3
A 服务
  ↓
B 服务（开始变慢）

如果没有熔断，会发生什么？

  1. A 不断调用 B
  2. B 响应越来越慢
  3. A 的线程被阻塞
  4. 线程池耗尽
  5. A 自己也开始不可用
  6. 整条链路雪崩

关键点在于：

失败不是瞬间发生的，而是“慢慢拖死”的。

Sentinel 的熔断关注什么？

Sentinel 并不关心业务语义，它只关心服务是否健康。

主要通过三类指标判断：

1. RT（响应时间）

  • 接口还能返回
  • 但平均 RT 明显升高
  • 说明系统已经“吃力”

2. 异常比例

  • 接口还能被调用
  • 但异常开始频繁出现
  • 成功率明显下降

3. 异常数

  • 单位时间内异常数量过多

今天我们重点关注 RT 熔断 和 异常比例熔断。

实战：RT 熔断如何生效？

1. 一个“慢接口”

1
2
3
4
5
6
7
8
9
10
@GetMapping("/slow")
@SentinelResource(value = "slowResource", blockHandler = "handleBlock")
public String slow() throws InterruptedException {
    Thread.sleep(2000);
    return "slow response";
}

public String handleBlock(BlockException ex) {
    return "服务暂时不可用（熔断中）";
}

这个接口没有异常，但 RT 非常高。

2. 配置 RT 熔断规则

在 Sentinel Dashboard 中配置，我们的请求数均设置成1，能很好的展示效果，但是这个值是为了防止低流量误熔断的，在真实场景中需要根据需求自行配置：

  • 资源名：slowResource
  • 熔断策略：RT
  • 最大 RT：1000ms
  • 最小请求数：1
  • 熔断时长：10s

含义可以翻译为一句话：

当 slowResource 的平均响应时间持续超过 1 秒，
且请求量达到一定规模时，
Sentinel 会主动“拉闸”。

3. 熔断发生时，发生了什么？

一旦熔断触发：

  • 请求 不会进入业务方法
  • 直接走 blockHandler
  • 不再执行 Thread.sleep
  • 系统资源得到释放

这一步非常关键：

熔断不是“执行失败”，而是“主动不执行”。

熔断不是一次性的，它有状态

Sentinel 的熔断是一个状态机：

  1. 关闭（Closed）
    • 正常放行请求
  2. 打开（Open）
    • 所有请求直接被拦截
  3. 半开（Half-Open）
    • 尝试放行少量请求
    • 判断服务是否恢复

这意味着：

熔断不是永久拒绝，而是带有“自我修复意图”的机制。

异常比例熔断：另一种保护方式

有些接口不是慢，而是不稳定。

1
2
3
4
5
6
7
8
@GetMapping("/error")
@SentinelResource(value = "errorResource", blockHandler = "handleBlock")
public String error() {
    if (Math.random() > 0.5) {
        throw new RuntimeException("mock error");
    }
    return "ok";
}

配置异常比例熔断：

  • 异常比例阈值：50%
  • 最小请求数：1
  • 熔断时长：10s 当异常占比持续过高时，Sentinel 同样会选择熔断。

站在 AegisCloud 的角度看熔断

在 AegisCloud 中，Sentinel 熔断不是“终点”，而是信号源。

Sentinel 行为 AegisCloud 意义
RT 熔断 性能退化信号
异常比例熔断 稳定性风险信号
熔断次数 健康度指标
熔断持续时间 恢复能力评估

一句话总结：

没有熔断，系统只能被动承受；
有了熔断，系统才开始“判断和选择”。

写在最后

熔断并不意味着系统失败，
恰恰相反——

熔断，是系统开始对自己负责的标志。

它承认当前能力有限，
选择暂时收缩，
为整体系统争取生存空间。

这，正是微服务走向自治的第一步。