nacos服务配置隔离与共享

# 一、四种隔离级别

下面这张图是nacos官网讲解nacos数据模型的概念时给出的，用来理解nacos的隔离级别再好不过。

一个namespace命名空间可以包含多个分组
一个分组可以有多个子项目或者子模块的微服务
每个子项目有自己的dataid，dataId命名规则带后缀，如：xxxx-dev.yaml、xxxx-pro.yaml，可以产生对某一个子项目部署环境配置文件加载隔离的效果。（前面章节讲过）

注意：学过apollo的同学不要把apollo的namespace和nacos的namespace搞混了，apollo的namespace是用于将多个服务或项目都需要使用的共有配置放到一个namespace中，方便多个项目公共加载使用。而nacos的namespace就是一个顶级的服务配置隔离级别。

其实还有一种隔离，是上面的这张图没有体现出来的，那就是：nacos可以增加多个用户（并为用户赋权）、在这些用户下可以建立namespace。不同用户建立的namespace里面的服务肯定是不能互相访问的，配置也是隔离的。

# 二、隔离级别的使用模式

namespace没有一定的必须的隔离模式要求，你可以根据自己的情况进行隔离，比如：

一套部署环境建立一个namespace，如：开发环境、测试环境
一个研发部门建立一个namespace，如：研发一部、研发二部
一个分公司建立一个namespace，如：上海分公司、北京分公司
……

根据自己的项目情况，公司项目、组织架构、外部客户等分组特征可以灵活决定namespace的隔离模式。下面为大家举两个常见的例子：

隔离级别	举例一	举例二
namespace（一级）	一套部署环境一个namespace，如：DEV开发环境；PRO生产环境	一个公司的一个部门建立一个namespace。如：开发一部，开发二部
group（二级）	一个微服务综合项目一个组	一个微服务综合项目一个组
dataid/service（三级）	微服务配置文件xxxx.yaml、yyyy.yaml	微服务配置文件xxxx-dev.yaml、xxxx-pro.yaml来区分部署环境

group的分组模式：通常是一个微服务综合项目作为一个group，因为微服务模块之间需要互相调用，放在不同的组会产生隔离，无法彼此远程调用。

# 三、添加并使用namespace

我们假设一个需求：为XX公司的“研发一部”建议一个namespace，该部门的所有项目都注册到这个namespace 下面，并且使用这个namespace下面的配置。

首先在nacos中添加命名空间：
添加完成之后效果如下：

微服务在没有明确指定配置的情况下，默认使用的是Public命名空间。如果需要明确使用自定义的命名空间namespace，可以通过以下配置来实现：

# 配置隔离的namespace
spring.cloud.nacos.config.namespace=fd96613a-2bad-4288-806d-0a7c2b265267
# 服务隔离的namespace
spring.cloud.nacos.discovery.namespace=fd96613a-2bad-4288-806d-0a7c2b265267

1
2
3
4

服务隔离配置：微服务属于不同的namespace，彼此之间不能远程调用
配置隔离配置：同一个namespace下的配置文件可以为该namespace下的多个子项目共享，跨namespace则无法实现配置文件共享。

# 三、Group的配置使用

分组不需要在nacos管理界面中新建，只需要在nacos客户端配置即可。

# 服务隔离的分组group
spring.cloud.nacos.discovery.group=
# 配置隔离的分组group
spring.cloud.nacos.config.group=

1
2
3
4

服务隔离配置：微服务属于不同的Group，彼此之间不能远程调用。
配置隔离配置：同一个namespace下面的不同Group的配置文件可以共享

# 五、配置文件共享

# 5.1.实现思路

nacos的配置共享的思路是：一个项目可以使用多个配置文件，既然一个项目或者子项目可以使用多个配置文件，那么配置共享是不是就简单了。方法就是：我们把公有配置单独抽取为一个配置文件，如下文中的：common-datasource.yaml。

# 5.2.一个项目使用多个配置文件(共享配置文件)

# extension-configs

准备工作：我们把原有的nacos上面的aservice-rbac-dev.yml配置文件拆分成两份。

一份叫做common-datasource.yaml，放在DEFAULT_GROUP默认分组下，是数据库连接及连接池相关的配置，属于公有配置。
一份仍然叫做aservice-rbac-dev.yml，除去数据库连接外的其他的所有配置，属于子项目(服务)内部的个性化配置。

现在配置文件被拆分成了两份，aservice-rbac服务该如何使用两份配置文件？不再使用默认的dataid规则加载配置文件，可以通过如下的方法加载多个配置文件：

spring:
  application:
    name: aservice-rbac
  cloud:
    nacos:
      discovery:
        server-addr: 192.168.161.6:8848
      config:
        server-addr: ${spring.cloud.nacos.discovery.server-addr}
        extension-configs:
          - data-id: aservice-rbac-dev.yaml
            group: ZIMUG_GROUP
            refresh: true
          - data-id: common-datasource.yaml
            group: DEFAULT_GROUP
            refresh: false

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

通过spring.cloud.nacos.config.extension-configs[n].data-id的配置方式来支持多个 Data Id 的配置。
通过spring.cloud.nacos.config.extension-configs[n].group的配置方式自定义 Data Id 所在的组，不明确配置的话，默认是 DEFAULT_GROUP。
通过spring.cloud.nacos.config.extension-configs[n].refresh的配置方式来控制该 Data Id 在配置变更时，是否支持应用中可动态刷新，感知到最新的配置值。默认是不支持的。

提示

# 注意：nacos配置DataId需要将配置文件后缀加上(common-datasource.yaml)，否则会出现读取不到配置问题

上次更新: 2022/06/13, 18:30:58

← nacos客户端配置刷新 nacos配置Beta发布→