持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第29天，点击查看活动详情

一、Nacos配置中心使用

Nacos 提供用于存储配置和其他元数据的 key/value 存储，为分布式系统中的外部化配置提供服务器端和客户端支持。使用 Spring Cloud Alibaba Nacos Config，您可以在 Nacos Server 集中管理你 Spring Cloud 应用的外部属性配置。

如上图，在没有Nacos Config配置中心的情况下，那OrderService和ProductService在不同的环境下就需要配置不同的配置文件，它们有不同的配置，当然也肯定有相同的配置信息，如redis/mq/db等，如果redis的服务器扩容或者缩容，那就需要将所有配置文件都进行修改，实在太麻烦，万一不小心还容易改错。而且改了配置文件还需要重启服务，而且万一服务是集群部署，如果挨个修改，就会导致服务造成不一致性的结果。同样如果把所有配置信息都放在服务中，就会暴露出相关配置的账号密码，这样也是不安全的。通过以上可以知道。是非常不易于维护，总结起来就是1.维护性 2.时效性 3.安全性方面就无法确保

而Nacos Config就帮助我们实现了配置中心的功能，可以极大的简化配置的处理，可以完美解决上面的问题，下面来看一下。

springcloud config 对比

三大优势：

springcloud config大部分场景结合git 使用, 动态变更还需要依赖Spring Cloud Bus 消息总线来通过所有的客户端变化.
springcloud config不提供可视化界面
nacos config使用长轮询更新配置, 一旦配置有变动后，通知Provider的过程非常的迅速, 从速度上秒杀springcloud原来的config几条街

通过以上spring cloud config/apllo/nacos的对比，可以很明显的看出nacos是非常具有优势的。

1-1、快速开始

1-1-1、新增配置

准备配置，nacos server中新建nacos-config 点击新增，填入相关信息，即可完成配置，如下：

Group：代表某项目，如XX医疗项目、XX电商项目

DataId：每个项目下往往有若干个工程（微服务），每个配置集(DataId)是一个工程（微服务）的主配置文件

返回列表就可以看到配置的信息了

创建好的配置服务在Nacos库config_info表中,如下：

1-1-2、历史版本

首先修改刚刚新增的配置信息，如下：

选择刚刚修改的配置信息，点击历史版本

这样Data ID和Group就会自动填充选中数据的内容，并显示修改历史记录，如下

点击详情，就可以当前版本修改前的内容，如下：这样，如果不小心改错并且修改的内容比较多，就可以通过历史版本进行一键回滚了。

1-1-3、配置文件的克隆

项目前期我们都在开发环境研发，当发布线上的时候，就需要将配置文件里面的相关信息修改为生成环境的配置，我们就可以克隆开发环境的配置，到生成环境，然后再修改里面的生成环境配置

选择要克隆到的命名空间

这样dev下也就有了刚刚的配置了

1-1-4、权限控制

权限控制功能比较常规就不再进行介绍了，主要就是配置角色和可操作的相关权限，唯一需要注意的是，如果要让权限起作用，需要修改Nacos/conf下的application.properties文件，让权限配置生效（如果是集群环境，所有节点都需要修改），如下图：

1-2、搭建nacos-config服务

上面主要讲述如何在Nacos中对配置文件的相关编写及权限控制，那如何让项目可以加载上面的配置文件呢？下面来操作一下

通过 Nacos Server 和 spring-cloud-starter-alibaba-nacos-config 实现配置的动态变更

1-2-1、引入依赖

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

1-2-2、添加bootstrap.properties

在项目resource下添加bootstrap.porperties/yml配置文件，这个文件名称必须固定，是nacos设置好的文件名称，并且需要在此文件中配置nacos的配置名称和nacos地址，如下：

spring:
  application:
    #配置服务名，这个服务名和nacos的Data ID一致就不需要特殊处理，如果不一致还需要对DataID
    name: nacos-config

  cloud:
    nacos:
      config:
        #配置Nacos的访问地址（我这边是集群nginx的地址）
        server-addr: 192.168.253.131:8851
        #因为在nacos的application.properties已经开启了权限，因此用户名密码是必须要配置的
        username: nacos
        password: nacos
        #配置命名空间
        namespace: public

1-2-3、启动服务，测试微服务是否使用配置中心的配置

在启动类获取配置文件中的值

@SpringBootApplication
public class NacosConfigApplication {
    public static void main(String[] args) {
        ConfigurableApplicationContext applicationContext = SpringApplication.run(NacosConfigApplication.class, args);
        String userName = applicationContext.getEnvironment().getProperty("user.name");
        String userAge = applicationContext.getEnvironment().getProperty("user.age");
        System.out.println("user name :"+userName+"; age: "+userAge);
    }
}

1-3、Config相关配置

Nacos 数据模型 Key 由三元组唯一确定, Namespace默认是空串，公共命名空间（public），分组默认是 DEFAULT_GROUP

1-3-1、客户端配置的动态更新

原理：
在Nacos客户端配置了相关配置后，nacos就会对当前配置信息进行MD5加密，并且每10ms和客户端进行一次通信，如果本地服务的md5和nacos端md5不一致，就会进行配置的拉取，这样就实现了配置的动态修改。

通过while循环中，让线程暂停一秒，就可以看到每一秒就会输出从nacos配置中心获取的配置信息，如下：

在Nacos配置中心修改配置之后，本地就会很快进行拉取最新配置信息，如下：

之前使用@Value来获得配置文件中的值，那如果在属性上使用Nacos配置中心的值，就需要在类上添@RefreshScope注解

1-3-2、通过file-extension设置配置文件类型

Nacos默认使用properties类型的配置，如果要使用yml格式的文件，需要在bootstrap.yml中配置文件类型
将默认的properties类型改为yml类型，并且将配置格式也改为yml格式，这时候如果不修改bootstrap.yml/properties，就无法识别配置信息了如下：

首先获得配置文件的user.name

然后访问获得name,可以看到获取的是电脑的用户名

这时候就需要在bootstrap配置文件，设置文件类型为yml

再次访问，获得user.name,可以看到已经可以正常获得user.name的值了。

1-3-3、支持profile粒度的配置

spring-cloud-starter-alibaba-nacos-config 在加载配置的时候，不仅仅加载了以 dataid 为 ${spring.application.name}.$ {file-extension:properties} 为前缀的基础配置，还加载了dataid为 ${spring.application.name}-$ {profile}. ${file-extension:properties} 的基础配置。在日常开发中如果遇到多套环境下的不同配置，可以通过Spring 提供的$ {spring.profiles.active} 这个配置项来配置。

spring.profiles.active=dev

profile 的配置文件大于默认配置的文件。并且形成互补

1-3-3-1、配置开发环境文件

比如现在要配置dev环境的配置文件，首先在nacos中创建DataId,规则为： ${spring.application.name}-$ {profile}.${file-extension:properties}

因此dataid为：nacos-config-dev.yml

然后再指向dev配置

访问测试，user.name已经是dev配置文件中的值

ps：只有默认的配置文件，才会应用profile，也就是服务项目名的配置文件，如果使用redis.yml,改为redis-dev.yml就不适用了

1-3-4、支持自定义 namespace 的配置

用于进行租户粒度的配置隔离。不同的命名空间下，可以存在相同的 Group 或 Data ID 的配置。Namespace 的常用场景之一是不同环境的配置的区分隔离，例如开发测试环境和生产环境的资源（如配置、服务）隔离等。

在没有明确指定 ${spring.cloud.nacos.config.namespace} 配置的情况下，默认使用的是 Nacos 上 Public 这个namespace。如果需要使用自定义的命名空间，可以通过以下配置来实现：

spring.cloud.nacos.config.namespace=dev

最终建议使用namespace的方式来处理生成环境和开发环境的处理，虽然profile的方式也可以，但是无法设置权限的处理，比如只让开发人员查看dev的环境，无权限查看生成环境的配置信息，使用profile就无法实现了。

1-3-5、支持自定义 Group 的配置

Group是组织配置的维度之一。通过一个有意义的字符串（如 Buy 或 Trade ）对配置集进行分组，从而区分 Data ID 相同的配置集。当您在 Nacos 上创建一个配置时，如果未填写配置分组的名称，则配置分组的名称默认采用 DEFAULT_GROUP 。配置分组的常见场景：不同的应用或组件使用了相同的配置类型，如 database_url 配置和 MQ_topic 配置。

在没有明确指定 ${spring.cloud.nacos.config.group} 配置的情况下，默认是DEFAULT_GROUP 。如果需要自定义自己的 Group，可以通过以下配置来实现：

spring.cloud.nacos.config.group=DEVELOP_GROUP

1-3-6、支持自定义扩展的 Data Id 配置

上面主要提到使用项目名和Nacos中DataID一致名称的配置，那如果多个项目中使用共同的配置，如redis。改如何配置呢?下面来看一下

Data ID 是组织划分配置的维度之一。Data ID 通常用于组织划分系统的配置集。一个系统或者应用可以包含多个配置集，每个配置集都可以被一个有意义的名称标识。Data ID 通常采用类 Java 包（如 com.taobao.tc.refund.log.level）的命名规则保证全局唯一性。此命名规则非强制。

通过自定义扩展的 Data Id 配置，既可以解决多个应用间配置共享的问题，又可以支持一个应用有多个配置文件。

1-3-6-1、通过sharedConfigs配置

首先在Nacos中添加DataID为：redis.yml配置文件，如下：

然后在bootstrap.yml中添加如下配置

修改控制器、获得redis端口

浏览器访问，可以看到可以获得默认配置文件以及通过sharedConfigs配置的其他文件配置信息

如果需要加在多个其他文件
首先创建一个mq的配置文件

在bootstrap中添加mq的配置，也可以继续往后面追加其他配置文件

1-3-6-2、使用extensionConfigs的方式配置

因为extensionConfigs是集合，因此支持下标设置配置文件，如下

1-4、配置的优先级

Spring Cloud Alibaba Nacos Config 目前提供了三种配置能力从 Nacos 拉取相关的配置。

A: 通过 spring.cloud.nacos.config.shared-configs 支持多个共享 Data Id 的配置
B: 通过 spring.cloud.nacos.config.extensionConfig[n].data-id 的方式支持多个扩展 Data Id 的配置
C: 通过内部相关规则(应用名、应用名+ Profile )自动生成相关的 Data Id 配置

当三种方式共同使用时，他们的一个优先级关系是:A < B < C

优先级从高到低：

nacos-config-product.yaml 精准配置 2) nacos-config.yaml 同工程不同环境的通用配置 3) extensionConfig: 不同工程扩展配置 4) shared-dataids 不同工程通用配置

Alibaba 微服务组件Nacos配置中心