Sentinel流量治理与熔断降级实战指南

1. 从雪崩效应到流量治理

去年双十一，我负责的电商系统经历了一场惊心动魄的流量洪峰。当时商品详情服务表现良好，但谁都没想到问题会出在一个看似不起眼的评论服务上。这个服务平时QPS只有200左右，但在大促第一个小时，流量突然暴涨到4000+。数据库连接池瞬间被打满，响应时间从正常的50ms飙升到惊人的30秒。

更可怕的是连锁反应：由于评论服务调用线程全部阻塞，很快耗尽了Tomcat的线程池。这导致所有新请求都被拒绝——包括与评论完全无关的下单、支付等核心接口。这就是典型的雪崩效应：一个边缘服务的崩溃，最终拖垮了整个系统。

关键教训：现代分布式系统中，任何一个服务都可能成为系统崩溃的导火索。我们需要在流量入口和服务调用链路上建立完善的隔离机制。

2. Sentinel核心架构解析

2.1 为什么选择Sentinel

在评估了Hystrix、Resilience4j等方案后，我们最终选择了Sentinel。这张对比表清晰地展示了各方案的差异：

特别值得注意的是，Hystrix已于2019年停止维护。对于Java技术栈，特别是使用Spring Cloud Alibaba的团队，Sentinel是目前最成熟的选择。

2.2 核心概念深度解读

资源(Resource)定义实践

在Sentinel中，资源是需要保护的最小单元。定义资源有两种推荐方式：

java复制// 方式1：手动埋点（适合精细控制）
try (Entry entry = SphU.entry("queryOrder")) {
    return orderService.query(orderId);
} catch (BlockException e) {
    // 触发流控时的降级逻辑
    return OrderDTO.fallback(); 
}

// 方式2：注解方式（推荐，更简洁）
@SentinelResource(
    value = "queryOrder",
    blockHandler = "queryOrderFallback",
    fallback = "queryOrderFallback"
)
public OrderDTO queryOrder(Long orderId) {
    return orderService.query(orderId);
}

// BlockException处理
public OrderDTO queryOrderFallback(Long orderId, BlockException ex) {
    log.warn("触发流控：{}", ex.getClass().getSimpleName());
    return OrderDTO.fallback();
}

// 通用fallback处理
public OrderDTO queryOrderFallback(Long orderId, Throwable t) {
    log.error("服务异常：", t);
    return OrderDTO.fallback();
}

重要提示：blockHandler只处理流控异常，fallback处理所有业务异常。生产环境建议同时配置两者。

插槽链工作机制

Sentinel的核心是一个精心设计的插槽链(ProcessorSlotChain)，每个资源调用都会经过以下关键处理节点：

1. NodeSelectorSlot：负责资源维度的统计信息收集
2. ClusterBuilderSlot：维护集群节点数据
3. StatisticSlot：实时采集QPS、RT等指标
4. FlowSlot：执行流量控制规则检查
5. DegradeSlot：执行熔断降级规则检查
6. SystemSlot：系统保护规则检查

其中StatisticSlot是整个体系的基础，它采