Nacos配置管理中心

一、Nacos配置管理

 也就是说Nacos不仅能充当注册中心，还能用来配置成配置中心。

 1、统一配置管理 

代码演示如下所示：

 

 

现在我们知道，Nacos配置管理中心已经有管理好的配置文件了，那么我们微服务（也就是一个功能模块，比如用户功能模块，现在这个微服务假如需要用到该Nacos配置管理中心管理的这个配置文件中的配置信息数据了）那么我们这个微服务怎么能够读取拉取到Nacos配置管理中心中管理的这个配置文件呢：

代码实现如下所示：

第一步：

        
            com.alibaba.cloud
            spring-cloud-starter-alibaba-nacos-config
        

 第二步：

 

spring:
  application:
    name: userservice # 服务名称
  profiles:
    active: dev   #开发环境，这里是dev
  cloud:
    nacos:
      server-addr: localhost:8848  # Nacos服务器地址
      config:
        file-extension: yaml #文件后缀名

 

通过第二步的操作之后，我们就知道我们这个微服务（用户功能模块），就已经拉读取到Nacos管理中心管理的那个配置文件了，我们知道该配置文件中有一个时间的配置属性数据，那么我们就可以验证一下我们这个微服务是否读到到该配置文件中的时间配置属性数据了（注意：我们这个微服务本地配置文件是没有时间配置属性数据的，只有Nacos管理中心的那个配置文件有，如果我们在这个微服务项目中能够获取到配置文件中的这个关于时间的配置属性数据，那么就证明我们这个微服务确实拉读取到了Nacos上的那个管理的配置文件了）：

 

总结：

         也就是说通过上面的演示，以后实际开发中如果我们的微服务（如一个功能模块）需要添加新的配置了，那么就不要再在自己本地的配置文件中修改添加配置数据了（因为在本地修改的话需要重启服务器才能生效），我们可以直接在Nacos管理中心添加一个配置文件，然后让这个微服务直接拉取这个配置文件然后获取到这个配置文件中微服务想要修改添加的新配置信息数据，最后再和自己本地的配置文件合并就可以了，同样达到了修改配置文件的作用，就可以不用再重新开启服务器了（以后项目会很多如果都重新启动的话太消耗资源了。）

二、配置热更新

 

 修改之后，我们思考我们微服务（也就是用户功能模块）在不启动服务器的情况下怎么获取读取到这个被Nacos管理中心管理的修改之后的这个配置文件中的配置数据呢：

第一种方式：

        当微服务（用户模块功能）是以@Value注解来拉读取Nacos管理中心中被管理的那个配置文件的时候，我们只需要在@Value注解对应的类上加上@RefreshScope注解即可完成热更新，也就是说微服务不用重启服务器同样可以拉读取到Nacos中修改的那个配置文件中修改的配置数据信息。

        注意：这种方式需要在加上@RefreshScope注解之后重启一下服务器，重启过之后，以后再修改管理的配置文件中的配置信息的时候就不用再重启服务器了。

然后我们在微服务的服务器不重启的情况下，会发现还真的能够拉读取到Nacos管理中心中那个修改后的配置文件中的配置数据信息啊：

第二种方式：（推荐使用）

        当获取Nacos配置管理中心中的配置文件数据是以@ConfigurationProperties注解的形式拉读取被管理的配置文件中的配置数据的时候，什么注解都不用加就可以实现热更新了。（也就是说只要是通过用@ConfigurationProperties注解来读取配置文件中的数据的话，那么就直接实现热更新问题了。）

复习@ConfigurationProperties注解获取配置文件数据的用法：（忘记的话可以看前面yaml数据格式的笔记）

三、多环境配置共享

直接上代码演示吧：

 

假如这个是无dev环境userservice.yaml配置文件中的数据：

假如这个是有dev环境userservice.yaml配置文件中的数据：

然后我们微服务（也就是用户接口功能），bootstrap.yml配置中只配置了拉读取Nacos管理配置中心中的有dev环境userservice.yaml配置文件中的数据，我们压根就没配置拉读取Nacos管理配置中心中的没有dev环境userservice.yaml配置文件中的数据，但最终我们会发现，好家伙我们明明配置的只想拉读取到Nacos管理配置中心中的有dev环境userservice.yaml配置文件中的时间数据，但实际结果是却把那个没有dev环境userservice.yaml配置文件中的“环境共享属性值”数据也拉取到了，最终会发现好家伙我们明明想要拉取的是带有dev环境userservice.yaml配置文件中的时间数据，却没想到最终却把带有dev环境userservice.yaml配置文件中的时间数据和没有dev环境userservice.yaml配置文件中的“环境共享属性值”数据都拉取获取到了：

 

总结：

        通过上面的演示我们就知道了虽然我们微服务的bootstrap.yml配置中配置的是只拉取Nacos管理配置中心中的有dev环境userservice.yaml配置文件中的时间数据，但是我们同样可以把Nacos管理配置中心中的没有dev环境userservice.yaml配置文件中的数据给拉取到，最终会发现却把Nacos管理配置中心中带有dev环境userservice.yaml配置文件中的时间数据和没有dev环境userservice.yaml配置文件中的“环境共享属性值”数据都拉取获取到了（具体如何拉取一个配置文件中属性对应的数据的过程，看yml的笔记即可）。

注意：但是我们如果微服务的bootstrap.yml配置中配置的是只拉取Nacos管理配置中心中的没有dev环境userservice.yaml配置文件中的数据的时候，就只能拉取到这个无环境的配置文件中的数据，不能拉取到带dev环境的配置文件中的数据。

思考：userservice.yaml（带dev环境）、userservice.yaml（不带dev环境）优先级

 

        首先我们上面知道了，当我们微服务的bootstrap.yml配置中配置的是只拉取Nacos管理配置中心中的有dev环境userservice.yaml配置文件中的数据的时候，最终的结果是却把Nacos管理配置中心中带有dev环境userservice.yaml配置文件中的数据和没有dev环境userservice.yaml配置文件中的数据都拉取获取到了。

那么我们现在思考：如果此时userservice.yaml（带dev环境）、userservice.yaml（不带dev环境）的这两个配置文件当中的配置属性数据是一样的时候，那么会以谁的为准呢？

userservice.yaml（不带dev环境）：

 

userservice.yaml（带dev环境）：

 

首先我们知道了我们微服务可以获取到上面的两个配置文件中的数据，那么如果此时上面的两个配置文件中都有这个name对应的配置数据的话，我们微服务就想获取这个name对应的配置数据的时候，到底会拉读取到上面两个配置文件中的谁的name对应的配置数据呢：