建筑设计院_灰色词seo推广_如何结合搜索检索与seo推广_营销助手

概述

Sentinel 是面向分布式、多语言异构化服务架构的流量治理组件，主要以流量为切入点，从流量路由、流量控制、流量整形、熔断降级、系统自适应过载保护、热点流量防护等多个维度来帮助开发者保障微服务的稳定性。

官网：https://github.com/alibaba/sentinel

https://sentinelguard.io/zh-cn/docs/introduction.html

Sentinel 主要特征：

快速开始

下载安装

下载地址：Release v1.8.6 · alibaba/Sentinel · GitHub

Sentinal 组件由两部分组成：

后台管理界面
前台 8080

启动命令：

java -jar sentinel-dashboard-1.8.6.jar

Sentinal 后台管理界面

用户名和密码都是：sentinal

上线服务

**注意：**Sentinel 需要 JDK 1.8 或更高版本。

<dependency><groupId>com.alibaba.csp</groupId><artifactId>sentinel-core</artifactId><version>1.8.6</version>
</dependency>

添加 yaml 文件

server:port: 8401spring:application:name: cloudalibaba-sentinel-servicecloud:nacos:discovery:# Nacos服务注册中心地址server-addr: 127.0.0.1:8848sentinel:transport:#配置Sentinel dashboard地址dashboard: 127.0.0.1:8080#默认8719端口，假如被占用会自动从8719开始依次+1扫描,直至找到未被占用的端口port: 8719management:endpoints:web:exposure:include: '*'

启动类

@EnableDiscoveryClient
@SpringBootApplication
public class MainApp8401 {public static void main(String[] args) {SpringApplication.run(MainApp8401.class, args);}
}

业务类

@RestController
public class FlowLimitController {@GetMapping("/testA")public String testA() {return "testA";}@GetMapping("/testB")public String testB() {return "testB";}
}

启动服务后，调用接口，在 sentienl 控制台中就有了接口流量监控。

至此 sentienl 已经监控到了 8401 的微服务了。

流控规则

任何系一个系统的运算、存储、网络资源都不是无限的，当系统资源不足不足以支撑外部超过预期的突发流量时，便应该有所取舍，建立面对超额流量自我保护的机制，这个机制就是微服务中常说的“限流”。

资源名：唯一名称，默认请求路径。
针对来源：Sentinel 可以针对调用者进行限流，填写微服务名，默认 default（不区分来源）
阈值类型
- QPS（每秒请求数）：当调用该 api 的 QPS 达到阈值，进行限流。
- 并发线程数：当调用该 api 的线程数达到阈值，进行限流。
是否集群：默认不需要集群。
流控模式
- 直接：api 达到限流条件时，直接限流。
- 关联：当关联的资源达到阈值时，就限流自己。（比如：自己是下单接口，当支付接口达到阈值时，限流下单接口）
- 链路：只记录指定链路上的流量（指定资源从入口资源进来的流量，如果达到阈值，就进行限流）【api 级别的针对来源】
流控效果
- 快速失败：直接失败，抛异常。
- Warm up（预热）：预热冷启动方式。当系统长期处于低水位的情况下，流量突增，直接会将系统拉升到高水位，可能瞬间把系统压垮。通过“预热”，让流量缓慢增加，在一定的时间内逐渐增加到阈值上限，给冷系统一个预热的时间。根据 codeFactor（冷加载因子，默认 3）的值，从阈值/ codeFactor，经过预热时长，才达到设置的 QPS 阈值。
- 排队等待：匀速排队，让请求以匀速通过，阈值类型必须设置为 QPS，否则无效。

直接

针对 testA 接口新增流控规则（系统默认：QPS、直接、快速失败）。

如果 testA 调用 QPS 大于 1，就会快速失败。

注意：QPS 与并发线程数的区别。

QPS 是站在请求端来看的，每秒的请求数量。

并发线程数是服务端并发使用线程数。如果处理很快，QPS 大于 1，但是使用同一个线程。

关联

当关联的资源达到阈值时，就限流自己。比如：A 是下单接口，B 是支付接口。当支付接口（B）达到阈值时（压力大了），限流下单接口（A）。

如图配置：当 testB 接口的 QPS 达到了 1，限流 testA 接口。

使用 Postman 模拟并发调用 testB 接口，让后看 testA 接口的限流情况。

在 Postman 执行期间，testA 接口被限流了。当 Postman 执行完毕后，testA 接口恢复正常。限流策略生效。

链路

Warm up（预热）

预热冷启动方式。当系统长期处于低水位的情况下，流量突增，直接会将系统拉升到高水位，可能瞬间把系统压垮。通过“预热”，让流量缓慢增加，在一定的时间内逐渐增加到阈值上限，给冷系统一个预热的时间。根据 codeFactor（冷加载因子，默认 3）的值，从阈值/ codeFactor，经过预热时长，才达到设置的 QPS 阈值。

如下图：接口 testA 的 QPS 大于 100 会触发限流。接口 testA 是新接口上线，刚开始 QPS 达到 100/3 就开始限流，在 5 秒内逐步从 100 /3 提升至 100 的 QPS。

排队等待

匀速排队，让请求以匀速通过，阈值类型必须设置为 QPS，否则无效。

这种方式严格控制了请求通过的间隔时间，也即是让请求以均匀的速度通过，对应的是漏桶算法。

这种方式主要用于处理间隔性突发的流量，例如消息队列。想象一下这样的场景，在某一秒有大量的请求到来，而接下来的几秒则处于空闲状态，我们希望系统能够在接下来的空闲期间逐渐处理这些请求，而不是在第一秒直接拒绝多余的请求。

下图设置含义：接口 testA 每秒处理 100 次请求，QPS 超过 100 就排队等待，等待的超时时间为 500 ms。

熔断规则

容错性设计（Design for Failure）是微服务的一个核心原则。由于某一个服务的崩溃，导致所有用到这个服务的其他服务都无法正常工作，一个点的错误经过层层传递，最终波及调用链上与此相关的所有服务，这便是雪崩效应。如何防止雪崩效应便是微服务架构容错性设计原则的具体实现。

要落实容错性设计这条原则，除了从思想观念上转变过来，正视程序必然是会出错的，并对它进行有计划的防御之外，还必须了解一些常用的容错策略和容错设计模式，作为具体设计与编码实践的指导。这里的容错策略指的是“面对故障，我们该做什么”。Sentinel 提供以下几种熔断策略。

慢调用比例 (SLOW_REQUEST_RATIO)：
- 最大 RT（最大的响应时间）：请求的响应时间大于该值则统计为慢调用
- 统计时长：当单位统计时长（statIntervalMs）内请求数目大于设置的最小请求数目，并且慢调用的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求响应时间小于设置的慢调用 RT 则结束熔断，若大于设置的慢调用 RT 则会再次被熔断。
异常比例 (ERROR_RATIO)：当单位统计时长（statIntervalMs）内请求数目大于设置的最小请求数目，并且异常的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求成功完成（没有错误）则结束熔断，否则会再次被熔断。异常比率的阈值范围是 [0.0, 1.0]，代表 0% - 100%。
异常数 (ERROR_COUNT)：当单位统计时长内的异常数目超过阈值之后会自动进行熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求成功完成（没有错误）则结束熔断，否则会再次被熔断。

注意：

以上熔断策略，在熔断期间让请求快速失败。
上述熔断策略，都有一个最小请求数目的设置，目的是当系统 QPS 不高时，如果发生了异常，其实对系统整体的稳定性影响不大，不需要熔断处理。

慢调用比例

异常比例

异常数

热点参数限流

何为热点？热点即经常访问的数据。很多时候我们希望统计某个热点数据中访问频次最高的 Top K 数据，并对其访问进行限制。比如：

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

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

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

实例

新增带参数据的方法

    @GetMapping("/testHotKey")// 热点参数限流,必须使用 SentinelResource，资源名必须是 value@SentinelResource(value = "testHotKey")public String testHotKey(@RequestParam(value = "p1", required = false) String p1,@RequestParam(value = "p2", required = false) String p2) {return "testHotKey";}

新增热点规则：testHotKey 接口：

参数索引：对第 0 个参数（P1）进行热度限流。
单机阈值：QPS 阈值

如果不设置限量后的结果就会抛异常，异常打到前台用户界面，不友好。

自定义限流后的处理结果。

    @GetMapping("/testHotKey")@SentinelResource(value = "testHotKey", blockHandler = "deal_testHotKey")public String testHotKey(@RequestParam(value = "p1", required = false) String p1,@RequestParam(value = "p2", required = false) String p2) {return "testHotKey";}public String deal_testHotKey(String p1, String p2, BlockException ex) {return "deal_testHotKey";}

参数例外项

参数例外项：可以针对指定的参数值单独设置限流阈值，不受前面 count 阈值的限制。仅支持基本类型和字符串类型

如下图：

正常情况下：p1 相同参数 QPS > 1 会进行限流。
特例：当 p1 == “vip” 时，QPS > 200 才会限流。

系统自适应保护

Sentinel 系统自适应保护从整体维度对应用入口流量进行控制，结合应用的 Load、总体平均 RT、入口 QPS 和线程数等几个维度的监控指标，让系统的入口流量和系统的负载达到一个平衡，让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。

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

@SentinelResource

@SentinelResource 用于定义资源，并提供可选的异常处理和 fallback 配置项。 @SentinelResource 注解包含以下属性：

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

实例

创建 CustomerBlockHandler 类用于自定义限流处理逻辑。项目中所有的限流兜底逻辑都写在这个类里。

public class CustomerBlockHandler {public static CommonResult hanlderException(BlockException exception) {return new CommonResult<>(444, "自定义错误信息 global handlerException", "1");}public static CommonResult hanlderException2(BlockException exception) {return new CommonResult<>(444, "自定义错误信息 global handlerException", "2");}
}import lombok.Data;@Data
public class CommonResult<T> {private int code;private String message;private T data;public CommonResult(int code, String message, T data) {this.code = code;this.message = message;this.data = data;}
}

通过：blockHandlerClass 参数找到限流兜底的类

通过：blockHandler 参数找到限流兜底的类中的方法。

    @GetMapping("/testCustomer")@SentinelResource(value = "testCustomer",blockHandlerClass = CustomerBlockHandler.class,blockHandler = "hanlderException2")public CommonResult<String> deal_testHotKey(String p1, String p2, BlockException ex) {return new CommonResult<>(200, "testCustomer success", "0");}

持久化

一旦重启应用，sentienl 规则就丢失了，生产环境需要将配置进行持久化。

方案：将限流规则持久化到 Nacos 中。

新增 mvn 依赖

        <!--SpringCloud ailibaba sentinel-datasource-nacos 后续做持久化用到--><dependency><groupId>com.alibaba.csp</groupId><artifactId>sentinel-datasource-nacos</artifactId></dependency>

新增 yml 配置

server:port: 8401spring:application:name: cloudalibaba-sentinel-servicecloud:nacos:discovery:#Nacos服务注册中心地址server-addr: 127.0.0.1:8848sentinel:transport:#配置Sentinel dashboard地址dashboard: 127.0.0.1:8080#默认8719端口，假如被占用会自动从8719开始依次+1扫描,直至找到未被占用的端口port: 8719datasource:ds1:nacos:server-addr: 127.0.0.1:8848dataId: cloudalibaba-sentinel-servicegroupId: DEFAULT_GROUPdata-type: jsonrule-type: flow
management:endpoints:web:exposure:include: '*'

手动在 Nacos 中添加接口限流信息

流量控制规则：

resource：资源名称；
limitApp：来源应用；
grade：阈值类型，0表示线程数，1表示QPS；
count：单机阈值；
strategy：流控模式，0表示直接，1表示关联，2表示链路；
controlBehavior：流控效果，0表示快速失败，1表示Warm Up，2表示排队等待；
clusterMode：是否集群。

熔断降级规则：

resource ：资源名，资源名是限流规则的作用对象，比如请求资源 getUser 。
grade ：熔断策略，支持慢调用比例/异常比例/异常数策略。1：慢调用比例，2：异常比例，3：异常数。默认为1，慢调用比例。
count ：慢调用比例模式下为慢调用临界 RT（超出该值计为慢调用）；异常比例/异常数模式下为对应的阈值。
timeWindow ：熔断时长，单位为秒。
minRequestAmount：熔断触发的最小请求数，请求数小于该值时即使异常比率超出阈值也不会熔断。默认为 5 。
statIntervalMs ：统计时长（单位为 ms），如 60*1000 代表分钟级。默认为 1000 ms。
slowRatioThreshold：慢调用比例阈值，仅慢调用比例模式有效

之后再重启服务：流控规则中已经用了 Nacos 中添加的流控规则。

注意：此时数据只能从 Nacos 单向 Sentinel 推送，不能从 Sentinel 向 Nacos 推送。

热点规则

[{// 资源名"resource": "/test1",// 限流模式（QPS 模式，不可更改）"grade": 1,// 参数索引"paramIdx": 0,// 单机阈值"count": 13,// 统计窗口时长"durationInSec": 6,// 是否集群 默认false"clusterMode": 默认false,// "burstCount": 0,// 集群模式配置"clusterConfig": {// "fallbackToLocalWhenFail": true,// "flowId": 2,// "sampleCount": 10,// "thresholdType": 0,// "windowIntervalMs": 1000},// 流控效果（支持快速失败和匀速排队模式）"controlBehavior": 0,// "limitApp": "default",// "maxQueueingTimeMs": 0,// 高级选项"paramFlowItemList": [{// 参数类型"classType": "int",// 限流阈值"count": 222,// 参数值"object": "2"}]}
]

系统规则

[{// RT"avgRt": 1,// CPU 使用率"highestCpuUsage": -1,// LOAD"highestSystemLoad": -1,// 线程数"maxThread": -1,// 入口 QPS"qps": -1}
]

授权规则

[{// 资源名"resource": "sentinel_spring_web_context",// 流控应用"limitApp": "/test",// 授权类型(0代表白名单；1代表黑名单。)"strategy": 0}
]

双向推送

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

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

规则管理及推送

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

原始模式

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

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

Pull 模式

pull 模式的数据源（如本地文件、RDBMS 等）一般是可写入的。使用时需要在客户端注册数据源：将对应的读数据源注册至对应的 RuleManager，将写数据源注册至 transport 的 WritableDataSourceRegistry 中。以本地文件数据源为例：

public class FileDataSourceInit implements InitFunc {@Overridepublic void init() throws Exception {String flowRulePath = "xxx";ReadableDataSource<String, List<FlowRule>> ds = new FileRefreshableDataSource<>(flowRulePath, source -> JSON.parseObject(source, new TypeReference<List<FlowRule>>() {}));// 将可读数据源注册至 FlowRuleManager.FlowRuleManager.register2Property(ds.getProperty());WritableDataSource<List<FlowRule>> wds = new FileWritableDataSource<>(flowRulePath, this::encodeJson);// 将可写数据源注册至 transport 模块的 WritableDataSourceRegistry 中.// 这样收到控制台推送的规则时，Sentinel 会先更新到内存，然后将规则写入到文件中.WritableDataSourceRegistry.registerFlowDataSource(wds);}private <T> String encodeJson(T t) {return JSON.toJSONString(t);}
}

本地文件数据源会定时轮询文件的变更，读取规则。这样我们既可以在应用本地直接修改文件来更新规则，也可以通过 Sentinel 控制台推送规则。以本地文件数据源为例，推送过程如下图所示：

首先 Sentinel 控制台通过 API 将规则推送至客户端并更新到内存中，接着注册的写数据源会将新的规则保存到本地的文件中。使用 pull 模式的数据源时一般不需要对 Sentinel 控制台进行改造。

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

Push 模式

生产环境下一般更常用的是 push 模式的数据源。对于 push 模式的数据源,如远程配置中心（ZooKeeper, Nacos, Apollo等等），推送的操作不应由 Sentinel 客户端进行，而应该经控制台统一进行管理，直接进行推送，数据源仅负责获取配置中心推送的配置并更新到本地。因此推送规则正确做法应该是 配置中心控制台/Sentinel 控制台 → 配置中心 → Sentinel 数据源 → Sentinel，而不是经 Sentinel 数据源推送至配置中心。这样的流程就非常清晰了：

从 Sentinel 1.4.0 开始，Sentinel 控制台提供 DynamicRulePublisher 和 DynamicRuleProvider 接口用于实现应用维度的规则推送和拉取，并提供了相关的示例。Sentinel 提供应用维度规则推送的示例页面（/v2/flow），用户改造控制台对接配置中心后可直接通过 v2 页面推送规则至配置中心。改造详情可参考应用维度规则推送示例。

改造 Sentinel Dashbord

下载 sentinel 源码，导入 idea 工程。主要改造 sentinel-dashbord 模块。

git clone https://github.com/alibaba/Sentinel.git

在 pom.xml 文件中去掉 test scope 注释

 <!-- for Nacos rule publisher sample --><dependency><groupId>com.alibaba.csp</groupId><artifactId>sentinel-datasource-nacos</artifactId><!--<scope>test</scope>--></dependency>

修改前端路由配置（sidebar.html）

  <!--<li ui-sref-active="active" ng-if="!entry.isGateway"><a ui-sref="dashboard.flowV1({app: entry.app})"><i class="glyphicon glyphicon-filter"></i>&nbsp;&nbsp;流控规则</a></li>--><!-- 修改为flow，直接调用FlowControllerV2 --><li ui-sref-active="active" ng-if="!entry.isGateway"><a ui-sref="dashboard.flow({app: entry.app})"><i class="glyphicon glyphicon-filter"></i>&nbsp;&nbsp;流控规则</a></li>

这样就可以通过js跳转至FlowControllerV2了

      .state('dashboard.flow', {templateUrl: 'app/views/flow_v2.html',url: '/v2/flow/:app',controller: 'FlowControllerV2',resolve: {loadMyFiles: ['$ocLazyLoad', function ($ocLazyLoad) {return $ocLazyLoad.load({name: 'sentinelDashboardApp',files: ['app/scripts/controllers/flow_v2.js',]});}]}})

将（com.alibaba.csp.sentinel.dashboard.test.rule.nacos）复制到 com.alibaba.csp.sentinel.dashboard.rule.nacos 目录下，即去掉 test 目录，这样是以内源码中 Nacos 等持久化的配置都是在 test 中，打包 jar 的时候并不会打包进去，所以需要 copy 到主源码目录下。

创建读取nacos配置的NacosPropertiesConfiguration文件并且application.properties指定配置

import org.springframework.boot.context.properties.ConfigurationProperties;@ConfigurationProperties(prefix = "sentinel.nacos")
public class NacosPropertiesConfiguration {private String serverAddr;private String dataId;private String groupId = "SENTINEL_GROUP"; // 默认分组private String namespace;private String username;private String password;// 省略 getter/setter  
}

然后配置sentinel-dashboar/resources/application.properties中配置nacos配置，以为sentinel.nacos为前缀：

sentinel.nacos.serverAddr=192.168.3.104:8848
sentinel.nacos.namespace=7bdf4616-b415-4221-a381-e1542e75af53
sentinel.nacos.group-id=SENTINEL-GROUP
sentinel.nacos.username=nacos
sentinel.nacos.password=nacos

改造NacosConfig，创建NacosConfigService

    @Beanpublic ConfigService nacosConfigService(NacosPropertiesConfiguration nacosPropertiesConfiguration) throws Exception {Properties properties = new Properties();properties.put(PropertyKeyConst.SERVER_ADDR, nacosPropertiesConfiguration.getServerAddr());properties.put(PropertyKeyConst.NAMESPACE, nacosPropertiesConfiguration.getNamespace());properties.put(PropertyKeyConst.USERNAME, nacosPropertiesConfiguration.getUsername());properties.put(PropertyKeyConst.PASSWORD, nacosPropertiesConfiguration.getPassword());return ConfigFactory.createConfigService(properties);
//        return ConfigFactory.createConfigService("localhost");}

NacosConfig主要做两件事：

注入 Convert 转换器，将 FlowRuleEntity 转化成 FlowRule，以及反向转化
注入 Nacos 配置服务 ConfigService

修改FlowControllerV2 类，使用 @Qulifier 将上面配置的两个类注入进来

@RestController
@RequestMapping(value = "/v2/flow")
public class FlowControllerV2 {private final Logger logger = LoggerFactory.getLogger(FlowControllerV2.class);@Autowiredprivate InMemoryRuleRepositoryAdapter<FlowRuleEntity> repository;/*@Autowired@Qualifier("flowRuleDefaultProvider")private DynamicRuleProvider<List<FlowRuleEntity>> ruleProvider;@Autowired@Qualifier("flowRuleDefaultPublisher")private DynamicRulePublisher<List<FlowRuleEntity>> rulePublisher;*//*** 修改默认publisher/provider为Nacos* 使用@Qualifier指定bean*/@Autowired@Qualifier("flowRuleNacosProvider")private DynamicRuleProvider<List<FlowRuleEntity>> ruleProvider;@Autowired@Qualifier("flowRuleNacosPublisher")private DynamicRulePublisher<List<FlowRuleEntity>> rulePublisher;// 省略      
}

对 sentinel-dashboard 重新打包

mvn clean package -pl .,sentinel-dashboard -am

启动 sentinel
```
java -Dserver.port=6005 -Dcsp.sentinel.dashboard.server=localhost:6006 -Dproject.name=sentinel-dashboard -Dcsp.sentinel.api.port=6007 -jar sentinel-dashboard.jar
```
- Dserver.port=6005 控制台端口，sentinel控制台是一个spring boot程序。客户端配置文件需要填对应的配置，如：spring.cloud.sentinel.transport.dashboard=192.168.1.102:8718
- Dcsp.sentinel.dashboard.server=localhost:6007 控制台的地址，指定控制台后客户端会自动向该地址发送心跳
- Dproject.name=sentinel-dashboard 指定Sentinel控制台程序的名称
- Dcsp.sentinel.api.port=8719 可选项，客户端提供给Dashboard访问或者查看Sentinel的运行访问的参数，默认8719

编写 Sentinel 客户端

bootstrap.properties中配置Nacos Config Server

spring.cloud.nacos.config.server-addr=192.168.3.104:8848

application.properties配置sentinel dashboard datasource

server.port=8401
spring.application.name=cloudalibaba-sentinel-service
management.endpoints.web.exposure.include=*
spring.cloud.nacos.discovery.server-addr=192.168.3.104:8848
spring.cloud.sentinel.transport.dashboard=192.168.3.104:6005
#指定csp.sentinel.api.port时需要配置，否则默认8719
#spring.cloud.sentinel.transport.port=6007# sentinel nacos配置
spring.cloud.sentinel.datasource.flow.nacos.server-addr=192.168.3.104:8848
spring.cloud.sentinel.datasource.flow.nacos.data-id=${spring.application.name}-flow-rules
spring.cloud.sentinel.datasource.flow.nacos.group-id=SENTINEL_GROUP
spring.cloud.sentinel.datasource.flow.nacos.namespace=7bdf4616-b415-4221-a381-e1542e75af53
spring.cloud.sentinel.datasource.flow.nacos.data-type=json
spring.cloud.sentinel.datasource.flow.nacos.rule-type=flow

联调测试

启动 Nacos
启动 sentienl 客户端

在 sentinel-dashboard 上配置限量数据已经 push 到 Nacos 中了。

上线服务重启后，接口依然可以限量

注意：sentinel-dashboard 界面上有很多添加流控的入口，都需要改为调用 FlowControllerV2。

参考文档：

https://www.cnblogs.com/jian0110/p/14139044.html
https://github.com/alibaba/Sentinel/wiki/%E5%9C%A8%E7%94%9F%E4%BA%A7%E7%8E%AF%E5%A2%83%E4%B8%AD%E4%BD%BF%E7%94%A8-Sentinel
https://sentinelguard.io/zh-cn/docs/annotation-support.html