## 一、四种隔离级别 下面这张图是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 ~~~ * 服务隔离配置：微服务属于不同的namespace，彼此之间不能远程调用 * 配置隔离配置：同一个namespace下的配置文件可以为该namespace下的多个子项目共享（下文会讲），跨namespace则无法实现配置文件共享。 ## 三、Group的配置使用 分组不需要在nacos管理界面中新建，只需要在nacos客户端配置即可。 ~~~ # 服务隔离的分组group spring.cloud.nacos.discovery.group= # 配置隔离的分组group spring.cloud.nacos.config.group= ~~~ * 服务隔离配置：微服务属于不同的Group，彼此之间不能远程调用。 * 配置隔离配置：同一个namespace下面的不同Group的配置文件可以共享（下文会讲到） ## 五、配置文件共享 ### 5.1.实现思路 nacos的配置共享的思路是：一个项目可以使用多个配置文件，既然一个项目或者子项目可以使用多个配置文件，那么配置共享是不是就简单了。方法就是：我们把公有配置单独抽取为一个配置文件，如下文中的：common-datasource.yaml。  ### 5.2.一个项目使用多个配置文件(共享配置文件) 准备工作：我们把原有的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 ~~~ * 通过`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 在配置变更时，是否支持应用中可动态刷新， 感知到最新的配置值。默认是不支持的。