微服务高可用：Sentinel 限流、熔断降级实战指南

微服务架构下，服务间的依赖关系复杂，任何一个环节出现问题都可能引发雪崩效应。在高并发场景下，保障服务的稳定性至关重要。Sentinel 作为阿里开源的流量控制、熔断降级组件，为微服务架构提供了强大的保障。

问题场景重现：高并发下的服务雪崩

想象一个电商系统，用户在秒杀活动期间涌入，请求量瞬间暴增。如果没有有效的流量控制机制，会导致以下问题：

• 下游服务过载： 大量请求涌入下游服务，导致 CPU 飙升、内存溢出，最终服务崩溃。
• 雪崩效应： 下游服务的崩溃会向上游服务蔓延，最终导致整个系统瘫痪。
• 用户体验下降： 请求超时、错误等问题频发，用户体验极差。

这种情况，就像 Nginx 服务器并发连接数超过上限时，新的请求会被拒绝一样。我们需要一种机制来保护我们的服务，防止被流量洪峰冲垮。

Sentinel 原理剖析：流量整形与服务保护

Sentinel 的核心原理在于流量整形和熔断降级。

流量整形（Flow Control）

Sentinel 通过预先配置的规则，对进入服务的流量进行控制，常用的流量控制策略包括：

• 直接拒绝： 当 QPS 超过阈值时，直接拒绝新的请求。
• Warm Up： 服务启动初期，逐步增加允许通过的请求，避免服务被瞬间流量冲垮。
• 匀速排队： 将请求放入队列中，以恒定的速率处理请求，保证服务的稳定性。

这些策略类似于 Nginx 中的 limit_req 模块，可以限制单个 IP 或用户的请求频率，防止恶意攻击。

熔断降级（Circuit Breaking）

当服务出现异常时，Sentinel 会触发熔断机制，停止向该服务发送请求，避免雪崩效应。常用的熔断策略包括：

• 平均响应时间： 当服务的平均响应时间超过阈值时，触发熔断。
• 异常比例： 当服务的异常比例超过阈值时，触发熔断。
• 异常数： 当服务的异常数超过阈值时，触发熔断。

熔断后，Sentinel 会进入一个恢复期，尝试向服务发送少量请求，如果服务恢复正常，则关闭熔断器。

Sentinel 实战：代码与配置示例

引入 Sentinel Starter

首先，在你的 Spring Boot 项目中引入 Sentinel Starter：

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

定义资源

使用 @SentinelResource 注解定义需要保护的资源：

@Service
public class OrderService {

    @SentinelResource(value = "getOrder", blockHandler = "blockHandlerForGetOrder", fallback = "fallbackForGetOrder")
    public String getOrder(String orderId) {
        // 业务逻辑
        return "Order: " + orderId;
    }

    // BlockHandler 处理流控降级
    public String blockHandlerForGetOrder(String orderId, BlockException e) {
        return "服务限流，请稍后再试！";
    }

    // Fallback 处理业务异常
    public String fallbackForGetOrder(String orderId, Throwable e) {
        return "服务异常，请稍后再试！";
    }
}

• value：资源名称，用于在 Sentinel 控制台中配置规则。
• blockHandler：处理 BlockException 的方法，用于处理流量控制、熔断降级等异常。
• fallback：处理业务异常的方法，用于处理业务逻辑抛出的异常。

配置流控规则

在 Sentinel 控制台中，你可以配置各种流控规则，例如：

• QPS 限流： 限制每秒钟通过的请求数量。
• 并发线程数限流： 限制同时访问资源的线程数量。

例如，配置 QPS 限流，限制 getOrder 资源的 QPS 为 10：

[
 {
 "resource": "getOrder",
 "limitApp": "default",
 "grade": 1, // 1 表示 QPS
 "count": 10,
 "strategy": 0, // 0 表示直接拒绝
 "controlBehavior": 0, // 0 表示直接拒绝
 "clusterMode": false
 }
]

配置熔断规则

同样，你可以在 Sentinel 控制台中配置熔断规则，例如：

• 平均响应时间熔断： 当 getOrder 资源的平均响应时间超过 100ms 时，触发熔断。
• 异常比例熔断： 当 getOrder 资源的异常比例超过 0.5 时，触发熔断。

[
 {
 "resource": "getOrder",
 "limitApp": "default",
 "grade": 0, // 0 表示 RT
 "count": 100, // 100ms
 "timeWindow": 10, // 10s
 "strategy": 0 //0:平均响应时间，1：异常比例，2：异常数
 "circuitBreakerCount": 5000 // 熔断时长 毫秒
 "clusterMode": false
 "statIntervalMs": 1000
 "maxAllowedRtMs": 100
 "minRequestAmount": 5
 "slowRatioAvgRt": 5
 }
]

实战避坑经验总结

• 资源定义要细致： 尽量将需要保护的资源定义得细致一些，例如，可以根据不同的业务场景定义不同的资源。
• 规则配置要合理： 根据实际情况配置流控规则和熔断规则，避免过度限流或误判。
• 监控与告警： 完善监控与告警体系，及时发现并处理异常情况。可以使用 Prometheus + Grafana 搭建监控系统，并配置钉钉或邮件告警。
• 优雅降级： 设计友好的降级页面或提示信息，提升用户体验。例如，可以将降级后的请求导向备用服务或静态页面。
• 熔断恢复期设置: 合理设置熔断后的恢复期，太短可能导致频繁熔断，太长则影响用户体验。

通过以上的实践，我们可以利用 Sentinel 更好地保障微服务的稳定性，应对高并发场景下的挑战。记住，没有银弹，需要结合自身的业务特点和系统架构，灵活运用 Sentinel 的各项功能。