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

目录

一、前言

二、namespace和group的不规范

三、我的评论

四、官网 

1.命名空间

2.Data ID

 3.配置分组

五、我的方案

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

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

第三，我的做法

六、注意事项

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

2.取消了bootstrap

3.新特性及其使用

七、总结

---

一、前言

用过SpringCloudAlibaba的小伙伴都知道nacos的配置有一个namespace和group的概念，这两个概念的字面意思都很容易理解，但是实际项目中使用起来，却不是那么回事了。

这就好比，你面试的时候问一个人，分布式事务的解决方式有哪些，他可能会告诉你两阶段提交、三阶段提交等等，然后针对各个方式是如何实现的、原理是什么，说的也很清楚。

这个时候你如果问题，那如何落地呢？

不少人，此时就会傻眼了！

你是不是这个样子呢？

那这个namespace和group其实和上面我们讲解的小案例是同样的道理，只不过namespace和group实际落地也简单一些，只是规范与否的问题。

有些小伙伴可能会讲，稍微不那么规范也没啥问题，就像我们代码中一般不能有魔法值，但是大多数项目都会有的，甚至不少知名开源项目也是如此。

有这个思路的小伙伴，说明是真的有在思考，恭喜你！

我们拿代码中的魔法值和namespace与group的问题来说一说。

魔法值的优点是：

1. 简单、便捷；
2. 开发效率高；
3. 直观，一眼就知道这是个什么东西。

缺点：

1. 维护性差，一旦有修改，需要查找并一一修改；
2. 不够优雅；
3. 维护时容易出错。

魔法值的优缺点大体如此，不必较真。

其实我们看魔法值的问题，真的不是很大。但是namespace和group的话就不一定了。

二、namespace和group的不规范

如果是小公司小团队，或者说少数几个项目有自己独立的nacos，那怎么玩都影响不大，这个其实就和我们平时自己玩的demo基本一个调子，只不过项目中的更真实一点而已。

但是如果真的是在生产上使用，而且是整个公司的nacos集群的话，而且不是小项目、小团队的话，这个就有必要认真考虑一下了。因为一旦规范定下来了，后面再变更，是一个很麻烦的事情，整个公司的项目都要跟着做变更，你未必能说服领导或者说服对方配合你，那你就gg了。

如果不规范，会产生一些问题，会比较麻烦，后面我们慢慢说。

因为公司最近再做这一块，本人原本对namespace和group的理解也不是很深入，总觉得公司的这个做法有问题，所以就网上看了不少文章，查阅了资料，算是有一些个人的看法，以飨诸位小伙伴。

网上那种不适合多项目、多环境的配置我们就不说了，我们只说适合生产的多项目、多环境的配置方式。

三、我的评论

这里有一篇文章，讲解的不错，但是也未必是很准确。

https://blog.csdn.net/m0_54852680/article/details/122170936

 在这篇文章中，我给出了我的看法，放在下面。

关于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的方式。

版本对应关系：

    
        org.springframework.boot
        spring-boot-dependencies
        2.6.3
        pom
        import
    
    
        org.springframework.cloud
        spring-cloud-dependencies
        2021.0.1
        pom
        import
    
    
        com.alibaba.cloud
        spring-cloud-alibaba-dependencies
        2021.0.1.0
        pom
        import
    

以上是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.

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

七、总结

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

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