最全springcloudAlibaba视频笔记-第三章Nacos Config服务配置中心

标签：配置文件 Config 配置 Nacos nacos provider config springcloudAlibaba

Nacos Config服务配置中心

课程视频：https://www.bilibili.com/video/BV1VW4y1o7n5 本课程使用的是目前最新版本2022.0.0.0-RC2。基于Spring Boot 3.0与JDK20的开发环境。

集群中每一台主机的配置文件都是相同的，对配置文件的更新维护就成为了一个棘手的问题。此时就出现了配置中心，将集群中每个节点的配置文件交由配置中心统一管理。相关产品很多，例如，Spring Cloud Config、Zookeeper、Apollo、Disconf(百度的，不再维护)等。但Spring Cloud Alibaba官方推荐使用Nacos作为微服务的配置中心。

3.1 常见配置中心工作原理

3.1.1 Spring Cloud Config

其存在三大问题：

无法自动感知更新
存在羊群效应
系统架构过于复杂

3.1.2 Apollo

其Config Client可以自动感知配置文件的更新。但也存在两个不足：

系统架构复杂
配置文件支持类型较少，其只支持xml、text、properties，不支持json、yml。

3.1.3 Nacos Config

Config Client通知自动感知配置中心中相应配置文件的更新。
架构简单
支持的配置文件类型较多(支持JSON与YML)

3.1.4 Zookeeper

Zookeeper作为配置中心，其工作原理与前面的三种都不同。其没有第三方服务器去存储配置数据，而是将配置数据存放在自己的Znode中了。当配置中心中的配置数据发生了变更，Config Client也是可以自动感知到的（Watcher监听机制）。

3.1.5 一致性问题

配置中心中的配置数据一般都是持久化在第三方服务器的，例如DBMS、Git远程库等。由于这些配置中心Server中根本就不存放数据，所以它们的集群中就不存在数据一致性问题。但像Zookeeper，其作为配置中心，配置数据是存放在自己本地的。所以该集群中的节点是存在数据一致性问题的。Zookeeper集群对于数据一致性采用的是CP模式。作为注册中心，这些Server集群间是存在数据一致性问题的，它们采用的模式是不同的。Zookeeper（CP）、Eureka（AP）、Consul（AP）、Nacos（默认AP，也支持CP）。

3.2 获取远程配置

这里实现的需求是，应用的配置文件不在本地，而由Nacos Config进行管理。

3.2.1 Nacos中完成配置

3.2.1.1 打开配置列表

启动Nacos，然后打开nacos页面。 Data ID用于指定在nacos config中保存的配置文件的名称。该文件可以是yml或properties，但名称必须为微服务名称。应用在启动时就是通过微服务名称在nacos config中查找相应的配置文件的。这里要使用的配置格式为YAML。发布，返回后，就可看到如下清单了。

3.2.1.2 填写配置内容

将原来application.yml中的全部内容复制到该页面，并将原来的spring.application.name属性删除。

| server: port: 8081 spring: cloud: _# 指定nacos server地址 _nacos: discovery: server-addr: localhost:8848

jpa: generate-ddl: true show-sql: true hibernate: ddl-auto: none

_# 配置数据源 _datasource: type: com.alibaba.druid.pool.DruidDataSource driver-class-name: com.mysql.jdbc.Driver url: jdbc:mysql:///test?useUnicode=true&useSSL=false&characterEncoding=utf8 username: root password: 111 logging: _# 设置日志输出格式 _pattern: console: level-%level %msg%n level: root: info org.hibernate: info org.hibernate.type.descriptor.sql.BasicBinder: trace org.hibernate.type.descriptor.sql.BasicExtractor: trace com.abc.provider: debug | | --- |

3.2.2 定义提供者03-provider-nacos-config-8081

3.2.2.1 定义工程

复制02-provider-nacos-8081工程，并重命名为03-provider-nacos-config-8081。

3.2.2.2 修改pom

在pom中添加如下依赖。

| <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>

</dependency>

3.2.2.3 修改application.yml

删除原有的application.yml文件的内容，替换为如下内容。

3.2.3 关于配置文件的扩展

当前服务配置、共享配置与扩展配置的加载顺序为：共享配置，扩展配置，当前服务配置。若在三个配置中具有相同属性设置，但它们具有不同的值，那么，后加载的会将先加载的给覆盖。即这三类配置的优先级由低到高是：共享配置，扩展配置，当前服务配置当前服务配置可以存在于三个地方：远程配置文件：（Nacos config中）快照文件：本地配置文件：(主动写入的配置文件) 这三个同名文件也存在加载顺序问题，它们的加载顺序为：本地配置文件、远程配置文件、快照配置文件。只要系统加载到了配置文件，那么后面的就不再加载。

3.2.4 运行访问

启动03-provider-nacos-config-8081，页面正常访问即可。

3.3 动态更新配置

3.3.1 需求

这里要实现的需求是：从数据库中根据id查询到的depart的name值，在浏览器上显示的并不是DB中的name，而是来自于nacos的动态配置depart.name。

3.3.2 修改Nacos配置数据

直接在nacos config配置页面修改配置信息，例如添加一个depart.name属性。修改完毕后，再次发布即可。

3.3.3 修改提供者工程

直接修改03-provider-nacos-config-8081工程中的DepartServiceImpl类。首先在需要动态更新配置数据的类上添加@RefreshScope注解，然后再添加departName属性，该属性值读取自配置文件中的depart.name属性。为了演示配置信息的动态更新效果，再修改如下方法返回值。

3.3.4 刷新访问页面

重启应用后，刷新页面可以看到数据已经更新。然后再多次更新远程配置文件，无需重启03-provider-nacos-config-8081工程，直接刷新访问页面即可获取到更新的数据。

3.3.5 长轮询模型

Nacos Config Server中配置数据的变更，Nacos Config Client是如何知道的呢？Nacos采用的是长轮询模型。长轮询模型整合了Push与Pull模型的优势。Client仍定时发起Pull请求，查看Server端数据是否更新。若发生了更新，则Server立即将更新数据以响应的形式Push给Client端；若没有发生更新，Server端并不向Client进行Push，而是临时性的保持住这个连接一段时间。若在此时间段内，Server端数据发生了变更，则立即将变更数据Push给Client。若仍未发生变更，则放弃这个连接。等待着下一次Client的Pull请求。长轮询模型，是Push与Pull模型的整合，既降低了Push模型中长连接的维护问题，又降低了Push模型实时性较低的问题。