文章目录

• 前言
• 一 初识Sentinel
• • 1.1 雪崩问题
  • 1.2 解决方法
  • 1.3 小结
  • 1.4 服务保护技术对比
  • 1.5 Sentinel介绍
  • 1.6 Sentinel安装
  • 1.7 微服务整合Sentinel
• 二 测试工具：Jmeter
• • 2.1 Jmeter安装和配置
  • 2.2 Jmeter快速入门
  • • 2.2.1 设置中文语言
    • 2.2.2 设置Jmeter桌面快捷图标
  • 2.3 Jmeter无法保存测试的问题
  • 2.4 jmeter基本用法
• 三 流量控制
• • 3.1 簇点链路
  • 3.2 快速入门
  • 3.3 流控模式
  • 3.4 链路模式
  • 3.5 流控效果
  • • 3.5.1 warm up
    • 3.5.2 排队等待
  • 3.6 热点参数限流
  • • 3.6.1 全局参数限流
    • 3.6.2 热点参数限流
• 四 隔离和降级
• • 4.1 FeignClient整合Sentinel
  • • 4.1.1 修改配置，开启sentinel功能
    • 4.1.2 编写失败降级逻辑
    • 4.1.3 总结
  • 4.2 线程隔离（舱壁模式）
  • • 4.2.1 线程隔离的实现方式
    • 4.2.2 sentinel的线程隔离
  • 4.3 熔断降级
  • • 4.3.1 慢调用
    • 4.3.2 异常比例、异常数
• 五 授权规则
• • 5.1 授权规则
  • 5.2 自定义异常结果
  • 5.3 自定义异常处理
• 六 规则持久化
• • 6.1 规则管理模式
  • 6.2 pull模式
  • 6.3 push模式
  • 6.4 实现push模式
  • • 6.4.1下载和解压Sentinel源码
    • 6.4.2 修改nacos依赖
    • 6.4.3 添加nacos支持
    • 6.4.4 配置nacos数据源
    • 6.4.5 修改前端页面
    • 6.4.6 重新编译、打包项目
    • 6.4.7 启动

前言

• 本文是学习自黑马程序员，大部分的内容来自微服务课程！！！
• 本文的意义在于学习记录，虽然黑马的学习文档很详细，但是由于课程不可能是时时最新，所以学习使用的工具、内容等版本有一定的差异！！
• 本文，是立足于黑马的教程，对后来的学习者，对其中的细节问题，进行记录和补充！！！
• 文章有不足之处，感谢大家的指正！！！
• 文章后半部分，有关实际操作的部分，小编不再赘述！！！对于操作部分，一定要亲自动手！！！

一 初识Sentinel

1.1 雪崩问题

• 微服务中，服务间调用关系错综复杂，一个微服务往往依赖于多个其它微服务
  

• 如图，如果服务提供者I发生了故障，当前的应用的部分业务因为依赖于服务I，因此也会被阻塞。此时，其它不依赖于服务I的业务似乎不受影响。
  

• 但是，依赖服务I的业务请求被阻塞，用户不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞：
  

• 服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，那么当前服务也就不可用了。那么，依赖于当前服务的其它服务随着时间的推移，最终也都会变的不可用，形成级联失败，雪崩就发生了

• 微服务调用链路中的某个服务故障，引起整个链路中的所有微服务都不可用，这就是雪崩。
  

1.2 解决方法

• 解决雪崩问题的常见方式有四种：
  • 超时处理：设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待
  • 舱壁模式：限定每个业务能使用的线程数，避免耗尽整个tomcat的资源，因此也叫线程隔离。
  • 熔断降级：由断路器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求。
  • 流量控制：限制业务访问的QPS，避免服务因流量的突增而故障。

1. 超时处理
   • 设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待
     

2. 仓壁模式
   • 仓壁模式来源于船舱的设计：船舱都会被隔板分离为多个独立空间，当船体破损时，只会导致部分空间进入，将故障控制在一定范围内，避免整个船体都被淹没。
   • 限定每个业务能使用的线程数，避免耗尽整个tomcat的资源，因此也叫线程隔离。
     

3. 断路器
   • 由断路器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求。
   • 断路器会统计访问某个服务的请求数量，异常比例，当发现访问服务D的请求异常比例过高时，认为服务D有导致雪崩的风险，会拦截访问服务D的一切请求，形成熔断。
     

4. 流量控制
   • 限制业务访问的QPS，避免服务因流量的突增而故障。
     

1.3 小结

• 雪崩问题：微服务之间相互调用，因为调用链中的一个服务故障，引起整个链路都无法访问的情况。
• 限流是对服务的保护，避免因瞬间高并发流量而导致服务故障，进而避免雪崩。是一种预防措施。
• 超时处理、线程隔离、降级熔断是在部分服务故障时，将故障控制在一定范围，避免雪崩。是一种补救措施。

1.4 服务保护技术对比

在SpringCloud当中支持多种服务保护技术：

• Netfix Hystrix
• Sentinel
• Resilience4J

早期比较流行的是Hystrix框架，但目前国内实用最广泛的还是阿里巴巴的Sentinel框架，这里我们做下对比：

1.5 Sentinel介绍

• Sentinel是阿里巴巴开源的一款微服务流量控制组件。官网地址
• Sentinel 具有以下特征:
  •丰富的应用场景：Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。
  •完备的实时监控：Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。
  •广泛的开源生态：Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。
  •完善的 SPI 扩展点：Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。

1.6 Sentinel安装

1. sentinel版本的选择：
   • 如果你使用的JDK是1.8，那么完全可以使用资料中的jar包
   • 如果你的JDK较新，请到GitHub下载，最新版！！！
2. 运行
   • 将jar包放到任意非中文目录，执行命令：

   java -jar sentinel-dashboard-x.x.x.jar

   • 如果要修改Sentinel的默认端口、账户、密码，可以通过下列配置：

• 例如，修改端口：

  java -Dserver.port=8090 -jar sentinel-dashboard-x.x.x.jar

3. 访问
   • 访问http://localhost:8080页面，就可以看到sentinel的控制台
   • 需要输入账号和密码，默认都是：sentinel
     
   • 登录后，发现一片空白，什么都没有：因为还没有与微服务整合
     

1.7 微服务整合Sentinel

• 在微服务项目中整合sentinel，并连接sentinel的控制台，步骤如下：

1. 引入sentinel依赖

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

2. 配置控制台
   • 修改application.yaml文件，添加下面内容

   server:port: 8088spring:cloud: sentinel:transport:dashboard: localhost:8080 #连接到sentinel 如果你的sentinel是在linux中启动的，请修改为linux的IP

3. 访问微服务项目的任意端点
   • 打开浏览器，访问http://localhost:8088/order/101，这样才能触发sentinel的监控。
   • 然后再访问sentinel的控制台，查看效果
     

• 后续测试，使用的测试工具是Jmeter，所以接下来学习以下Jmeter的安装和使用

二 测试工具：Jmeter

• Jmeter依赖于JDK，所以必须确保当前计算机上已经安装了JDK，并且配置了环境变量

2.1 Jmeter安装和配置

1. 可以Apache Jmeter官网下载，地址
   
2. 解压
   
   • bin目录就是执行的脚本，其中包含启动脚本：
3. 双击即可运行，但是有两点注意：
   • 启动速度比较慢，要耐心等待
   • 启动后黑窗口不能关闭，否则Jmeter也跟着关闭了
     

2.2 Jmeter快速入门

2.2.1 设置中文语言

- 方式一：永久中文，打开jmeter文件夹，在bin目录中找到 **jmeter.properties**，添加下面配置：- **注意：前面不要出现#，#代表注释，另外这里是下划线，不是中划线**

– 方式二：暂时设置，在图形化界面中选择Potions->Choose Language->English

2.2.2 设置Jmeter桌面快捷图标

1. 为jmeter文件的bin目录—>jmeter.bat文件，右键创建桌面快捷方式
   
2. 修改快捷方式的属性
   
3. 制作jmeter快捷方式的图标
   • 进入到apache-jmeter-5.5\docs\images目录，选一张合适的图标，然后打开在线生成透明ICO图标网站
   • 上传图片，制作ico图标，然后将其放入到apache-jmeter-5.5\docs\images目录
   • 最后右键桌面的快捷方式，修改属性->更改图标->浏览apache-jmeter-5.5\docs\images目录选择ico图标文件即可
     

2.3 Jmeter无法保存测试的问题

1. 在jmeter5.4.1中设置外观为window,重启即可解决
2. 在最新的jmeter5.5中则无此问题，建议大家尝试最新版
   • 可以在默认Darcula样式下，正常保存测试计划
     

2.4 jmeter基本用法

• 在测试计划上点鼠标右键，选择添加 > 线程（用户） > 线程组：
  
• 在新增的线程组中，填写线程信息：
  
• 给线程组点鼠标右键，添加http取样器：
  
• 编写取样器内容：
  
• 添加监听报告：
  
• 添加监听结果树：
  
• 汇总报告结果：
  
• 结果树结果
  

三 流量控制

3.1 簇点链路

• 当请求进入微服务时，首先会访问DispatcherServlet，然后进入Controller、Service、Mapper，这样的一个调用链就叫做簇点链路。簇点链路中被监控的每一个接口就是一个资源。
• 默认情况下sentinel会监控SpringMVC的每一个端点（Endpoint，也就是controller中的方法），因此SpringMVC的每一个端点（Endpoint）就是调用链路中的一个资源。
  • 如：刚才访问的order-service中的OrderController中的端点：/order/{orderId}
    
• 流控、熔断等都是针对簇点链路中的资源来设置的，因此我们可以点击对应资源后面的按钮来设置规则：
  • 流控：流量控制
  • 降级：降级熔断
  • 热点：热点参数限流，是限流的一种
  • 授权：请求的权限控制

3.2 快速入门

1. 点击资源/order/{orderId}后面的流控按钮，就可以弹出表单
   
2. 表单中可以填写限流规则
   
3. 利用jmeter测试
   
   

• 注意：不要点击菜单中的执行按钮来运行

4. 执行结果
   

3.3 流控模式

• 在添加限流规则时，点击高级选项，可以选择三种流控模式：
  • 直接：统计当前资源的请求，触发阈值时对当前资源直接限流，也是默认的模式
  • 关联：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流
  • 链路：统计从指定链路访问到本资源的请求，触发阈值时，对指定链路限流

• 需求说明：
  • 在OrderController新建两个端点：/order/query和/order/update，无需实现业务
  • 配置流控规则，当/order/ update资源被访问的QPS超过5时，对/order/query请求限流

• 注意，重启服务之后，记得访问一次之后，sentinel才可以显示簇点链路
  
  

• 重启服务，查看sentinel控制台的簇点链路：
  
• 配置流控规则
  
  
• 在Jmeter测试
  
  • 1000个用户，100秒，因此QPS为10，超过了我们设定的阈值：5
  • 查看http请求：
    
• 请求的目标是/order/update，这样这个断点就会触发阈但限流的目标是/order/query
  
• 满足下面条件可以使用关联模式:
  • 两个有竞争关系的资源
  • 一个优先级较高，一个优先级较低

3.4 链路模式

• 链路模式：只针对从指定链路访问到本资源的请求做统计，判断是否超过阈值。

1. 如：设置两个链路访问相同的资源
   
2. 添加流控规则
   
3. Jmeter测试
   
   • 一个http请求是访问/order/save：
     
   • 运行的结果：完全不受影响
     
   • 另一个是访问/order/query：
     
   • 运行结果：每次只有2个通过
     

3.5 流控效果

• 流控效果是指请求达到流控阈值时应该采取的措施，包括三种：
  • 快速失败：达到阈值后，新的请求会被立即拒绝并抛出FlowException异常。是默认的处理方式。
  • warm up：预热模式，对超出阈值的请求同样是拒绝并抛出异常。但这种模式阈值会动态变化，从一个较小值逐渐增加到最大阈值。
  • 排队等待：让所有的请求按照先后次序排队执行，两个请求的间隔不能小于指定时长

3.5.1 warm up

• 阈值一般是一个微服务能承担的最大QPS，但是一个服务刚刚启动时，一切资源尚未初始化（冷启动），如果直接将QPS跑到最大值，可能导致服务瞬间宕机。
• warm up也叫预热模式，是应对服务冷启动的一种方案。请求阈值初始值是 maxThreshold / coldFactor，持续指定时长后，逐渐提高到maxThreshold值。而coldFactor的默认值是3.
• 例如，我设置QPS的maxThreshold为10，预热时间为5秒，那么初始阈值就是 10 / 3 ，也就是3，然后在5秒后逐渐增长到10.
  
• 配置流控规则
  
• Jmeter测试
  
• Sentinel控制台查看实时监控：
  

3.5.2 排队等待

• 排队等待则是让所有请求进入一个队列中，然后按照阈值允许的时间间隔依次执行。后来的请求必须等待前面执行完成，如果请求预期的等待时间超出最大时长，则会被拒绝。
• 工作原理
  • 例如：QPS = 5，意味着每200ms处理一个队列中的请求；timeout = 2000，意味着预期等待时长超过2000ms的请求会被拒绝并抛出异常。
  • 那什么叫做预期等待时长呢？比如现在一下子来了12 个请求，因为每200ms执行一个请求，那么：
    • 第6个请求的预期等待时长 = 200 * （6 – 1） = 1000ms
    • 第12个请求的预期等待时长 = 200 * （12-1） = 2200ms
• 现在，第1秒同时接收到10个请求，但第2秒只有1个请求，此时QPS的曲线这样的：
  
• 如果使用队列模式做流控，所有进入的请求都要排队，以固定的200ms的间隔执行，QPS会变的很平滑：
  
• 动图解释：
  
• 添加流控规则
  
• Jmeter测试测试结果
  
  • QPS非常平滑，一致保持在10，但是超出的请求没有被拒绝，而是放入队列。因此响应时间（等待时间）会越来越长。当队列满了以后，才会有部分请求失败。

3.6 热点参数限流

• 热点参数限流是分别统计参数值相同的请求，判断是否超过QPS阈值。

3.6.1 全局参数限流

• 访问/goods/{id}的请求中，id参数值会有变化，热点参数限流会根据参数值分别统计QPS，统计结果：当id=1的请求触发阈值被限流时，id值不为1的请求不受影响。
  
• 配置示例：
  • 对hot这个资源的0号参数（第一个参数）做统计，每1秒相同参数值的请求数不能超过5
    

3.6.2 热点参数限流

• 在实际开发中，可能部分商品是热点商品，例如秒杀商品，我们希望这部分商品的QPS限制与其它商品不一样，高一些。那就需要配置热点参数限流的高级选项
  

四 隔离和降级

• 限流是一种预防措施，虽然限流可以尽量避免因高并发而引起的服务故障，但服务还会因为其它原因而故障。而要将这些故障控制在一定范围，避免雪崩，就要靠线程隔离（舱壁模式）和熔断降级

• 线程隔离：调用者在调用服务提供者时，给每个调用的请求分配独立线程池，出现故障时，最多消耗这个线程池内资源，避免把调用者的所有资源耗尽。
  

• 熔断降级：是在调用方这边加入断路器，统计对服务提供者的调用，如果调用的失败比例过高，则熔断该业务，不允许访问该服务的提供者
  

• 不管是线程隔离还是熔断降级，都是对客户端（调用方）的保护。需要在调用方 发起远程调用时做线程隔离、或者服务熔断。

• 而我们的微服务远程调用都是基于Feign来完成的，因此我们需要将Feign与Sentinel整合，在Feign里面实现线程隔离和服务熔断。

4.1 FeignClient整合Sentinel

• SpringCloud中，微服务调用都是通过Feign来实现的，因此做客户端保护必须整合Feign和Sentinel。

4.1.1 修改配置，开启sentinel功能

• 修改OrderService的application.yml文件，开启Feign的Sentinel功能：

  feign:sentinel:enabled: true # 开启feign对sentinel的支持

4.1.2 编写失败降级逻辑

• 业务失败后，不能直接报错，而应该返回用户一个友好提示或者默认结果，这个就是失败降级逻辑。
• 给FeignClient编写失败后的降级逻辑
  ①方式一：FallbackClass，无法对远程调用的异常做处理
  ②方式二：FallbackFactory，可以对远程调用的异常做处理【采用】

• 这里演示方式二的失败降级处理。

• 步骤一：在feing-api项目中定义类，实现FallbackFactory：

  • 代码：

  @Slf4jpublic class UserClientFallbackFactory implements FallbackFactory<UserClient> {@Overridepublic UserClient create(Throwable throwable) {return new UserClient() {@Overridepublic User findById(Long id) {log.error("查询用户异常", throwable);return new User();}};}}

• 步骤二：在feing-api项目中的DefaultFeignConfiguration类中将UserClientFallbackFactory注册为一个Bean：

  @Beanpublic UserClientFallbackFactory userClientFallbackFactory(){return new UserClientFallbackFactory();}

• 步骤三：在feing-api项目中的UserClient接口中使用UserClientFallbackFactory：

  @FeignClient(value = "userservice", fallbackFactory = UserClientFallbackFactory.class)public interface UserClient {@GetMapping("/user/{id}")User findById(@PathVariable("id") Long id);}

• 重启后，访问一次订单查询业务，然后查看sentinel控制台，可以看到新的簇点链路：
  

4.1.3 总结

• Sentinel支持的雪崩解决方案：

  • 线程隔离（仓壁模式）
  • 降级熔断

• Feign整合Sentinel的步骤：

  • 在application.yml中配置：feign.sentienl.enable=true
  • 给FeignClient编写FallbackFactory并注册为Bean
  • 将FallbackFactory配置到FeignClient

4.2 线程隔离（舱壁模式）

4.2.1 线程隔离的实现方式

• 线程隔离有两种方式实现：
  • 线程池隔离
  • 信号量隔离（Sentinel默认采用）
    
• 线程池隔离：给每个服务调用业务分配一个线程池，利用线程池本身实现隔离效果
• 信号量隔离：不创建线程池，而是计数器模式，记录业务使用的线程数量，达到信号量上限时，禁止新的请求。
• 两者的优缺点：
  

4.2.2 sentinel的线程隔离

• 在添加限流规则时，可以选择两种阈值类型：
  
• QPS：就是每秒的请求数
• 线程数：该资源能使用用的tomcat线程数的最大值。也就是通过限制线程数量，实现线程隔离（舱壁模式）

4.3 熔断降级

• 熔断降级是解决雪崩问题的重要手段。其思路是由断路器统计服务调用的异常比例、慢请求比例，如果超出阈值则会熔断该服务。即拦截访问该服务的一切请求；而当服务恢复时，断路器会放行访问该服务的请求。

• 下面演示断路器的执行图：
  
  状态机包括三个状态：

• closed：关闭状态，断路器放行所有请求，并开始统计异常比例、慢请求比例。超过阈值则切换到open状态

• open：打开状态，服务调用被熔断，访问被熔断服务的请求会被拒绝，快速失败，直接走降级逻辑。Open状态5秒后会进入half-open状态

• half-open：半开状态，放行一次请求，根据执行结果来判断接下来的操作。
  – 请求成功：则切换到closed状态
  – 请求失败：则切换到open状态

• 断路器熔断策略有三种：慢调用、异常比例、异常数

4.3.1 慢调用

• 慢调用：业务的响应时长（RT）大于指定时长的请求认定为慢调用请求。在指定时间内，如果请求数量超过设定的最小数量，慢调用比例大于设定的阈值，则触发熔断。
• 演示
  
  • 慢调用的RT阈值为50ms，统计时间为1秒，最小请求数量为5，失败阈值比例为0.4，熔断时长为5。超过50ms的请求都会被认为是慢请求。

4.3.2 异常比例、异常数

• 异常比例或异常数：统计指定时间内的调用，如果调用次数超过指定请求数，并且出现异常的比例达到设定的比例阈值（或超过指定异常数），则触发熔断。
• 例如，一个异常比例设置：
  
  • 解读：统计最近1000ms内的请求，如果请求量超过10次，并且异常比例不低于0.4，则触发熔断。
• 一个异常数设置：
  
  • 解读：统计最近1000ms内的请求，如果请求量超过10次，并且异常比例不低于2次，则触发熔断。

五 授权规则

• 授权规则可以对请求方来源做判断和控制。

5.1 授权规则

• 授权规则可以对调用方的来源做控制，有白名单和黑名单两种方式。

  • 白名单：来源（origin）在白名单内的调用者允许访问
  • 黑名单：来源（origin）在黑名单内的调用者不允许访问
    
  • 资源名：就是受保护的资源，例如/order/{orderId}
  • 流控应用：是来源者的名单，
    • 如果是勾选白名单，则名单中的来源被许可访问。
    • 如果是勾选黑名单，则名单中的来源被禁止访问。

• 演示：【有关微服务操作略过】
  

  • 只允许网关访问服务
    
  • 直接访问出错
    
  • 通过网关访问：
    

5.2 自定义异常结果

• 默认情况下，发生限流、降级、授权拦截时，都会抛出异常到调用方。异常结果都是flow limmiting（限流）。这样不够友好，无法得知是限流还是降级还是授权拦截。

1. 异常类型
   • 如果要自定义异常时的返回结果，需要实现BlockExceptionHandler接口：

   public interface BlockExceptionHandler {/** * 处理请求被限流、降级、授权拦截时抛出的异常：BlockException */void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception;}

   • 这个方法有三个参数：
     • HttpServletRequest request：request对象
     • HttpServletResponse response：response对象
     • BlockException e：被sentinel拦截时抛出的异常

• BlockException包含多个不同的子类：

5.3 自定义异常处理

@Componentpublic class SentinelExceptionHandler implements BlockExceptionHandler {@Overridepublic void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception {String msg = "未知异常";int status = 429;if (e instanceof FlowException) {msg = "请求被限流了";} else if (e instanceof ParamFlowException) {msg = "请求被热点参数限流";} else if (e instanceof DegradeException) {msg = "请求被降级了";} else if (e instanceof AuthorityException) {msg = "没有权限访问";status = 401;}response.setContentType("application/json;charset=utf-8");response.setStatus(status);response.getWriter().println("{\"msg\": " + msg + ", \"status\": " + status + "}");}}

• 授权拦截：
  

六 规则持久化

• sentinel的所有规则都是内存存储，重启后所有规则都会丢失。在生产环境下，我们必须确保这些规则的持久化，避免丢失。

6.1 规则管理模式

• 规则是否能持久化，取决于规则管理模式，sentinel支持三种规则管理模式：
  

• 原始模式：Sentinel的默认模式，将规则保存在内存，重启服务会丢失。

  • pull模式
  • push模式

6.2 pull模式

• pull模式：控制台将配置的规则推送到Sentinel客户端，而客户端会将配置规则保存在本地文件或数据库中。以后会定时去本地文件或数据库中查询，更新本地规则。
  

6.3 push模式

• push模式：控制台将配置规则推送到远程配置中心，例如Nacos。Sentinel客户端监听Nacos，获取配置变更的推送消息，完成本地配置更新。
  

6.4 实现push模式

6.4.1下载和解压Sentinel源码

• Sentinel下载地址
  
• 然后并用IDEA打开这个项目，结构如下：
  

6.4.2 修改nacos依赖

• 在sentinel-dashboard源码文件夹的pom文件中，nacos的依赖默认的scope是test，只能在测试时使用，这里要去除：
  

6.4.3 添加nacos支持

• 在sentinel-dashboard的test包下，已经编写了对nacos的支持，我们需要将其拷贝到main下
  

• 修改其中的nacos地址，让其读取application.properties中的配置：
  

• 在sentinel-dashboard的application.properties中添加nacos地址配置：
  

6.4.4 配置nacos数据源

6.4.5 修改前端页面

• 还要修改前端页面，添加一个支持nacos的菜单
• 修改src/main/webapp/resources/app/scripts/directives/sidebar/目录下的sidebar.html文件
  

• 修改其中的文本

  <li ui-sref-active="active" ng-if="entry.appType==0"> <a ui-sref="dashboard.flow({app: entry.app})"> <i class="glyphicon glyphicon-filter"></i>流控规则-NACOS</a> </li>

6.4.6 重新编译、打包项目

• 运行IDEA中的maven插件，编译和打包修改好的Sentinel-Dashboard：
  
  

6.4.7 启动

• 启动方式跟官方一样：

  java -jar sentinel-dashboard.jar

• 如果要修改nacos地址，需要添加参数：

  java -jar -Dnacos.addr=localhost:8848 sentinel-dashboard.jar