sentinel限流的基本使用

sentinel概念

 Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

sentinel控制台的概念

Sentinel控制台(sentinel-dashboard)是流量控制、熔断降级规则统一配置和管理的入口，它为用户提供了机器自发现、簇点链路自发现、监控、规则配置等功能。在 Sentinel 控制台上，我们可以配置规则并实时查看流量控制效果。

sentinel-dashboard控制台的下载和安装

注意点

• sentinel-dashboard控制台只能进行单机部署。但是阿里巴巴同时提供了AHAS Sentinel企业级的控制台实现高可用，同时提供更加详细的数据展示和告警措施，这里不再详述，有意者自己去学习。
• 启动 Sentinel 控制台需要 JDK 版本为 1.8 及以上版本
• 若您的应用为 Spring Boot 或 Spring Cloud 应用，您可以通过 Spring 配置文件来指定配置

依赖引用

注意：依赖引入事一定要注意和自己使用的springboot版本的对应，否者很可能无法正常使用

在父级模块进行管理alibaba的依赖
<dependencyManagement>
   <dependencies>
     <dependency>
                <groupId>com.alibaba.cloud</groupId>
                <artifactId>spring-cloud-alibaba-dependencies</artifactId>
                <version>2.1.0.RELEASE</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
      </dependencies>
</dependencyManagement>
在相应的业务模块引入sentinel模块的依赖
<dependency>
   <groupId>com.alibaba.cloud</groupId>
   <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
      <exclusions>
         <exclusion>
            <groupId>com.fasterxml.jackson.dataformat</groupId>
            <artifactId>jackson-dataformat-xml</artifactId>
         </exclusion>
      </exclusions>
</dependency>

与springboot整合配置

　　我使用的springboott项目版本为2.2.6.RELEASE，但我的项目只是一个简单的springboot项目并非springcloud和dubbo项目，如果想在springcloud或者dubbo集群项目中使用，还需要因为引入相应的适配器模块，具体的可以参看GitHub中相关文档，文章最后会附上链接。

　　其实sentinel和springboot的整合非常简单，只需要几个基本的配置即可，更多的配置github文档中有详细的介绍。

注解解读

@SentinelResource 注解

　　Sentinel 提供了 @SentinelResource 注解用于定义资源，并提供了 AspectJ 的扩展用于自动定义资源、处理 BlockException等。使用 Sentinel Annotation AspectJ Extension 的时候需要引入以下依赖：

<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-annotation-aspectj</artifactId>
    <version>x.y.z</version>
</dependency>

注解中的配置项解读：

• value：资源名称，必需项（不能为空）
• entryType：entry 类型，可选项（默认为 EntryType.OUT）
• blockHandler / blockHandlerClass: blockHandler 对应处理 BlockException 的函数名称，可选项。blockHandler 函数访问范围需要是 public，返回类型需要与原方法相匹配，参数类型需要和原方法相匹配并且最后加一个额外的参数，类型为 BlockException。blockHandler 函数默认需要和原方法在同一个类中。若希望使用其他类的函数，则可以指定 blockHandlerClass 为对应的类的 Class 对象，注意对应的函数必需为 static 函数，否则无法解析。
• fallback / fallbackClass：fallback 函数名称，可选项，用于在抛出异常的时候提供 fallback 处理逻辑。fallback 函数可以针对所有类型的异常（除了 exceptionsToIgnore 里面排除掉的异常类型）进行处理。fallback 函数签名和位置要求：
  • 返回值类型必须与原函数返回值类型一致；
  • 方法参数列表需要和原函数一致，或者可以额外多一个 Throwable 类型的参数用于接收对应的异常。
  • fallback 函数默认需要和原方法在同一个类中。若希望使用其他类的函数，则可以指定 fallbackClass 为对应的类的 Class 对象，注意对应的函数必需为 static 函数，否则无法解析。
• defaultFallback（since 1.6.0）：默认的 fallback 函数名称，可选项，通常用于通用的 fallback 逻辑（即可以用于很多服务或方法）。默认 fallback 函数可以针对所有类型的异常（除了 exceptionsToIgnore 里面排除掉的异常类型）进行处理。若同时配置了 fallback 和 defaultFallback，则只有 fallback 会生效。defaultFallback 函数签名要求：exceptionsToIgnore（since 1.6.0）：用于指定哪些异常被排除掉，不会计入异常统计中，也不会进入 fallback 逻辑中，而是会原样抛出。
• 返回值类型必须与原函数返回值类型一致；
• 方法参数列表需要为空，或者可以额外多一个 Throwable 类型的参数用于接收对应的异常。
• defaultFallback 函数默认需要和原方法在同一个类中。若希望使用其他类的函数，则可以指定 fallbackClass 为对应的类的 Class 对象，注意对应的函数必需为 static 函数，否则无法解析。

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

　　从 1.4.0 版本开始，注解方式定义资源支持自动统计业务异常，无需手动调用 Tracer.trace(ex) 来记录业务异常。Sentinel 1.4.0 以前的版本需要自行调用 Tracer.trace(ex) 来记录业务异常。

注意点：

• 注解方式埋点不支持 private 方法
• 1.6.0 之前的版本 fallback 函数只针对降级异常（DegradeException）进行处理，不能针对业务异常进行处理
• 一般推荐将 @SentinelResource 注解加到服务实现上，而在 Web 层直接使用 Spring Cloud Alibaba 自带的 Web 埋点适配。

@SentinelRestTemplate注解

持久化

 sentinel本身支持多种规则配置方式：

• sentinel-dashboard控制台直接配置

　　这种方式配置的规则只保存在内存中，在控制台重启的时候就会丢失所有配置的规则，这在生产环境肯定是不可取的，所以我们要把配置的规则持久化下来，这样可以保证重启服务后我们的配置规则不丢失，这也是我们会着重讲的方式。

• 通过Sentinel提供的SPI可扩展机制（这里不在详述）

　　这种方式可以保证我们每次启动客户端时或者控制台时都可以展示出来我们的配置规则，但是这种方式有个很大额弊端就是每次修改规则都要重新部署客户端代码。这在实际生产中肯定不行，于是有了动态配置的方式。

• 通过动态的配置

　　这种方式能够根据我们的需要动态的调整规则。但是这种方式同样有弊端，就是sentinel-dashboard本身无法单独完成需要外部的配置中心来配合管理规则的创建和修改，同时需要外部数据库来保证规则的持久化。具体分为两种模式：pull模式和push模式。

　　推送模式分为下面三种：

推送模式	说明	优点	缺点
原始模式	API 将规则推送至客户端并直接更新到内存中，扩展写数据源（WritableDataSource）	简单，无任何依赖	不保证一致性；规则保存在内存中，重启即消失。严重不建议用于生产环境
Pull 模式	扩展写数据源（WritableDataSource）， 客户端主动向某个规则管理中心定期轮询拉取规则，这个规则中心可以是 RDBMS、文件 等	简单，无任何依赖；规则持久化	不保证一致性；实时性不保证，拉取过于频繁也可能会有性能问题。
Push 模式	扩展读数据源（ReadableDataSource），规则中心统一推送，客户端通过注册监听器的方式时刻监听变化，比如使用 Nacos、Zookeeper 等配置中心。这种方式有更好的实时性和一致性保证。生产环境下一般采用 push 模式的数据源。	规则持久化；一致性；快速	引入第三方依赖

　　我们这里只讲解Push模式的实现。由于Nacos优秀的通信协议性能以及本身既可当规则配置中心又可作为服务注册发现中心的优势，就连springcloud目前都开放弃本身的服务注册发现中心（erruke和consule）和配置中心（springcloud config），我们有什么理由不使用它呢！并且Nacos的另个优势在于在部署集群时要比另一个著名的配置中心Appolo（携程开源的配置中心）简单的多。当然，如果各位有兴趣完全可以使用其他的配置中心，毕竟每个技术都有自己独特的优势。

sentinel和Nacos配合实现配置规则的持久化

学习链接

sentinel问题排查

sentinel的github文档