一文搞懂 Sentinel 限流熔断！

java -jar -Dserver.port=9999 sentinel-dashboard-1.8.2.jar

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

# sentinel看板的地址
spring.cloud.sentinel.transport.dashboard = localhost:9999
# 开启对sentinel看板的饥饿式加载。sentinel默认是懒加载机制，只有访问过一次的资源才会被监控，通过关闭懒加载，在项目启动时就连接sentinel控制台
spring.cloud.sentinel.eager = true

@RestController
@RequestMapping("/sentinel")
public class FlowLimitController {
    @GetMapping("/test")
    public String test(){
        return "接收到一条消息--------";
    }
}

Entry entry = null;
try {
    // 定义一个sentinel保护的资源，
    entry = SphU.entry(resourceName);
    // 被保护的业务逻辑
} catch (BlockException e) {
    // 如果被保护的资源被限流或者降级了，就会抛出BlockException
    log.warn("资源被限流或降级了", e);
} catch (InterruptedException e) {
    log.error("发生InterruptedException",e);
} finally {
    if (entry != null) {
        entry.exit();
    }
}

public static void main(String[] args) {
    // 配置规则.
    initFlowRules();
 
    // 1.5. 版本开始可以直接利用 try-with-resources 特性
    try (Entry entry = SphU.entry(resourceName)) {
        // 被保护的逻辑
        System.out.println("hello world");
    } catch (BlockException ex) {
        // 处理被流控的逻辑
        System.out.println("blocked!");
    }
}

示例代码如下：

// 资源名可使用任意有业务语义的字符串
if (SphO.entry("自定义资源名")) {
  // 务必保证finally会被执行
  try {
    /**
    * 被保护的业务逻辑
    */
  } finally {
    SphO.exit();
  }
} else {
  // 资源访问阻止，被限流或被降级
  // 进行相应的处理操作
}

注意：SphO.entry(xxx) 需要与 SphO.exit() 方法成对出现，匹配调用，位置正确，否则会导致调用链记录异常，抛出 ErrorEntryFreeException 异常。

（2）@SentinelResource注解方式(推荐)：

使用 @SentinelResource 注解可以更加的灵活的定义资源，如下示例就定义了一个名为 “HelloWorld” 的资源

@SentinelResource("HelloWorld")
public void helloWorld() {
    // 资源中的逻辑
    System.out.println("hello world");
}

需要注意的是，@SentinelResource 注解用于定义资源埋点，但不支持 private 方法。默认情况下，Sentinel 对控制资源的保护处理是直接抛出异常，这样对用户不友好，所以我们需要通过可选的异常处理 blockHandler 和 fallback 配置项处理一下异常信息。@SentinelResource 注解包含以下属性：

① value： 资源名称，必需项

② entryType： entry 类型，可选项（默认为 EntryType.OUT）

③ blockHandler/blockHandlerClass： blockHandler 指定函数负责处理 BlockException 异常，可选项。blockHandler 函数默认需要和原方法在同一个类中，通过指定 blockHandlerClass 为对应类的 Class 对象，则可以指定其他类中的函数，但注意对应的函数必需为 static 函数，否则无法解析。

blockHandler 函数访问范围需要是 public，返回类型需要与原方法相匹配，参数类型必须和原方法一致并且后加一个类型为 BlockException 的异常参数。

④ fallback /fallbackClass： fallback 指定的函数负责处理业务运行的异常，可选项，fallback 函数可以针对所有类型的异常（除了exceptionsToIgnore里面排除掉的异常类型）进行处理。fallback 函数默认需要和原方法在同一个类中，通过指定 fallbackClass 为对应类的 Class 对象，则可以指定指定为其他类的函数，但注意对应的函数必需为 static 函数，否则无法解析。

fallback 函数的返回值类型必须与原函数返回值类型一致；方法参数列表需要和原函数一致，或者可以额外多一个 Throwable 类型的参数用于接收对应的异常。

⑤ defaultFallback（since 1.6.0）： 默认的 fallback 函数名称，可选项，通常用于通用的 fallback 逻辑。defaultFallback 函数默认需要和原方法在同一个类中，通过指定 fallbackClass 为对应类的 Class 对象，则可以指定指定为其他类的函数，但注意对应的函数必需为 static 函数，否则无法解析。defaultFallback 函数可以针对所有类型的异常（除了 exceptionsToIgnore 里面排除掉的异常类型）进行处理。若同时配置了 fallback和 defaultFallback，则只有 fallback会生效。

defaultFallback函数的返回值类型必须与原函数返回值类型一致；方法参数列表需要为空，或者可以额外多一个 Throwable 类型的参数用于接收对应的异常。

⑥ exceptionsToIgnore（since 1.6.0）： 用于指定哪些异常被排除掉，不会计入异常统计中，也不会进入 fallback 逻辑中，而是会原样抛出。

特别地，若 blockHandler 和 fallback 都进行了配置，则被限流降级而抛出 BlockException 时只会进入 blockHandler 处理逻辑。若未配置 blockHandler、fallback 和 defaultFallback，则被限流降级时会将 BlockException 直接抛出（若方法本身未定义 throws BlockException 则会被 JVM 包装一层 UndeclaredThrowableException）

@SentinelResource 的 fallback 负责业务运行的异常，blockHandler 负责 sentinel 配置的违规。

1.2、定义规则：

    Sentinel 支持以下几种规则：流量控制规则、熔断降级规则、系统保护规则、来源访问控制规则 和 热点参数规则。而定义规则同样支持两种方式：一种是硬编码的方式，一种是通过 sentinel-dashboard 控制台直接配置，这部分我们在下文会继续介绍。

2、流控规则：

2.1、流控规则的核心属性：

流量控制，原理是监控应用流量的 QPS 或 并发线程数 等指标，当达到指定阈值时对流量进行控制，避免系统被瞬时的流量高峰冲垮，保障应用高可用性。同一个资源可以创建多条限流规则，一条限流规则由以下属性组成：

① resource： 资源名，即限流规则的作用对象，默认请求路径。

② limitApp： 流控针对的调用来源，若为 default 则不区分调用来源，默认值default

③ count： 限流阈值

④ grade： 限流阈值类型（1代表 QPS，0 代表并发线程数），默认值QPS

⑤ strategy： 流控模式

• 直接拒绝（默认）： 接口达到限流条件时，直接限流
• 关联： 当关联的资源达到阈值时，就限流自己（适合做应用让步）
• 链路： 只记录指定链路上的流量，指定资源从入口资源进来的流量，如果达到阈值，就可以限流

⑥ controlBehavior： 流控效果

• 快速失败（默认）： 当 QPS 超过任意规则的阈值后，新的请求就会被立即拒绝，拒绝方式为抛出FlowException
• 排队等待： 这种方式严格控制了请求通过的间隔时间，也即是让请求以均匀的速度通过，对应的是漏桶算法。
• Warm Up： 该方式主要用于系统长期处于低水位的情况下，当流量突然增加时，直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动"，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮的情况。预热底层是根据令牌桶算法实现的。

以上几种属性在 sentinel-dashboard 控制台对应的规则如下图：

2.2、阈值类型：

（1）基于 QPS 的流控：

QPS，每秒请求数，即在不断向服务器发送请求的情况下，服务器每秒能够处理的请求数量。

（2）基于并发线程数的流控：

并发数控制用于保护业务线程池不被慢调用耗尽。例如，当应用所依赖的下游应用由于某种原因导致服务不稳定、响应延迟增加，对于调用者来说，意味着吞吐量下降和更多的线程数占用，极端情况下甚至导致线程池耗尽。为应对太多线程占用的情况，业内有使用隔离的方案，比如：

• 通过不同业务逻辑使用不同线程池来隔离业务自身之间的资源争抢（线程池隔离），这种隔离方案虽然隔离性比较好，但是代价就是线程数目太多，线程上下文切换的 overhead 比较大，特别是对低延时的调用有比较大的影响。

• 使用信号量来控制同时请求的个数（信号量隔离），这种隔离方案虽然能够控制线程数量，但无法控制请求排队时间，当请求过多时排队也是无益的，直接拒绝能够迅速降低系统压力。

Sentinel 并发线程数限流不负责创建和管理线程池，而是简单统计当前请求上下文的线程个数（正在执行的调用数目），如果超出阈值，新的请求会被立即拒绝，效果类似于信号量隔离。并发数控制通常在调用端进行配置。

2.3、流控效果：

当系统的流量超过设定的阈值时，sentinel 则采取措施进行流量控制，流控效果总共分为三种：快速失败、Warm Up、排队等待。对应的 FlowRule 中的 controlBehavior 字段。

• 快速失败（默认）： 当 QPS 超过任意规则的阈值后，新的请求就会被立即拒绝，拒绝方式为抛出FlowException
• 排队等待： 这种方式严格控制了请求通过的间隔时间，也即是让请求以均匀的速度通过，对应的是漏桶算法。
• Warm Up： 该方式主要用于系统长期处于低水位的情况下，当流量突然增加时，直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动"，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮的情况。预热底层是根据令牌桶算法实现的。

注意：若使用除了快速失败之外的流量控制效果，则调用关系限流策略（strategy）会被忽略。

（1）快速失败：

默认的流量控制方式，当 QPS 超过任意规则的阈值后，新的请求就会被立即拒绝，拒绝方式为抛出FlowException。这种方式适用于对系统处理能力确切已知的情况下，比如通过压测确定了系统的准确水位时

（2）Warm Up：

注意：该方式只针对 QPS 流控，对并发线程数流控不支持

即预热/冷启动方式，该方式主要用于系统长期处于低水位的情况下，当流量突然增加时，直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动"，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮的情况。

预热底层是根据令牌桶算法实现的，源码对应得类在 com.alibaba.csp.sentinel.slots.block.flow.controller.WarmUpController 中，算法中有一个冷却因子coldFactor，默认值是3，即请求 QPS 从 threshold(阈值) / 3 开始，经预热时长逐渐升至设定的 QPS 阈值。

比如通过 sentinel-dashboard 设定 testWarmUP 资源的 QPS 阈值为，流控效果为 warm up，预热时长为5秒，如下图所示，testWarmUP 资源刚开始限流的阈值为 20/3=7，但经过10秒的预热后，慢慢将阈值升至20。

通常冷启动的过程系统允许通过的 QPS 曲线如下图所示：

比如秒杀系统在开启瞬间，会有很多流量上来，很可能把系统打死，预热方式就是为了保护系统，可慢慢的把流量放进来，慢慢的把阈值增长到设置的阈值。

（3）排队等待：

注意：这一效果只针对QPS流控，并发线程数流控不支持。

排队等待的方式会以匀速排队方式严格控制请求通过的间隔时间，也就是让请求以均匀的速度通过，其余的排队等待，它还会让设置一个超时时间，当请求超过超时间时间还未处理，则会被丢弃。

对应的是漏桶算法，源码对应得类：com.alibaba.csp.sentinel.slots.block.flow.controller.RateLimiterController。该方式的作用如下图：

该方式主要用于处理间隔性突发的流量。假设某时刻来了大流量的请求，如果此时要处理所有请求，很可能会导致系统负载过高，影响稳定性。

但其实接下来几秒可能系统处于空闲状态，若直接把多余的请求丢弃则没有充分利用系统的处理能力，所以我们希望系统能够在接下来的空闲期间逐渐处理这些请求，而不是在秒直接拒绝多余的请求。

Sentinel 的 Rate Limiter 模式能在某一段时间间隔内以匀速方式处理这样的请求, 充分利用系统的处理能力, 也就是削峰填谷, 保证资源的稳定性。

Sentinel会以固定的间隔时间让请求通过, 访问资源，当请求到来时，如果当前请求距离上个通过的请求通过的时间间隔不小于预设值，则让当前请求通过；否则，计算当前请求的预期通过时间，如果该请求的预期通过时间大于规则预设的 timeout 时间，则该请求会等待直到预设时间到来通过；反之，则马上抛出阻塞异常。

下图能很形象的展示这种场景的削峰填谷的作用：X轴代表时间，Y轴代表系统处理的请求

比如通过 sentinel-dashboard 对 service 资源设置限流阈值为10，流控效果为排队等候，每秒10次请求时，再有请求就排队等候，等待超时时间为 10000ms，超时过后，请求将被踢出排队队列，返回限流异常。

2.4、流控模式：

调用关系包括调用方、被调用方；一个方法又可能会调用其它方法，形成一个调用链路的层次关系。Sentinel 通过 NodeSelectorSlot 建立不同资源间的调用的关系，并且通过 ClusterBuilderSlot 记录每个资源的实时统计信息。有了调用链路的统计信息，我们可以衍生出多种流量控制模式，总共分为三种，对应属性为 strategy：

• 直接拒绝（默认）： 接口达到限流条件时，直接限流
• 关联： 当关联的资源达到阈值时，就限流自己（适合做应用让步）
• 链路： 只记录指定链路上的流量，指定资源从入口资源进来的流量，如果达到阈值，就可以限流

（1）直接拒绝：

默认的流控模式，当QPS超过任意规则的阈值后，新的请求就会被立即拒绝，拒绝方式为抛出 FlowException，这里不再详细介绍。

（2）关联：

当两个资源之间具有资源争抢或者依赖关系的时候，这两个资源便具有了关联，该流控模式的作用是当关联的资源达到阈值时，就限流自己，适合做应用让步。

比如对数据库同一个字段的读操作和写操作存在争抢，读的速度过高会影响写得速度，写的速度过高会影响读的速度，如果放任读写操作争抢资源，则争抢本身带来的开销会降低整体的吞吐量，这时可使用关联限流来避免具有关联关系的资源之间过度的争抢。

举例来说，read_db 和 write_db 这两个资源分别代表数据库读写，我们可以给 read_db 设置限流规则来达到写优先的目的

还有一个例子，电商的 下订单 和 支付 两个操作，一旦支付接口达到了阈值，那么需要优先保障支付操作， 那么订单接口就应用被限流，从而保护支付的目的。

@RestController
@RequestMapping("/sentinel")
public class FlowLimitController {
 
    /**
     * 下单接口
     */
    @GetMapping("/order")
    public String order()  {
        return "下单成功..........";
    }
 
    /**
     * 支付接口
     */
    @GetMapping("/pay")
    public String pay()  {
        return "支付成功..........";
    }
}

此时的流控规则配置如下图：

注意：关联之后，这里设置的限流规则是针对被关联资源，也就是 /sentinel/pay 这个资源，但是真正被限流则是 /sentinel/order。我们只需要不断的请求 /sentinel/pay 达到阈值，然后在请求 /sentinel/order，就可以看到订单接口被限流了

（3）链路：

该流控模式针对资源链路上的接口进行限流，例如：A、B两个接口都调用某一资源C，A -> C、B -> C 可以看成两个简单的链路，此时可以针对C配置链路限流，比如限制A调用C，而B调用C则不受影响，它的功能有点类似于针对来源配置项，但链路流控是针对上级接口，它的粒度更细。

@RestController
public class TestController  {
 
    @Autowired
    TestService testService;
 
    @GetMapping("/test")
    public String test() throws InterruptedException {
        testService.test();
        System.out.println("链路流控模式限流示例");
        return "test";
    }
 
    @GetMapping("/test1")
    public String test1(){
        testService.test();
        System.out.println("正常链路接口");
        return "test";
    }
}

@Service
public class TestService {
 
    @SentinelResource(value = "service")
    public void test() {
        System.out.println("service");
    }
}

添加配置：

spring.cloud.sentinel.web-context-unify=false

此时的流控规则配置如下图：

不断访问 test 和 test1 两个接口，发现即使 test 接口被限流了，test1 接口也不受影响。

2.5、流控规则的硬编码方式：

前面的示例都是基于 sentinel-dashboard 控制台去定义限流规则，但我们也可以通过调用 FlowRuleManager.loadRules() 方法来用硬编码的方式定义流量控制规则，比如：

private void initFlowQpsRule() {
    List<FlowRule> rules = new ArrayList<>();
    FlowRule rule = new FlowRule(resourceName);
    // set limit qps to 20
    rule.setCount(20);
    rule.setGrade(RuleConstant.FLOW_GRADE_QPS);
    rule.setLimitApp("default");
    rules.add(rule);
    FlowRuleManager.loadRules(rules);
}

官网示例链接：

https://github.com/alibaba/Sentinel/wiki/如何使用#流量控制规则-flowrule

3、熔断降级规则：

3.1、熔断降级规则的核心属性：

熔断机制可以防止应用程序不断执行可能失败的操作，快速地拒绝可能导致错误的调用，当感知到下游服务的资源出现不稳定状态（调用超时或异常比例升高时），暂时切断对下游服务的调用，而不是一直阻塞等待服务响应，阻止级联失败导致的雪崩效应，保证系统的可用性；尤其是后端太忙的时候，使用熔断设计可以保护后端不会过载。

另外，在微服务架构下，我们一般都会设置超时与重试机制，但如果错误太多，或是在短时间内得不到修复，那么我们重试也没有意义了，这时也需要使用熔断机制快速返回结果。当资源被熔断降级后，在接下来的降级时间窗口之内，对该资源的调用都会自动返回降级数据（默认行为是抛出 DegradeException），当检测到该节点的服务调用响应正常后，则恢复调用链路。

熔断降级规则包含以下核心属性：

以上几种属性在 sentinel-dashboard 控制台对应的规则如下图：

3.2、熔断策略：

sentinel 提供了以下几种荣熔断策略：

（1）平均响应时间 ：

DEGRADE_GRADE_RT，当资源的平均响应时间超过阈值（DegradeRule 中的 count，以 ms 为单位）之后，资源会进入降级状态，那么在接下的时间窗口（DegradeRule 中的 timeWindow，以 s 为单位）之内，对这个方法的调用都会自动地熔断（抛出 DegradeException）。

注意：Sentinel 默认统计的 RT 上限是 4900 ms，超出此阈值的都会算作 4900 ms，若需要变更此上限可以通过启动配置项 -Dcsp.sentinel.statistic.max.rt=xxx 来配置。

（2）异常比例 ：

DEGRADE_GRADE_EXCEPTION_RATIO，当资源的每秒异常总数占通过量的比值超过阈值（DegradeRule 中的 count）之后，资源进入降级状态，即在接下的时间窗口（DegradeRule 中的 timeWindow，以 s 为单位）之内，对这个方法的调用都会自动地熔断。

异常比率的阈值范围是 [0.0, 1.0]，代表 0% - 。

（3）异常数 ：

DEGRADE_GRADE_EXCEPTION_COUNT，当资源近 1 分钟的异常数目超过阈值之后会进行熔断。

注意由于统计时间窗口是分钟级别的，若 timeWindow 小于 60s，则结束熔断状态后仍可能再进入熔断状态。

3.3、熔断降级规则的硬编码方式：

在 sentinel-dashboard 控制台去定义熔断规则比较简单，我们就不详细展开了。除此之外，我们也可以通过调用 DegradeRuleManager.loadRules() 方法来用硬编码的方式定义流量控制规则，比如：

@PostConstruct
public void initSentinelRule()
{
    //熔断规则：5s内调用接口出现异常次数超过5的时候, 进行熔断
    List<DegradeRule> degradeRules = new ArrayList<>();
    DegradeRule rule = new DegradeRule();
    rule.setResource("queryGoodsInfo");
    rule.setCount(5);
    //熔断规则
    rule.setGrade(RuleConstant.DEGRADE_GRADE_EXCEPTION_COUNT);
    rule.setTimeWindow(5);
    degradeRules.add(rule);
    DegradeRuleManager.loadRules(degradeRules);
}

官方示例链接：

https://github.com/alibaba/Sentinel/wiki/如何使用#熔断降级规则-degraderule

4、热点参数规则：

热点就是经常访问的数据，很多时候我们肯定希望统计某个访问频次 Top K 数据并对其进行限流，比如：

• 商品 ID 为参数，统计一段时间内常购买的商品 ID 并进行限制
• 用户 ID 为参数，针对一段时间内频繁访问的用户 ID 进行限制

热点参数限流会统计传入参数中的热点参数，并根据配置的限流阈值与模式，对包含热点参数的资源调用进行限流。热点参数限流可以看做是一种特殊的流量控制，仅对包含热点参数的资源调用生效。

Sentinel 利用 LRU 策略统计近常访问的热点参数，结合令牌桶算法来进行参数级别的流控。

热点参数限流只针对QPS。

4.1、热点参数规则的核心属性：

热点参数规则（ParamFlowRule）类似于流量控制规则（FlowRule）：

4.2、热点参数规则的硬编码方式：

（1）定义资源：

@GetMapping("/byHotKey")
@SentinelResource(value = "byHotKey",blockHandler = "userAccessError")
public String byHotKeyTest(@RequestParam(value = "userId", required = false) String userId,
                    @RequestParam(value = "goodId", required = false) int goodId)
{
    log.info(Thread.currentThread().getName() + "\t" + "...byHotKey");
    return "-----------by HotKey：UserId";
}

可以看到，我们上边的代码示例有两个参数，分别是 userId、goodId

（2）添加热点参数限流规则：*

我们可以通过 ParamFlowRuleManager 的 loadRules 方法配置热点参数规则，案例的具体限流代码如下：

ParamFlowRule pRule = new ParamFlowRule("byHotKey")
    .setParamIdx(1)
    .setCount(1);
// 针对 goodId 为1000 的参数值，单独设置限流 QPS 阈值为 5，而不是全局的阈值 1.
ParamFlowItem item = new ParamFlowItem().setObject(String.valueOf(1000))
                .setClassType(int.class.getName())
                .setCount(5);
pRule.setParamFlowItemList(Collections.singletonList(item));
 
ParamFlowRuleManager.loadRules(Collections.singletonList(pRule));

官方示例链接 ：

https://github.com/alibaba/Sentinel/wiki/热点参数限流

4.3、热点参数的控制台配置方式：

上述配置的具体含义，当 “byHotKey” 这个资源的第1个参数（这里参数索引是从0开始），即 goodId 的 QPS 超过1秒1次将会被限流，需要注意的是，只有包含指定索引的参数请求才会被限流，否则不影响。

另外，sentinel 提供了 参数例外项 这个配置，从上图配置中，我们将 参数 goodId 的参数值等于1000 时，限流阈值设置成了 5，也就是说 goodId = 1000 这个请求 QPS 放宽到每秒 5 次 以上才会被限流。

5、系统保护规则：

Sentinel 系统保护的目标是在系统不被拖垮的情况下，提高系统的吞吐率，系统自适应限流从整体维度对应用入口流量进行控制，从单台机器的 Load、CPU 使用率、总体平均 RT、入口 QPS 和 并发线程数 等几个维度的监控指标，通过自适应的流控策略，让系统的入口流量和系统的负载达到一个平衡，让系统尽可能跑在大吞吐量的同时保证系统整体的稳定性。

5.1、系统保护规则的核心属性：

系统保护规则包含下面几个重要的属性：

所以，sentinel 的系统保护支持以下几种模式：

• Load 自适应：（仅对 Linux/Unix-like 机器生效）系统的 load1 作为触发指标，进行自适应系统保护。当系统 load1 超过设定的触发值，且系统当前的并发线程数超过估算的系统容量时才会触发系统保护（BBR 阶段）。系统容量由系统的 maxQps * minRt 估算得出。设定参考值一般是 CPU cores * 2.5。
• CPU usage：（1.5.0+ 版本）当系统 CPU 使用率超过阈值即触发系统保护（取值范围 0.0-1.0），比较灵敏。
• 平均 RT： 当单台机器上所有入口流量的平均 RT 达到阈值即触发系统保护，单位是毫秒。
• 并发线程数： 当单台机器上所有入口流量的并发线程数达到阈值即触发系统保护。
• 入口 QPS： 当单台机器上所有入口流量的 QPS 达到阈值即触发系统保护。

以上几种模式在 sentinel-dashboard 控制台对应的配置如下图：

注意：系统保护规则是应用整体维度的，而不是资源维度的，并且仅对入口流量生效。入口流量指的是进入应用的流量，比如 Web 服务或 Dubbo 服务端接收的请求，都属于入口流量。

5.2、系统保护规则的硬编码方式：

除了在 sentinel 控制台配置系统保护规则，我们也可以通过调用 SystemRuleManager.loadRules() 方法来用硬编码的方式定义流量控制规则。

private void initSystemRule() {
    List<SystemRule> rules = new ArrayList<>();
    SystemRule rule = new SystemRule();
    rule.setHighestSystemLoad(10);
    rules.add(rule);
    SystemRuleManager.loadRules(rules);
}

官方示例链接：

https://github.com/alibaba/Sentinel/wiki/如何使用#系统保护规则-systemrule

6、来源访问控制规则：

来源访问控制，就是根据调用来源判断该次请求是否允许放行，也就是黑白名单控制。若配置白名单则只有请求来源位于白名单内时才可通过；若配置黑名单则请求来源位于黑名单时不通过，其余的请求通过。

6.1、来源访问控制的核心配置：

来源访问控制规则（AuthorityRule）非常简单，主要有以下配置项：

• resource： 资源名，即限流规则的作用对象。
• limitApp： 对应的黑名单/白名单，不同来源用 “,” 分隔，如 “appA,appB”。
• strategy： 限制模式，AUTHORITY_WHITE 为白名单模式，AUTHORITY_BLACK 为黑名单模式，默认为白名单模式。

6.2、来源访问规则的硬编码方式：

比如我们希望控制对资源 test 的访问设置白名单，只有来源为 appA 和 appB 的请求才可通过，则可以配置如下白名单规则：

官方示例链接：

https://github.com/alibaba/Sentinel/wiki/如何使用#访问控制规则-authorityrule

6.3、来源访问规则的控制台配置方式：

7、集群流控：

7.1、为什么需要集群流控：

有了单机流控，还需要集群流控的原因如下：

• 微服务要保证高可用，必须是集群，假设有100个集群，那么想要设置流控规则，就要每个微服务都设置一遍，这样的维护成本太高了
• 单体流控容易造成流量不均匀的问题，出现总流控阈值没有达到，但某些微服务却已经被限流了，这个是非常糟糕的问题，因此实际生产中对于集群不推荐单体流控。

所以 sentinel 提供了集群流控规则解决上述的问题，思想很简单，就是提供一个专门的 server 来统计调用的总量，其他的实例都与 server 保持通信。通过集群流控可以地控制整个集群的调用总量，结合单机限流兜底，可以更好地发挥流量控制的效果。集群流控中间共有两种身份：

• Token Client： 集群流控客户端，用于向所属 Token Server 通信请求 token。集群限流服务端会返回给客户端结果，决定是否限流。
• Token Server： 即集群流控服务端，处理来自 Token Client 的请求，根据配置的集群规则判断是否应该发放 token（是否允许通过）。

sentinel的集群限流有两种模式，分别如下：

• 独立模式（Alone）： 即作为独立的 token server 进程启动，独立部署，隔离性好，但是需要额外的部署操作。独立模式适合作为 Global Rate Limiter 给集群提供流控服务。
• 嵌入模式（Embedded）： 即作为内置的 token server 与服务在同一进程中启动。在此模式下，集群中各个实例都是对等的，token server 和 client 可以随时进行转变，因此无需单独部署，灵活性比较好。但是隔离性不佳，需要限制 token server 的总 QPS，防止影响应用本身。嵌入模式适合某个应用集群内部的流控。

7.2、集群流控的控制台配置方式：

下面就以嵌入模式为例介绍一下如何配置。就以 sentinel-openfeign-provider 这个模块作为演示，直接启动三个集群，端口分别为 9009、9011、9013，如下图：

此时只需要在控制台指定一个服务为token server，其他的为token client，集群流控->新增token server，操作如下图：

选取一个作为服务端，另外两个作为客户端，此时就已经配置好了，如下图：

此时就可以添加集群流控规则了，可以在sentinel控制台直接添加，如下图：

至此集群流控到这儿就介绍完了

四、sentinel 整合 openFeign：

上文介绍的都是在单个模块间的进行 fallback 和 blockhandler 测试，但在实际的 SpringCloud 微服务开发场景中肯定会遇到服务间远程服务调用的问题，而目前主流的远程调用组件就是 openFeign 了，那接下来我们看看 sentinel 如何整合 openFeign 进行熔断降级。

1、引入 openFeign 的依赖：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

2、配置文件中开启 openFeign 对 sentinel 熔断降级的支持：

feign.sentinel.enabled=true

3、消费者主启动类添加注解 @EnableFeignClients 激活 openFeign

4、消费者声明接口，标识要调用提供方模块的哪个方法，并在 @FeignClient 注解中使用 fallback 属性指定熔断降级类：

@FeignClient(value = "payment-provider", fallback = PaymentServiceImpl.class)
public interface PaymentService {
 
    @GetMapping("/payment/get/{id}")
    public CommonResult paymentSql(@PathVariable("id")Long id);
}

5、添加降级类：实现第4步的定义的接口，并添加降级逻辑：

@Component
public class PaymentServiceFallback implements PaymentService {
 
    @Override
    public CommonResult paymentSql(Long id) {
        return new CommonResult(414, "open-feign 整合 sentinel 实现的全局服务降级策略",null);
    }
}

PaymentServiceFallback 是 PaymentService 的降级回调类，一旦PaymentService 中对应得接口出现了异常，则会调用这个类中对应得方法进行降级处理。

五、Sentinel 所存在的问题：

通过 Sentinel-Dashboard 控制台配置的规则依然要推送到微服务应用中 Sentinel 客户端本身才能生效，而微服务之间的调用链路等指标信息也需要推送给Sentinel控制台，才能比较方便地使用Sentinel提供的一些能力，因此在开源的架构版本中需要微服务应用本身开启独立端口与 sentinel-dashboard 进行通信，从而获取配置规则以及上送微服务应用的各类指标信息。

而这显然也会占用微服务额外的资源，并且由于 sentinel-dashboard 在此条件下并不具备集群部署能力，因此也会形成一个单节点问题，但是有一套控制台总好过于没有，如果希望比较方便快速地应用 Sentinel 这也是一种代价。此时的 Sentinel 架构如下图所示：

在开源版本架构中，通过 sentinel-dashboard 控制台配置的限流、熔断降级等规则都是存储于 Sentinel-Dashboard 控制台服务的内存之中，如果控制台服务重启或者微服务应用重启都会导致规则丢失，而这在生产环境下显然是不能接受的，因此 Sentinel 官方推荐在生产架构中使用第三方数据源作为存储中心，比如 nacos、apollo、zookeeper，这样各个微服务的限流、降级规则都可以存储。