spring-cloud-alibaba-3.4-Sentinel-在生产环境中使用

在生产环境中使用 Sentinel

生产环境中使用Sentinel

生产环境的 Sentinel Dashboard 需要具备下面几个特性:

• 规则管理及推送，集中管理和推送规则。sentinel-core 提供 API 和扩展接口来接收信息。开发者需要根据自己的环境，选取一个可靠的推送规则方式；同时，规则最好在控制台中集中管理。
• 监控，支持可靠、快速的实时监控和历史监控数据查询。sentinel-core 记录秒级的资源运行情况，并且提供 API 来拉取资源运行信息。当机器大于一台以上的时候，可以通过 Dashboard 来拉取，聚合，并且存储这些信息。这个时候，Dashboard 需要有一个存储媒介，来存储历史运行情况。
• 权限控制，区分用户角色，来进行操作。生产环境下的权限控制是非常重要的，理论上只有管理员等高级用户才有权限去修改应用的规则。

规则管理及推送

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

原始模式

如果不做任何修改，Dashboard 的推送规则方式是通过 API 将规则推送至客户端并直接更新到内存中：

这种做法的好处是简单，无依赖；坏处是应用重启规则就会消失，仅用于简单测试，不能用于生产环境。

Pull模式

pull 模式的数据源（如本地文件、RDBMS 等）一般是可写入的。 下图以本地文件为例。

首先 Sentinel 控制台通过 API 将规则推送至客户端并更新到内存中，接着注册的写数据源会将新的规则保存到本地的文件中。

然后 其他客户端会定时的去轮询本地文件，从而对本地的规则进行变更。

这种实现方法好处是简单，不引入新的依赖，坏处是无法保证监控数据的一致性。

Push 模式

生产环境下一般更常用的是 push 模式的数据源。

推送规则正确做法应该是 配置中心控制台/Sentinel 控制台 → 配置中心 → Sentinel 数据源 → Sentinel，而不是经 Sentinel 数据源推送至配置中心。

---

监控

Sentinel 会记录资源访问的秒级数据（若没有访问则不进行记录）并保存在本地日志 ${user_home}/logs/csp/${app_name}-${pid}-metrics.log，具体格式如下；

1532415661000|2018-07-24 15:01:01|sayHello(java.lang.String)|12|3|4|2|295

1532415661000：时间戳
2018-07-24 15:01:01：格式化之后的时间戳
sayHello(java.lang.String)：资源名
12：表示到来的数量，即此刻通过 Sentinel 规则 check 的数量（passed QPS）
3：实际该资源被拦截的数量（blocked QPS）
4：每秒结束的资源个数（完成调用），包括正常结束和异常结束的情况（exit QPS）
2：异常的数量
295：资源的平均响应时间（RT）

Sentinel 控制台可以通过 Sentinel 客户端预留的 HTTP API 从秒级监控日志中拉取监控数据，并进行聚合。

目前 Sentinel 控制台中监控数据聚合后直接存在内存中，未进行持久化，且仅保留最近 5 分钟的监控数据。若需要监控数据持久化的功能，可以自行扩展实现 MetricsRepository 接口（0.2.0 版本），然后注册成 Spring Bean 并在相应位置通过 @Qualifier 注解指定对应的 bean name 即可。MetricsRepository 接口定义了以下功能：

• save 与 saveAll：存储对应的监控数据
• queryByAppAndResourceBetween：查询某段时间内的某个应用的某个资源的监控数据
• listResourcesOfApp：查询某个应用下的所有资源

实战

Sentinal使用Nacos数据源

maven依赖

      <dependency>
          <groupId>com.alibaba.csp</groupId>
          <artifactId>sentinel-datasource-nacos</artifactId>
      </dependency>

bootstrap.yaml

指定nacos数据源。

spring:
  cloud:
    sentinel:
#      transport:
#        dashboard: vm1:8080
#        ## 从8719依次+1扫描，直到找到未被占用端口为之
#        port: 8719
#        clientIp: 192.1.17.61
      datasource:
        ds1:
          nacos:
            server-addr: vm1:8848
            dataId: ${spring.application.name}-flow-rules
            groupId: DEFAULT_GROUP
            data-type: json
            rule-type: flow
        ds2:
          nacos:
            server-addr: vm1:8848
            dataId: ${spring.application.name}-degrade-rules
            groupId: DEFAULT_GROUP
            data-type: json
            rule-type: degrade

启动客户端

客户端启动时，会请求nacos的规则配置。 当nacos更新发布配置时，会主动通知客户端。

nacos配置流控规则

### sentinel-service-flow-rules
[
   {
      "controlBehavior" : "1",
      "count" : "3",
      "grade" : "1",
      "limitApp" : "default",
      "resource" : "/testA",
      "strategy" : "0"
   }
]


### sentinel-service-degrade-rules
[
   {
      "count" : "100",
      "grade" : "0",
      "resource" : "/testA",
      "timeWindow" : "20"
   }
]

不论采用什么配置中心，限流规则都只能通过Nacos界面完成修改才能得到持久化存储，而在Sentinel Dashboard中修改限流规则虽然可以生效，但是不会被持久化到配置中心。

Sentinel Dashboard中修改规则同步到Nacos

Sentinel 控制台（集群流控管理）

参考： Sentinel Dashboard中修改规则同步到Nacos