上篇文章：
https://blog.csdn.net/sniper_fandc/article/details/149938785?fromshare=blogdetail&sharetype=blogdetail&sharerId=149938785&sharerefer=PC&sharesource=sniper_fandc&sharefrom=from_link目录
1 介绍
微服务环境下，配置文件需要经常修改，一旦修改就要重新部署。同时多人对同一个配置文件反复修改可能会冲突，增加开发难度。
针对上面的问题，Nacos可以帮我们管理配置项，即配置中心的作用。通过在Nacos配置中心增加、修改、查看和删除配置，服务启动时从配置中心获取配置；当配置中心的配置项变动时，Nacos配置中心又会通知服务配置变更。
2 使用Nacos实现配置中心
首先现在配置中心创建配置：
这里的Data ID设置为项目名称，配置格式目前支持YAML和Properties，并设置配置内容nacos.config=public（该配置项无实际意义，只是用来测试）。
在需要读取配置的服务中添加依赖：
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>
<!-- SpringCloud 2020.*之后版本需要引⼊bootstrap-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bootstrap</artifactId>
</dependency>这里因为SpringCloud 2020.*版本之后移除了bootstrap依赖，而配置中心的配置（在微服务中配置）需要bootstrap配置文件，因此需要引入该依赖。
新建bootstrap.yml文件，配置如下内容：
spring:
application:
name: product-service
cloud:
nacos:
config:
server-addr: 192.168.159.150:8848name的值是Data ID，server-addr则是配置中心的地址（即nacos服务器地址）。
注意：该配置是配置中心相关的，区分和服务发现的配置。bootstrap.yml在服务启动时会更早地读取，获取配置中心的地址后向配置中心获取配置项，并把获取的配置项和application.yml合并。
从application.yml文件中获取从配置中心拉取的配置项：
@RequestMapping("/config")
@RefreshScope
@RestController
public class NacosController {
@Value("${nacos.config}")
private String nacosConfig;
@RequestMapping("/get")
public String get() {
return nacosConfig;
}
}@Value("${nacos.config}")注解则是从配置文件中获取配置项，注解中${}中填配置项中的变量名称。而@RefreshScope是配置热更新注解，添加后服务端就可以根据配置中心的配置项变化而实时感知到。
重启服务，访问该接口，可以发现配置项实时获取到了：
3 命名空间和Data ID
3.1 命名空间
在Nacos中，配置管理的命名空间和服务管理的命名空间无关，即某个命名空间下的服务读取配置中心的配置时并不是读取同一个命名空间下的配置管理。
可以发现，刚刚读取配置项的服务是在服务管理的命名空间dev下面，但是却读到了配置管理的命名空间public下的配置项。
如果想要配置管理的命名空间和服务管理的命名空间一致，需要在服务中配置文件的Nacos配置中心的配置项（即bootstrap.yml文件）配置namespace和服务管理的命名空间一样（如果不配置默认都读取public命名空间下的配置项）。
spring:
application:
name: product-service
cloud:
nacos:
config:
server-addr: 192.168.159.150:8848
namespace: 0e97b7df-af8f-4a64-b7b4-c9122b186e6c在dev命名空间下创建相同的配置项，值为public1：
重启服务，访问接口，发现成功读取到配置项：
3.2 Data ID
Data ID的全写格式如下：
${prefix}-${spring.profiles.active}.${file-extension}prefix默认是spring:application:name的值（即服务名），也可以通过spring.cloud.nacos.config.prefix来配置（bootstrap文件）。
spring.profiles.active是当前环境对应的profile，默认为空（即省略该变量，同时-也省略）。该变量可以理解为开发环境、测试环境和生产环境等意思。
file-extension是配置中心配置项的文件格式，目前只支持yml和properties（默认格式）。也可以通过spring.cloud.nacos.config.file-extension配置（bootstrap文件）。
微服务启动时会创建三个监听器，分别监听${prefix}-${spring.profiles.active}.${file-extension}、${prefix}.${file-extension}和${prefix}这三个配置中心的配置项对应的文件。
三个文件的优先级为（这里强调的是如果三种文件都存在，并且都是对应同一个服务的配置文件，从配置中心获取配置的优先级）：${prefix}-${spring.profiles.active}.${file-extension}>${prefix}.${file-extension}>${prefix}
依次在配置中心创建多种配置文件，配置项的值分别为dev1、dev2和dev3：
修改bootstrap.yml文件：
spring:
application:
name: product-service
profiles:
active: dev
cloud:
nacos:
config:
server-addr: 192.168.159.150:8848
namespace: 0e97b7df-af8f-4a64-b7b4-c9122b186e6c重启服务，观察日志：
访问接口，结果如下：
可以发现，优先访问的是product-service-dev.properties的配置项。
4 Nacos和Eureka比较
1.功能方面：Eureka功能主要用来服务注册和服务发现；Nacos除了服务注册和服务发现，还提供配置中心、流量管理（负载均衡）和DNS服务等功能。
2.CAP理论方面：Eureka遵循AP原则；Nacos即遵循AP又遵循CP，如果是临时服务，则是AP，如果不是就是CP，可能AP和CP混合出现。
3.服务发现：Eureka和服务之间是拉模式，即Eureka周期性向服务实例拉取服务信息（默认30s）。而Nacos和服务之间是推送模式，Nacos和服务之间保持心跳连接，一旦服务列表发生变化，Nacos将信息实时推送给订阅者。
下篇文章：