Nacos配置中心和SpringCloudConfig提供的功能是一致的，主要是为了解决两个问题

• 多环境配置，实现一次打包，根据环境信息启动不同的版本
• 提取公共配置，简化微服务的配置方式

多环境配置在SpringCloudConfig中一般使用spring.cloud.config.profile=prod来指定，在程序启动时，通过运行时参数传入，可以启动不同的版本。如java -jar client.jar --spring.cloud.config.profile=prod即可启动生产环境版本。对于公共配置，SpringCloudConfig的使用也非常简单，只需要通过spring.cloud.config.name=client,db,redis即可实现公共环境的配置文件载入，如第一个client为项目的主配置文件，db,redis分别表示要引入公共的数据库以及redis的配置文件信息。对于Nacos配置中心来说，其多环境的配置方式更加灵活，概念也更多一些，可以通过这些概念进行组合从而实现多环境配置。

Nacos中关于配置管理的概念主要有：Data ID、Group、NameSpace，另外加上SpringCloud本身的profile，主要通过这几个概念的组合使用实现多环境配置，由于其概念较多，因此实现多环境配置的方式更加灵活，可以依据自己的应用需求通过不同的方式实现。

Data ID方案实现多环境配置

回看之前的nacos-config项目，在该项目中，首先在Nacos配置管理的public命名空间中创建了Data ID=nacos-config.yml的配置文件。而在客户端的使用中仅指定了spring.cloud.nacos.config.file-extension=yml，之后客户端就可以正确获取到nacos-config.yml的配置信息，此前也介绍过nacos-config等于spring.application.name，spring.cloud.nacos.config.file-extension等于Data ID的文件后缀名。这里完整的描述一下Data ID的详细规则

Data ID=${spring.cloud.nacos.config.prefix}-${spring.profiles.active}.spring.cloud.nacos.config.file-extension，这是最完整的描述。

如果不指定prefix，则Data ID=${spring.application.name}-${spring.profiles.active}.spring.cloud.nacos.config.file-extension，即spring.cloud.config.prefix的默认值为应用名称spring.application.name。

spring.cloud.nacos.config.file-extension的默认值为properties，如果不指定该值，则Data ID=${spring.application.name}-${spring.profiles.active}.properties，当配置文件采用yaml格式时，必须指定file-extension。

当不指定spring.profiles.active时，则Data ID=${spring.application.name}.${spring.cloud.nacos.config.file-extension}，这也是最常使用的形态。

既然可以指定prefix，是不是Data ID可以完全和spring.application.name没有关系，可以任意配置呢？答案是肯定的，实现一个例子来测试一下。

Prefix和spring.application.name不同

仍然使用nacos-config项目，将原有的配置文件重命名，新建配置文件

（一）在Nacos配置中心创建一个配置文件personal.yml

user:
  name: personal

（二）客户端应用新的配置文件，并指定spring.cloud.nacos.config.prefix=personal

server:
  port: 8072
spring:
  application:
    name: nacos-config
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848
      config:
        server-addr: ${spring.cloud.nacos.discovery.server-addr}
        file-extension: yml
        prefix: personal

（三）启动服务，测试接口

从图中看到，客户端已经成功地应用了自定义文件名的Data ID配置信息。

一般情况下，不建议更改perfix，使得Data ID和应用程序名保持一致是一个好的习惯，也便于维护。

Data ID实现多环境配置

Data ID实现多环境配置，需要借助于spring.profiles.active来实现，通过应用程序在启动时，传入不同的参数，从而实现不同环境的配置文件引用。应用起来比较简单，和SpringCloudConfig方案基本上一致。

仍然使用nacos-config项目，保存原来的配置文件，新创建配置文件。

（一）在Nacos配置中心创建两个配置文件，Data ID=nacos-config-dev.yml以及Data ID=nacos-config-prod.yml

# nacos-config-dev.yml
user:
  name: dev

# nacos-config-prod.yml
user:
  name: prod

（二）修改客户端配置文件，添加spring.profiles.active=dev默认配置信息

spring:
  profiles:
    active: dev
  application:
    name: nacos-config
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848
      config:
        server-addr: ${spring.cloud.nacos.discovery.server-addr}
        file-extension: yml

配置信息和之前基本上一致，添加spring.profiles.active=dev配置，默认为dev环境。

（三）启动服务，观察启动信息，发现启用了dev环境，且明确获取以及监听了nacos-config-dev.yml配置文件信息

访问接口，确定dev环境配置信息生效curl localhost:8072/hi

curl localhost:8072/hi
# hi dev

启动时，使用spring.profiles.active=prod参数，启用prod环境，成功获取nacos-config-prod.yml配置信息。

java -jar nacos-config.jar --spring.profiles.active=prod

访问接口，确定prod环境生效curl localhost:8072/hi

curl localhost:8072/hi
# hi prod

Group实现多环境配置

Group是用来做分组管理的，比如可以将一类服务的配置文件归为一组，用户管理、第三方认证、机构区域管理等可以分组为USER_GROUP，这样配置的分组模式和业务服务的分组保持一致，便于理解和管理。而多环境开发、测试及生产本质上也是一种分组，因此可以使用Group来实现多环境配置。

（一）在Nacos配置中心，创建两个配置文件nacos-config.yml，名称相同，但Group分别命名为DEV_GROUP、PROD_GROUP

# dev_group
user:
  name: DEV_GROUP

# prod_group
user:
  name: PROD_GROUP

（二）创建配置文件，同时指定默认分组为spring.cloud.nacos.config.group=DEV_GROUP

spring:
  application:
    name: nacos-config
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848
      config:
        server-addr: ${spring.cloud.nacos.discovery.server-addr}
        file-extension: yml
        group: DEV_GROUP

（三）启动服务，此时将自动加载DEV_GROUP下的nacos-config.yml配置信息

观察启动信息显示，已经加载了DEV_GROUP配置信息

2021-03-05 14:09:02.673  INFO 14800 --- [           main] b.c.PropertySourceBootstrapConfiguration : Located property source: [BootstrapPropertySource {name='bootstrapProperties-nacos-config.yml,DEV_GROUP'}, BootstrapPropertySource {name='bootstrapProperties-nacos-config,DEV_GROUP'}]

访问接口，验证配置信息的加载正确性:curl localhost:8072/hi

curl localhost:8072/hi
# hi DEV_GROUP

重启服务，并指定spring.cloud.nacos.config.group=PROD_GROUP

java -jar nacos-config.jar --spring.cloud.nacos.config.group=PROD_GROUP
# 观察启动信息，发现已加载PROD_GOURP下的nacos-config.yml配置信息
2021-03-05 14:12:24.595  INFO 9212 --- [           main] b.c.PropertySourceBootstrapConfiguration : Located property source: [BootstrapPropertySource {name='bootstrapProperties-nacos-config.yml,PROD_GROUP'}, BootstrapPropertySource {name='bootstrapProperties-nacos-config,PROD_GROUP'}]

验证接口curl localhost:8072/hi

curl localhost:8072/hi
# hi PROD_GROUP

Namespace实现多环境配置

Namespace是Nacos提出的一个新的概念，用于进行租户粒度的配置隔离，在不同的命名空间下，可以具有相同的Group和Data ID，因此命名空间天然适合用于实现多环境的配置隔离，这也是官方推荐的方案。

（一）创建两个新的命名空间，分别命名为dev、prod

（二）在dev、prod两个命名空间下，分别创建nacos-config.yml配置文件，group都为默认值DEFAULT_GROUP

这里可以使用Nacos提供的克隆配置文件工具，快速创建这两个配置文件。在public命名空间下，选中之前的nacos-config.yml配置文件，之后点击克隆，在弹出框中选择目标空间，并点击开始克隆即可创建目标配置文件

# dev namespace   Data ID=nacos-config.yml  GROUP=DEFAULT_GROUP
user:
  name: dev-namespace

# prod namespace  Data ID=nacos-config.yml  GROUP=DEFAULT_GROUP
user:
  name: prod-namespace

（三）创建配置文件，并指定spring.cloud.nacos.config.namespace=589f047a-45b5-4878-8fd4-61daa2652344值，具体的值，可以从Nacos配置中心中复制

spring:
  application:
    name: nacos-config
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848
      config:
        server-addr: ${spring.cloud.nacos.discovery.server-addr}
        file-extension: yml
        namespace: 589f047a-45b5-4878-8fd4-61daa2652344

（四）启动服务，默认是调用了dev的命名空间，访问测试

curl localhost:8072/hi
# hi dev-namespace

重启服务，并指定spring.cloud.nacos.config.namespace=3800ada3-acd2-46a6-a424-c72a3fc5ba8d，该值对应prod命名空间，并访问接口测试

java -jar nacos-config.jar --spring.cloud.nacos.config.namespace=3800ada3-acd2-46a6-a424-c72a3fc5ba8d

curl localhost:8072/hi
# hi prod-namespace

总结

Nacos多环境配置更加灵活，可以使用Data ID、Group、Namespace三种方案实现多环境配置，官方推荐Namespace来实现多环境配置。经过对三种方案的使用和分析，最终采用了Namespace命名空间的方案来实现多环境配置，目前已创建了20+个子服务，配置文件40余，规模不大，配置文件虽然不多，但是真管理起来，也比较费劲，使用该方案，良好的解决了三种环境的配置、应用以及日常维护和管理，简化了工作流程。

为什么最终采用了Namespace方案？主要是其他两个方案分别有以下问题

• Data ID，该方案简单且和SpringCloudConfig基本上一致，但是只在一个命名空间下，40多个配置文件，分三个系统，则会膨胀到近150个配置文件，（这还是小规模的微服务集群），管理和配置都造成了很大的困扰。随着服务的增加，这个问题将会越来越严重。
• Group方案解决了一部分Data ID的问题，对三种环境的配置文件分组，可以借助Nacos的分组筛选，降低了配置文件过多，不好管理的问题。但是对于之前提出的想要对同类业务的服务进行再次分组管理，此时没办法做到，因为Group已经被占用。
• Namespace方案解决了前面两个方案的弊端，一方面通过命名空间分散了配置文件多，乱的管理性问题，另外一方面可以通过Group进行业务分组，进一步规范了配置文件的管理。

基于SpringCloudAlibaba微服务架构设计及实现系列文章

1. 基于SpringCloudAlibaba微服务架构设计及实现
2. SpringCloud-Nacos实现服务的注册与发现（一）
3. SpringCloud：Nacos配置中心应用（二）
4. SpringCloud-Nacos配置持久化（三）
5. SpringCloud-Nacos集群化部署（四）
6. Nacos启用身份认证解决Nacos安全漏洞（五）