一、前言

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

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

应用系统定制开发这个时候你如果问题，应用系统定制开发那如何落地呢？

不少人，应用系统定制开发此时就会傻眼了！

应用系统定制开发你是不是这个样子呢？

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

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

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

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

魔法值的优点是：

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

缺点：

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

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

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

二、namespace和group的不规范

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

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

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

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

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

三、我的评论

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

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

关于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建议采用的是.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: entryAction: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的扩展配置文件或共享配置文件的配置。这个不在本文的讨论访问之内，感兴趣的可以自行百度。

应用系统定制开发SpringCloud的nacos多项目、多环境的命名空间和分组配置