您好,登录后才能下订单哦!
本篇内容主要讲解“Spring Cloud Alibaba Nacos怎么实现多环境管理”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“Spring Cloud Alibaba Nacos怎么实现多环境管理”吧!
在Nacos中,本身有多个不同管理级别的概念,包括:Data ID
、Group
、Namespace
。只要利用好这些层级概念的关系,就可以根据自己的需要来实现多环境的管理。
下面,我就来介绍一下,可以使用的几种实现方式:
Data ID
与profiles
实现Data ID
在Nacos中,我们可以理解为就是一个Spring Cloud应用的配置文件名。我们知道默认情况下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}
都使用了默认值。
动手试一试
我们可以用上一篇中的列子为基础,体验一下这种区分环境的配置方式。
第一步:先在Nacos中,根据这个规则,创建两个不同环境的配置内容。比如:
如上图,我们为alibaba-nacos-config-client
应用,定义了DEV和TEST的两个独立的环境配置。我们可以在里面定义不同的内容值,以便后续验证是否真实加载到了正确的配置。
第二步:在alibaba-nacos-config-client
应用的配置文件中,增加环境配置:spring.profiles.active=DEV
Group
实现Group
在Nacos中是用来对Data ID
做集合管理的重要概念。所以,如果我们把一个环境的配置视为一个集合,那么也就可以实现不同环境的配置管理。对于Group
的用法并没有固定的规定,所以我们在实际使用的时候,需要根据我们的具体需求,可以是架构运维上对多环境的管理,也可以是业务上对不同模块的参数管理。为了避免冲突,我们需要在架构设计之初,做好一定的规划。这里,我们先来说说如何用Group
来实现多环境配置管理的具体实现方式。
动手试一试
第一步:先在Nacos中,通过区分Group
来创建两个不同环境的配置内容。比如:
第二步:在配置列表的最上方,可以看到除了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
的方式来动态指定,会更加灵活!。
到此,相信大家对“Spring Cloud Alibaba Nacos怎么实现多环境管理”有了更深的了解,不妨来实际操作一番吧!这里是亿速云网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。