Nacos配置细化

Nacos配置细化

多环境管理

在Nacos中，本身有多个不同管理级别的概念，包括：Data ID、Group、Namespace。只要利用好这些层级概念的关系，就可以根据自己的需要来实现多环境的管理。

下面，我就来介绍一下，可以使用的几种实现方式：

使用Data ID与profiles实现

Data ID在Nacos中，我们可以理解为就是一个Spring Cloud应用的配置文件名。我们知道默认情况下Data ID的名称格式是这样的：${spring.application.name}.properties，即：以Spring Cloud应用命名的properties文件。

实际上，Data ID的规则中，还包含了环境逻辑，这一点与Spring Cloud Config的设计类似。我们在应用启动时，可以通过spring.profiles.active来指定具体的环境名称，此时客户端就会把要获取配置的Data ID组织为：${spring.application.name}-${spring.profiles.active}.properties。

实际上，更原始且最通用的匹配规则，是这样的：${spring.cloud.nacos.config.prefix}-${spring.profile.active}.${spring.cloud.nacos.config.file-extension}。而上面的结果是因为${spring.cloud.nacos.config.prefix}和${spring.cloud.nacos.config.file-extension}都使用了默认值。

具体操作如下

1. 在nacos中，根据这个规则创建两个不同的配置内容

   

   在nacos-provider-dev.yml中增加：

   test: 此为dev
   server:
     port: 8888
   

   在nacos-provider-prod.yml中增加：

   test: 此为prod
   server:
     port: 8888
   

2. 在bootstrap.yml，增加spring.profiles.active=dev

3. 这时候我们访问地址就可以看到

   

使用Group实现

Group在Nacos中是用来对Data ID做集合管理的重要概念。所以，如果我们把一个环境的配置视为一个集合，那么也就可以实现不同环境的配置管理。对于Group的用法并没有固定的规定，所以我们在实际使用的时候，需要根据我们的具体需求，可以是架构运维上对多环境的管理，也可以是业务上对不同模块的参数管理。为了避免冲突，我们需要在架构设计之初，做好一定的规划。这里，我们先来说说如何用Group来实现多环境配置管理的具体实现方式。

具体操作如下

1. 在nacos创建规则

   

   在DEV_DEFAULT_GROUP中增加：

   test: 此为DEV_GROUP
   server:
     port: 8888
   

2. 在bootstrap.yml，增加spring.cloud.nacos.config.group=DEV_DEFAULT_GROUP

   

3. 这时候我们访问地址就可以看到

   

使用Namespace实现

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

具体操作如下

1. 在Nacos中创建命名空间，并在命名空间增加配置

   

   在张伟31398485-c414-45d1-9f0c-426011114fa5增加如下配置：

   test: 此为张伟Namespace
   server:
     port: 8888
   

2. 在bootstrap.yml，增加spring.cloud.nacos.config.namespace=31398485-c414-45d1-9f0c-426011114fa5

   

3. 这时候我们访问地址就可以看到

   

总结

上面我们分别利用Nacos配置管理功能中的几个不同纬度来实现多环境的配置管理。从结果上而言，不论用哪一种方式，都能够胜任需求，但是哪一种最好呢？

第一种：通过Data ID与profile实现。

• 优点：这种方式与Spring Cloud Config的实现非常像，用过Spring Cloud Config的用户，可以毫无违和感的过渡过来，由于命名规则类似，所以要从Spring Cloud Config中做迁移也非常简单。
• 缺点：这种方式在项目与环境多的时候，配置内容就会显得非常混乱。配置列表中会看到各种不同应用，不同环境的配置交织在一起，非常不利于管理。
• 建议：项目不多时使用，或者可以结合Group对项目根据业务或者组织架构做一些拆分规划。

第二种：通过Group实现。

• 优点：通过Group按环境讲各个应用的配置隔离开。可以非常方便的利用Data ID和Group的搜索功能，分别从应用纬度和环境纬度来查看配置。
• 缺点：由于会占用Group纬度，所以需要对Group的使用做好规划，毕竟与业务上的一些配置分组起冲突等问题。
• 建议：这种方式虽然结构上比上一种更好一些，但是依然可能会有一些混乱，主要是在Group的管理上要做好规划和控制。

第三种：通过Namespace实现。

• 优点：官方建议的方式，通过Namespace来区分不同的环境，释放了Group的自由度，这样可以让Group的使用专注于做业务层面的分组管理。同时，Nacos控制页面上对于Namespace也做了分组展示，不需要搜索，就可以隔离开不同的环境配置，非常易用。
• 缺点：没有啥缺点，可能就是多引入一个概念，需要用户去理解吧。
• 建议：直接用这种方式长远上来说会比较省心。虽然可能对小团队而言，项目不多，第一第二方式也够了，但是万一后面做大了呢？

注意：不论用哪一种方式实现。对于指定环境的配置（spring.profiles.active=DEV、spring.cloud.nacos.config.group=DEV_GROUP、spring.cloud.nacos.config.namespace=31398485-c414-45d1-9f0c-426011114fa5），都不要配置在应用的bootstrap.properties中。而是在发布脚本的启动命令中，用-Dspring.profiles.active=DEV`的方式来动态指定，会更加灵活！。

加载多个配置

我们已经知道Spring应用对Nacos中配置内容的对应关系是通过下面三个参数控制的：

• spring.cloud.nacos.config.prefix
• spring.cloud.nacos.config.file-extension
• spring.cloud.nacos.config.group

默认情况下，会加载Data ID=${spring.application.name}.properties，Group=DEFAULT_GROUP的配置。

假设现在有这样的一个需求：我们需要从application.yml中读取应用启动端口，然后从nacos-provider.yml获取业务性配置，那么我们就可以这样配置：

1. 如下配置

在nacos-provider.yml增加：

test: nacos-provider.yml

在application.yml增加：

server:
  port: 9999

2. 在Spring Cloud应用中通过使用spring.cloud.nacos.config.ext-config参数来配置要加载的这两个配置内容

   

3. 这时候我们访问地址就可以看到

   

可以看到，spring.cloud.nacos.config.ext-config配置是一个数组List类型。每个配置中包含三个参数：data-id、group，refresh；前两个不做赘述，与Nacos中创建的配置相互对应，refresh参数控制这个配置文件中的内容时候支持自动刷新，默认情况下，只有默认加载的配置才会自动刷新，对于这些扩展的配置加载内容需要配置该设置时候才会实现自动刷新。

共享配置

通过上面加载多个配置的实现，实际上我们已经可以实现不同应用共享配置了。但是Nacos中还提供了另外一个便捷的配置方式，比如下面的设置与上面使用的配置内容是等价的：

• spring.cloud.nacos.config.shared-dataids参数用来配置多个共享配置的Data Id，多个的时候用用逗号分隔
• spring.cloud.nacos.config.refreshable-dataids参数用来定义哪些共享配置的Data Id在配置变化时，应用中可以动态刷新，多个Data Id之间用逗号隔开。如果没有明确配置，默认情况下所有共享配置都不支持动态刷新

配置加载的优先级

当我们加载多个配置的时候，如果存在相同的key时，我们需要深入了解配置加载的优先级关系。

在使用Nacos配置的时候，主要有以下三类配置：

• A: 通过spring.cloud.nacos.config.shared-dataids定义的共享配置
• B: 通过spring.cloud.nacos.config.ext-config[n]定义的加载配置
• C: 通过内部规则（spring.cloud.nacos.config.prefix、spring.cloud.nacos.config.file-extension、spring.cloud.nacos.config.group这几个参数）拼接出来的配置

优先级关系是：A < B < C