摘要：第二步在应用的配置文件中，增加环境配置第三步启动应用，我们可以看到日志中打印了，加载的配置文件使用实现在中是用来对做集合管理的重要概念。深入思考上面我们分别利用配置管理功能中的几个不同纬度来实现多环境的配置管理。
前情回顾：
《Spring Cloud Alibaba基础教程：使用Nacos实现服务注册与发现》
《Spring Cloud Alibaba基础教程：支持的几种服务消费方式》
《Spring Cloud Alibaba基础教程：使用Nacos作为配置中心》
《Spring Cloud Alibaba基础教程：Nacos配置的加载规则详解》
通过之前两篇对Nacos配置管理功能的介绍，已经学会了在Nacos中如何加入配置以及Spring Cloud应用如何通过配置来加载到对应的内容。接下来，我们讨论一个在使用配置中心时，都需要关注的一个问题：多环境的配置如何实现与管理？
多环境管理在Nacos中，本身有多个不同管理级别的概念，包括：Data ID、Group、Namespace。只要利用好这些层级概念的关系，就可以根据自己的需要来实现多环境的管理。
下面，我就来介绍一下，可以使用的几种实现方式：
使用Data ID与profiles实现Data ID在Nacos中，我们可以理解为就是一个Spring Cloud应用的配置文件名。通过上一篇《Spring Cloud Alibaba基础教程：Nacos配置的加载规则详解》，我们知道默认情况下Data ID的名称格式是这样的：${spring.application.name}.properties，即：以Spring Cloud应用命名的properties文件。
实际上，Data ID的规则中，还包含了环境逻辑，这一点与Spring Cloud Config的设计类似。我们在应用启动时，可以通过spring.profiles.active来指定具体的环境名称，此时客户端就会把要获取配置的Data ID组织为：${spring.application.name}-${spring.profiles.active}.properties。
实际上，更原始且最通用的匹配规则，是这样的：${spring.cloud.nacos.config.prefix}-${spring.profile.active}.${spring.cloud.nacos.config.file-extension}。而上面的结果是因为${spring.cloud.nacos.config.prefix}和${spring.cloud.nacos.config.file-extension}都使用了默认值。
动手试一试
我们可以用《Spring Cloud Alibaba基础教程：使用Nacos作为配置中心》一文中的列子（可在文末仓库中获取）为基础，体验一下这种区分环境的配置方式。
第一步：先在Nacos中，根据这个规则，创建两个不同环境的配置内容。比如：
如上图，我们为alibaba-nacos-config-client应用，定义了DEV和TEST的两个独立的环境配置。我们可以在里面定义不同的内容值，以便后续验证是否真实加载到了正确的配置。
第二步：在alibaba-nacos-config-client应用的配置文件中，增加环境配置：spring.profiles.active=DEV
第三步：启动应用，我们可以看到日志中打印了，加载的配置文件：
2019-01-30 15:25:18.216 INFO 96958 --- [ main] o.s.c.a.n.c.NacosPropertySourceBuilder : Loading nacos data, dataId: "alibaba-nacos-config-client-DEV.properties", group: "DEFAULT_GROUP"使用Group实现
Group在Nacos中是用来对Data ID做集合管理的重要概念。所以，如果我们把一个环境的配置视为一个集合，那么也就可以实现不同环境的配置管理。对于Group的用法并没有固定的规定，所以我们在实际使用的时候，需要根据我们的具体需求，可以是架构运维上对多环境的管理，也可以是业务上对不同模块的参数管理。为了避免冲突，我们需要在架构设计之初，做好一定的规划。这里，我们先来说说如何用Group来实现多环境配置管理的具体实现方式。
动手试一试
第一步：先在Nacos中，通过区分Group来创建两个不同环境的配置内容。比如：
如上图，我们为alibaba-nacos-config-client应用，定义了DEV环境和TEST环境的两个独立的配置，这两个匹配与上一种方法不同，它们的Data ID是完全相同的，只是GROUP不同。
第二步：在alibaba-nacos-config-client应用的配置文件中，增加Group的指定配置：spring.cloud.nacos.config.group=DEV_GROUP
第三步：启动应用，我们可以看到日志中打印了，加载的配置文件：
2019-01-30 15:55:23.718 INFO 3216 --- [main] o.s.c.a.n.c.NacosPropertySourceBuilder : Loading nacos data, dataId: "alibaba-nacos-config-client.properties", group: "DEV_GROUP"使用Namespace实现
Namespace在本系列教程中，应该还是第一次出现。先来看看官方的概念说明：用于进行租户粒度的配置隔离。不同的命名空间下，可以存在相同的Group或Data ID的配置。Namespace的常用场景之一是不同环境的配置的区分隔离，例如：开发测试环境和生产环境的资源（如配置、服务）隔离等。
在官方的介绍中，就介绍了利用其可以作为环境的隔离使用，下面我们就来试一下吧！
动手试一试
第一步：先在Nacos中，根据环境名称来创建多个Namespace。比如：
第二步：在配置列表的最上方，可以看到除了Public之外，多了几个刚才创建的Namepsace。分别在DEV和TEST空间下为alibaba-nacos-config-client应用创建配置内容：
第三步：在alibaba-nacos-config-client应用的配置文件中，增加Namespace的指定配置，比如：spring.cloud.nacos.config.namespace=83eed625-d166-4619-b923-93df2088883a。
这里需要注意namespace的配置不是使用名称，而是使用Namespace的ID。
第四步：启动应用，通过访问localhost:8001/test接口，验证一下返回内容是否正确。这种方式下，目前版本的日志并不会输出与Namespace相关的信息，所以还无法以此作为加载内容的判断依据。
深入思考上面我们分别利用Nacos配置管理功能中的几个不同纬度来实现多环境的配置管理。从结果上而言，不论用哪一种方式，都能够胜任需求，但是哪一种最好呢？
第一种：通过Data ID与profile实现。
优点：这种方式与Spring Cloud Config的实现非常像，用过Spring Cloud Config的用户，可以毫无违和感的过渡过来，由于命名规则类似，所以要从Spring Cloud Config中做迁移也非常简单。
缺点：这种方式在项目与环境多的时候，配置内容就会显得非常混乱。配置列表中会看到各种不同应用，不同环境的配置交织在一起，非常不利于管理。
建议：项目不多时使用，或者可以结合Group对项目根据业务或者组织架构做一些拆分规划。
第二种：通过Group实现。
优点：通过Group按环境讲各个应用的配置隔离开。可以非常方便的利用Data ID和Group的搜索功能，分别从应用纬度和环境纬度来查看配置。
缺点：由于会占用Group纬度，所以需要对Group的使用做好规划，毕竟与业务上的一些配置分组起冲突等问题。
建议：这种方式虽然结构上比上一种更好一些，但是依然可能会有一些混乱，主要是在Group的管理上要做好规划和控制。
第三种：通过Namespace实现。
优点：官方建议的方式，通过Namespace来区分不同的环境，释放了Group的自由度，这样可以让Group的使用专注于做业务层面的分组管理。同时，Nacos控制页面上对于Namespace也做了分组展示，不需要搜索，就可以隔离开不同的环境配置，非常易用。
缺点：没有啥缺点，可能就是多引入一个概念，需要用户去理解吧。
建议：直接用这种方式长远上来说会比较省心。虽然可能对小团队而言，项目不多，第一第二方式也够了，但是万一后面做大了呢？
注意：不论用哪一种方式实现。对于指定环境的配置（spring.profiles.active=DEV、spring.cloud.nacos.config.group=DEV_GROUP、spring.cloud.nacos.config.namespace=83eed625-d166-4619-b923-93df2088883a），都不要配置在应用的bootstrap.properties中。而是在发布脚本的启动命令中，用-Dspring.profiles.active=DEV的方式来动态指定，会更加灵活！。参考资料
Nacos官方文档
代码示例本文示例读者可以通过查看下面仓库的中的alibaba-nacos-config-client项目：
Github：https://github.com/dyc87112/SpringCloud-Learning/
Gitee：https://gitee.com/didispace/SpringCloud-Learning/
如果您对这些感兴趣，欢迎star、follow、收藏、转发给予支持！
以下专题教程也许您会有兴趣Spring Boot基础教程
Spring Cloud基础教程
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/11977.html
摘要：之前开放过一台公益给大家，以方便大家在阅读我博客中教程时候做实验。由于目前在连载，所以对应的也部署了一台，并且也开放出来，给大家学习测试之用。 之前开放过一台公益Eureka Server给大家，以方便大家在阅读我博客中教程时候做实验。由于目前在连载Spring Cloud Alibaba，所以对应的也部署了一台Nacos，并且也开放出来，给大家学习测试之用。 Nacos控制台 ...
摘要：下表整理了目前的版本与版本的兼容关系还未所以，不论您是在读我的基础教程基础教程还是正在连载的系列教程。 这篇博文是临时增加出来的内容，主要是由于最近连载《Spring Cloud Alibaba基础教程》系列的时候，碰到读者咨询的大量问题中存在一个比较普遍的问题：版本的选择。其实这类问题，在之前写Spring Cloud基础教程的时候，就已经发过一篇《聊聊Spring Cloud版本的...
摘要：最近对基础教程系列的催更比较多，说一下最近的近况因为打算一起更新。再次，对于中国用户来说，还有一个非常特殊的意义它将曾经红极一时的，以及阿里巴巴的强力消息中间件融入体系。 最近对《Spring Cloud Alibaba基础教程》系列的催更比较多，说一下最近的近况：因为打算Spring Boot 2.x一起更新。所以一直在改博客Spring Boot专题页和Git仓库的组织。由于前端技...
摘要：在搭建集群之前，我们需要先修改的数据持久化配置为存储。所以，如果启动多个默认配置下的节点，数据存储是存在一致性问题的。为了解决这个问题，采用了集中式存储的方式来支持集群化部署，目前只要支持的存储。 前情回顾： 《Spring Cloud Alibaba基础教程：使用Nacos实现服务注册与发现》 《Spring Cloud Alibaba基础教程：支持的几种服务消费方式》 《Spri...
摘要：下面通过这篇，详细介绍当使用作为配置中心之后，如何实现中修改规则同步到。关于下面改造的原理和分析可以见上一篇中修改规则同步到的头两节内容，这里不重复介绍了。但是由于考虑到与的结合使用，略作修改。主要就是中存储配置的和不要弄错。 上一篇我们介绍了如何通过改造Sentinel Dashboard来实现修改规则之后自动同步到Apollo。下面通过这篇，详细介绍当使用Nacos作为配置中心之后...
阅读 3187·2021-11-24 10:30
阅读 3127·2021-11-22 15:29
阅读 3535·2021-10-28 09:32
阅读 927·2021-09-07 10:22
阅读 3137·2019-08-30 15:55
阅读 3456·2019-08-30 15:54
阅读 3349·2019-08-30 15:54
阅读 2735·2019-08-30 15:44
