一、Nacos配置中心介绍 从架构图上可以知道，Nacos提供了两种服务，一种是用于服务注册、发现的Naming Service，一种是用于配置中心、动态配置的Config Service，而他们底层均由core模块来支持。外层提供OpenAPI供客户端使用，并提供了User Console、Admin Console方便用户使用 。
用户通过管理平台发布配置，通过HTTP调用将配置注册到服务端，服务端将之保存在MySQL等持久化存储引擎中；用户通过客户端SDK访问服务端的配置，同时建立HTTP的长轮询监听配置项变更，同时为了减轻服务端压力和保证容灾特性，配置项拉取到客户端之后会保存一份快照在本地文件中，SDK优先读取本地文件里的配置。当服务端的配置发生变更时，客户端会通过监听机制，拿到变更后的最新配置信息。
简单来说，Nacos 客户端是怎么实时获取到 Nacos 服务端的最新数据的：
Nacos 并不是通过推的方式将服务端最新的配置信息发送给客户端的，而是客户端维护了一个长轮询的任务，定时去拉取发生变更的配置信息，然后将最新的数据推送给 Listener 的持有者。
二、配置中心搭建 1.配置中心启用 首先需要到官网上下载nacos-server，然后将服务跑起来之后。根据自己的需要，建立几个命名空间，当然使用默认的public的命名空间也是可以的，如图所示。
2.创建配置文件 在配置列表中创建配置文件，其中配置文件命名方式需要注意。
在Nacos-Server中新建配置，其中Data ID它的定义规则是：${prefix}-${spring.profiles.active}.${file-extension}
prefix 默认为 spring.application.name 的值，也可以通过配置项 spring.cloud.nacos.config.prefix 来配置。
spring.profiles.active 即为当前环境对应的 profile，可以通过配置项 spring.profiles.active 来配置。
file-exetension 为配置内容的数据格式，可以通过配置项 spring.cloud.nacos.config.file-extension 来配置。目前只支持 properties 和 yaml 类型。
注意：当 spring.profiles.active 为空时，对应的连接符 - 也将不存在，dataId 的拼接格式变成 prefix.{prefix}.prefix.{file-extension}
在本文中，我的项目名称为vaso-core，配置文件使用的是dev环境，因此我的配置文件如下：
其中的文件内容就是正常的yaml格式的内容填写就行，这边就不具体展示了。
3.工程配置 首先我们需要导入nacos-config的依赖（注：我这边没有使用nacos的注册发现，依旧沿用自身使用的eureka）。其中依赖版本的对应关系可以在官网中查找。
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
<version>2.1.2.RELEASE</version>
</dependency>
其次我们需要在配置文件中进行配置，采用bootstrap.yml文件进行配置，因为springboot会优先启动bootstrap.yml文件中的配置。其中文件内容如下：
bootstrasp.yml:
spring: application: name: vaso-core cloud: nacos:
discovery:
server-addr: xx.xx.xxx.xx:8848
namespace: 8b387ec4-e60d-4878-baf4-f2246e58a1d6
config:
server-addr: xx.xx.xxx.xx:8848
file-extension: yml
namespace: 8b387ec4-e60d-4878-baf4-f2246e58a1d6
profiles: active: dev namespace的内容为上文中配置的dev命名空间的id。
最后我们需要引入@refreshscope关键字，保证可以实时刷新配置。在controller层或者要刷新的值所在的类上进行注释就行。
其中我们的demo是如下所示：
三、试验结果 将工程跑起来，可以看到一开始就已经去配置中心读取配置了，如图：
此时将配置中心内容修改，可以看到已经实时刷新了配置。
四、踩坑经历 其实在正式使用之前也碰到过nacos无法试试实时刷新的问题，打断点却发现实际已经读取到本地，通过进入spring的源码中查看，也发现其实已经可以拿到配置了，但是却一直无法刷新配置。最后通过一个礼拜的定位源码，断点查询才发现一个本质性的问题。欲哭无泪
@RefreshScope与数据源之间存在冲突！！
具体如下：
因为项目是多数据源，所以使用的是自定义数据源配置的DataSource，用@Bean注入。
在SpringBoot 2.0以上默认使用Hikari连接池，一旦连接池启动，就无法再修改HikariDataSource，所以刷新配置时连带数据源一起刷新，于是会报错。
Caused by: java.lang.IllegalStateException: The configuration of the pool is sealed once started. Use HikariConfigMXBean for runtime changes.
解决方法： 在自定义的DataSource上加入注解@RefreshScope，或者使用spring.scloud.refresh.extra-refreshable配置指定classname列表即可。
查看Hikari的默认配置即可发现，这个与刷新配置之间是存在冲突的。
因此在数据源配置类中加入注释，这样每次刷新配置的时候会重新刷新这个Bean，那么就可以保证不会报错，这样的spring的刷新机制就可以顺利执行下去了。
