一、前言

二、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的问题来说一说。

魔法值的优点是：

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

缺点：

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

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

其实我们看魔法值的问题，真的不是很大。但是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=devspring.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多项目、多环境的命名空间和分组配置相关推荐

Springcloud+Seata+nacos 分布式事务项目搭建 AT模式
前言本文要求对Springcloud有一定了解,对分布式事务本身有一定认知,如果不了解微服务,建议先看看Spring Cloud的基本认识和使用Spring Cloud的基本教程,再回头学习本文为 ...
springCloud集成nacos
之前项目中用的apollo,需要换成nacos做配置和注册中心.[先将erueka的jar包依赖从pom文件移除,否则会有冲突报错] nacos文档地址:https://nacos.io/zh-cn/ ...
SpringCloud学习之（十八）SpringCloud Alibaba Nacos服务注册和配置中心
文章目录 (十八)SpringCloud Alibaba Nacos服务注册和配置中心 1.Nacos简介 1.1 为什么叫Nacos 1.2 Nacos是什么 1.3 Nacos能干嘛 1.4 Na ...
SpringCloud入门总结 + 使用SpringCloud搭建微服务项目
SpringCloud 1.认识微服务 2.认识spring Cloud 3.Spring Cloud Eureka 服务发现框架 3.1认识Eureka 3.2 实战--开发并部署Eureka Se ...
SpringCloud读取Nacos配置中心报错：Could not resolve placeholder ‘xxx’ in value ‘${xxx}
hello,我是灰小猿,一个超会写bug的程序员! 近期在写一个spring cloud Alibaba读取Nacos配置中心远程配置文件的内容时,出现了几个比较坑的bug,在此记录一下,帮大家避避坑 ...
SpringCloud - 整合Nacos启动报错Consider defining a bean of type IClientConfig
SpringCloud - 整合Nacos启动报错Consider defining a bean of type IClientConfig 前言一. 尝试解决Bug的几种不合适方案 1.1 添加 ...
SpringCloud使用Nacos服务发现实现远程调用
本文使用SpringCloud结合Nacos服务发现,Feign远程调用做一个简单的Demo. 1 Nacos 关于Nacos之前写了两篇文章关于SpringBoot对它的使用,感兴趣可以查看一下. ...
用 cooking 搭建一个简单又优雅的 Vue 项目开发环境 (入门篇)
本文适合 Vue 的初学者,以及对 webpack 不熟悉的同学阅读.前提是你要会用基本的命令行. Node 和 NPM,以及掌握 ES2015 的基础知识.本文都是在 macOS 环境下运行,要求使 ...
windows10下使用virtualenv虚拟技术，管理多个python版本，多个项目包环境
windows10下使用virtualenv虚拟技术,管理多个python解释器版本,多个项目包环境文章目录 windows10下使用virtualenv虚拟技术,管理多个python解释器版本,多 ...

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

一、前言

二、namespace和group的不规范

三、我的评论

四、官网

1.命名空间

2.Data ID

3.配置分组

五、我的方案

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

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

第三，我的做法

六、注意事项

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

2.取消了bootstrap

3.新特性及其使用

七、总结

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

最新文章

热门文章