SpringCloud的nacos多项目、多环境的命名空间和分组配置

关于nacos的多环境多项目的问题，网上很多说的都不到位，或者说，根本不具备实际生产使用的方式。
这篇文章整体上还是说的比较清楚的，重要的是生产上使用也没啥大问题，而网上很多文章讲的也就是自己玩的demo而已，生产上根本用不了。
不过这里有个问题，多租户多环境多项目的情况下，namespace以租户名字命名的方式个人感觉不是一个很好的方式，在nacos上的配置管理页面上，命名空间是一栏显示的，如果是以租户名字显示，如果公司人多，项目多，会有很多，根本难以显示出来，而且到时候会很难查找。我对租户的理解不深入，不敢妄加评论，不知道是否合理？
个人感觉，以namespace来区分不同环境，以group来区分不同项目或者说项目组最合适。区分环境这个不说了。区分项目的或项目组的，可以建一个项目组的分组，里面存放的不一定只是这一个项目，而是一组项目，比如一个具体某一块业务拆分成多个项目，那么这几个项目可以放在一个分组下。其他的比如，网关、用户鉴权等可以放一个分组，一些基础功能模块按照业务逻辑分为不同的分组，领完如果公司业务比较多，可以分不同的分组。这样下来，一、命名空间不会太多，方便查看每个命名空间下的配置或服务；二、事先建好命名空间，不来回变动，也剩的来回折腾；三、在查找不同的配置时可以通过分组来查找，或者直接dataId查找，也方便；四、查看不同服务时，可以通过服务名称或分组，同三是一样的道理。
至于文章中说的，多租户的情况，一个人负责很多个项目，那每个人负责的项目他自己肯定清楚的，有了不同的namespace，他就可以去对应的环境找到对应的项目去测试，解决问题。
至于有人担心的，项目多了，在某一个指定环境，比如uat环境，会担心不方便。其实这个完全多余。首先，可以直接搜索对应的服务或dataId，直接查找，也可以通过分组来查找，至于说多的问题，你管它干嘛，只看自己的就行了嘛！
文章中说的以租户的名字来命名空间的，还有个问题，这是要写到代码中的，张三来了，建一个，等张三走了，李四来了，也要建一个吗？那项目已经上线的张三这个命名空间咋办呢？到时候项目运行几年得多少啊？如果说不新建，让李四用张三的，那李四负责的项目未必就和张三负责的一样多，到时候一样混乱。不知道作者怎么看？还有，把人名写在项目中，这个。。。

四、官网

我们看nacos官网的说法。

1.命名空间

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

一句话：不同环境的配置的区分隔。

2.Data ID

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

3.配置分组

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

一句话：默认DEFAULT_GROUP，配置分组的常见场景：不同的应用或组件使用了相同的配置类型，如 database_url 配置和 MQ_topic 配置。

综合以上，我们得出结论：

通过namespace来区分不同的环境，通过group来区分不同的应用或组件或项目，通过DataID来区分不同的项目。

五、我的方案

结合我对本文引用的那篇文章的评论，个人看法如下面的表格：

DEV		SIT		UAT		PRD
服务	分组	服务	分组	服务	分组	服务	分组
a-service	BIZ_ GROUP	a-service	BIZ_ GROUP	a-service	BIZ_ GROUP	a-service	BIZ_ GROUP
b-service	BASE_ GROUP	b-service	BASE_ GROUP	b-service	BASE_ GROUP	b-service	BASE_ GROUP
c-service	USER_ GROUP	c-service	USER_ GROUP	c-service	USER_ GROUP	c-service	USER_ GROUP
d-service	USER_ GROUP	d-service	USER_ GROUP	d-service	USER_ GROUP	d-service	USER_ GROUP
e-service	BIZ_ GROUP	e-service	BIZ_ GROUP	e-service	BIZ_ GROUP	e-service	BIZ_ GROUP

下面我们就这个表格做一个解读。

第一行是namespace，通过DEV/SIT/UAT/PRD来区分不同的环境，对应项目中nacos的namespace。在springboot2.6之前，nacos建议采用的是bootstrap.yml或bootstrap.properties方式进行nacos注册于发现的配置。

首先，在bootstrap.properties文件中指定环境

spring.profiles.active=dev

在springboot2.4之前是采用以上方式指定的，但是在springboot2.4（含）以后，采用这种方式是不生效的，而是更改为了：

spring.config.activate.on-profile=dev

然后，在bootstrap.properties文件中指定namespace和group

spring.cloud.nacos.discovery.namespace=${NACOS_NAMESPACE}

spring.cloud.nacos.config.namespace=${NACOS_NAMESPACE}

spring.cloud.nacos.config.group=${NACOS_GROUP:DEFAULT_GROUP}

以上三个，分别指的是服务发现的namespace——也就是服务的namespace、配置中心的namespace、和配置的group。

前两者一般我们设为一样的即可，对应我们上面表格的DEV/SIT/UAT/PRD，以此来区分不同开发环境。

第三，我的做法

我这里采用了${NACOS_NAMESPACE}的取值，是因为这个取值是在pom文件中自定义的，如下：

如果你项目中有定义四个开发环境，写四个profile即可。这样就不用写多个properties文件了，不管是application.properties、application-dev.properties、application-sit.properties、application-uat.properties、application-prd.properties，或者是bootstrap.properties、bootstrap-dev.properties、bootstrap-sit.properties、bootstrap-uat.properties、bootstrap-prd.properties。

这两种多环境的配置文件，完全不需要了。通过pom文件中单 profiles标签定义多个profile——也就是多个环境，然后在bootstrap.properties中配置对应的profile环境，然后加上对应的服务注册与发现的配置即可。

spring.profiles.active=dev
# spring.config.activate.on-profile=dev

spring.application.name=${artifactId}
spring.cloud.nacos.discovery.namespace=${NACOS_NAMESPACE}
spring.cloud.nacos.discovery.server-addr=${NACOS_ADDR}
spring.cloud.nacos.config.namespace=${NACOS_NAMESPACE}
spring.cloud.nacos.config.server-addr=${NACOS_ADDR}
# 本地启动服务，请使用DEV_GROUP
spring.cloud.nacos.config.group=${NACOS_GROUP:DEV_GROUP}

六、注意事项

1.namespace指的是id不是名称。

如果不指定id的话自动生成一段字符串，建议配置好id，这样在配置文件中也清楚，当前是哪个namespace。

2.取消了bootstrap

另外，在最新版的spring boot上，bootstrap这种方式的配置被取消了，而是采用了application.yml或properties的方式。

版本对应关系：

<dependencyManagement>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-dependencies</artifactId>
        <version>2.6.3</version>
        <type>pom</type>
        <scope>import</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-dependencies</artifactId>
        <version>2021.0.1</version>
        <type>pom</type>
        <scope>import</scope>
    </dependency>
    <dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-alibaba-dependencies</artifactId>
        <version>2021.0.1.0</version>
        <type>pom</type>
        <scope>import</scope>
    </dependency>
</dependencyManagement>

以上是SCA官方给出的一个比较新的版本的对应关系。

以下内容来源官网

注意事项： spring-cloud-starter-alibaba-nacos-config 模块移除了 spring-cloud-starter-bootstrap 依赖，如果你想以旧版的方式使用，你需要手动加上该依赖，现在推荐使用 spring.config.import 方式引入配置

完成以上步骤就能无缝切换到 spring cloud alibaba 2021.0.1.0 版本

3.新特性及其使用

支持 spring.config.import

这里假设有一个配置文件(bootstrap.yml)，升级到新版本应该怎么配置呢

# bootstrap.yml
spring:
cloud:
nacos:
config:
name: test.yml
group: DEFAULT_GROUP
server-addr: 127.0.0.1:8848
extension-configs:
- dataId: test01.yml
group: group_01
- dataId: test02.yml
group: group_02
refresh: false

这两个配置是等价的

# application.yml
spring:
cloud:
nacos:
config:
group: DEFAULT_GROUP
server-addr: 127.0.0.1:8848
config:
import:
- optional:nacos:test.yml # 监听 DEFAULT_GROUP:test.yml
- optional:nacos:test01.yml?group=group_01 # 覆盖默认 group，监听 group_01:test01.yml
- optional:nacos:test02.yml?group=group_02&refreshEnabled=false # 不开启动态刷新
- nacos:test03.yml # 在拉取nacos配置异常时会快速失败，会导致 spring 容器启动失败

注意事项:

如果使用 spring.config.import 就不能使用 bootstrap.yml/properties 引入配置的方式了 !!!
如果引入了 spring-cloud-starter-alibaba-nacos-config，并且使用 import 方式导入配置, 项目启动时会自动检测是否引入了 nacos: 条目，如果没有 import nacos 条目，会出现如下错误：

The spring.config.import property is missing a nacos: entry

Action:

Add a spring.config.import=nacos: property to your configuration.
	If configuration is not required add spring.config.import=optional:nacos: instead.
	To disable this check, set spring.cloud.nacos.config.import-check.enabled=false.

至此，关于新版本的改动的一些东西也说完了。

七、总结

正如我们在给本文引用的一篇文章写的评论说的那样。

多租户情况，本人不甚了解，不多置喙；
即便如此，如果以租户名字作为namespace，也具有很多问题；
namespace用来做环境隔离，而非项目隔离，是比较好的方案；
group用来做项目或者一组项目的隔离，是比较合适的；
不同的namespace采用项目名+环境+后缀来区分，如，order-service-dev.yml，order-service-uat.yml等；
以上所说都是在nacos上的配置文件和服务，而不是springboot项目中的配置文件；
采用了nacos之后，基本上配置文件就不怎么需要了，只需要一些profile环境、端口（其实也可以放到nacos上）、nacos配置信息等，其余的配置都可以放到nacos上；
大多数配置项都可以放到nacos对应的服务名+环境的配置文件中，比如，order-service-dev.yml，但是可能这个项目还需要另外的配置文件，或者说老项目拆分后有多个配置文件，都在项目中使用，不便于合并到一个配置文件中，一样可以再建这些配置文件到nacos上，只是不是系统本身的配置文件，需要用到nacos的扩展配置文件或共享配置文件的配置。这个不在本文的讨论访问之内，感兴趣的可以自行百度。

北冥牧之

关注

13
点赞
踩
43

收藏

觉得还不错? 一键收藏
打赏
18
评论
SpringCloud的nacos多项目、多环境的命名空间和分组配置

用过SpringCloudAlibaba的小伙伴都知道nacos的配置有一个namespace和group的概念，这两个概念的字面意思都很容易理解，但是实际项目中使用起来，却不是那么回事了。这就好比，你面试的时候问一个人，分布式事务的解决方式有哪些，他可能会告诉你两阶段提交、三阶段提交等等，然后针对各个方式是如何实现的、原理是什么，说的也很清楚。这个时候你如果问题，那如何落地呢？不少人，此时就会傻眼了！你是不是这个样子呢？
复制链接

扫一扫