本文主要是介绍Nacos Config 配置中心支持配置共享,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
文章目录
- 一、什么是配置中心
- 二、Nacos Config
- 2.1 Nacos Config 工作原理 (★)
- 2.2 Nacos Config 的使用
- 2.3 动态刷新
- 2.4 配置共享
- 2.4.1 同一个微服务的不同环境之间共享配置
- 2.4.2 不同微服务中间共享配置
一、什么是配置中心
微服务架构下关于配置文件的存在以下问题:
- 配置文件相对分散。在一个微服务架构下,配置文件会随着微服务的增多变的越来越多,而且分散在各个微服务中,不好统⼀配置和管理。
- 配置文件无法区分环境。微服务项目可能会有多个环境,例如:测试环境、预发布环境、⽣产环境。每⼀个环境所使用的配置理论上都是不同的,⼀旦需要修改,就需要我们去各个微服务下手动维护,这比较困难。
- 配置文件⽆法实时更新。我们修改了配置文件之后,必须重新启动微服务才能使配置⽣效,这对一个正在运行的项目来说是非常不友好的。
配置中心的思路是:
首先把项目中各种配置全部都放到一个集中的地方进行统一管理,并提供一套标准的接口。
当各个服务需要获取配置的时候,就来配置中心的接口拉取自己的配置。
当配置中心中的各种参数有更新的时候,也能通知到各个服务实时的过来,同步最新的信息,动态更新。
当加入了服务配置中心之后,我们的系统架构图会变成下面这样:
二、Nacos Config
Nacos 作为 SpingCloud Alibaba 技术栈中的一个组件,除了可以作为服务中心以外,也可直接服务的配置中心。
2.1 Nacos Config 工作原理 (★)
使用 nacos 作为配置中心,就是将 nacos 当做一个服务端,将各个微服务看成是客户端,我们将各个微服务的配置文件统一存放在 nacos 上,然后各个微服务从 nacos 上拉取配置即可。具体的工作详情如下图所示:
bootstrap 配置和 application 都是 SpringBoot 的配置文件,bootstrap 一般存储系统级别的参数,application 一般用于定义应用级别的参数,并且 bootstrap 加载的时间相比于application更早。
优先级:
在同一级目录下,会先比较前缀 bootstrap、application,其中 bootstrap 比 application 的优先级高,其次再去比较后缀.properties .yml,其中.properties 比 .yml 优先级高。
所以它们的执行顺序如下:bootstrap.properties > bootstrap.yml > application.properties > application.yml
配置覆盖:
- 当同一个配置属性在
bootstrap.properties
和bootstrap.yml
文件中都存在时,那么properties
中的配置会被加载,而忽略 yml 文件中的配置,即优先级高的配置覆盖优先级低的配置,不同配置相互互补。此处application(.properties/yml)
同理。 - 当同一配置在
bootstrap
和application
中都存在时,那么虽然优先加载bootstrap
但是会被applicatioin
中的配置 覆盖,此时则变成了低优先级覆盖高优先的配置。 - 当同一个配置属性在四种配置(
bootstrap.properties
、bootstrap.yml
、application.properties
、application.yml
)都存在,application.properties
里的配置一定是会覆盖其他配置文件。首先遵循第二点:虽然优先加载bootstrap但是会被applicatioin
中的配置覆盖,这时候就只剩application.yml
、application.properties
了,此时遵循第一点:即优先级高的配置覆盖优先级低的配置,所以application.properties
的配置文件会覆盖其他配置文件。
参考:https://blog.csdn.net/qq_60264381/article/details/130248941
2.2 Nacos Config 的使用
1、搭建 nacos 注册中心环境
2、在商品微服务中引入nacos Config的依赖
<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>
3、在微服务中添加 bootstrap.yml 配置文件,不用原来的 application.yml
spring:application:name: product-servicecloud:nacos:config:server-addr: 127.0.0.1:8848 # nacos中⼼地址file-extension: yaml # 配置⽂件格式profiles:active: dev # 环境标识
4、在 nacos 中添加配置,然后把商品微服务原 application.yml 配置复制到配置内容中。
6、如果依旧可以成功访问程序,说明我们 nacos 的配置中心功能已经实现
2.3 动态刷新
需要在需要刷新的类上加 @RefreshScope
注解,以支持当前类动态刷新。具体案例如下:
@RestController
@RefreshScope
public class NacosConfigController {@Value("${appConfig.name}")private String appConfigName;@RequestMapping("/nacosConfig1")public String nacosConfig(){return "远程信息:"+appConfigName;}
}
此时当在配置中心修改 ${appConfig.name}
,再次访问接口即可发生变化。
注:动态刷新只支持部分属性,有些属性不可动态刷新如端口号等。
2.4 配置共享
当配置越来越多的时候,我们就发现有很多配置是重复的,这时候就考虑将公共配置⽂件提取出来,然后实现共享。
2.4.1 同一个微服务的不同环境之间共享配置
如果想在同一个微服务的不同环境之间实现配置共享(如:product-service-dev.yaml
、product-service-test.yaml
)。只需要提取一个以 spring.application.name
命名的配置文件,然后将其所有环境的公共配置放在里面即可。
1、新建一个名为 product-service.yaml
配置存放商品微服务的公共配置,把之前的公共配置都存放进去。
2、新建⼀个名为 product-service-test.yaml
配置存放测试环境的配置。
3、新建⼀个名为 product-service-dev.yaml
配置存放测试环境的配置。
4、需要的配置信息具体如下:
5、通过修改环境,参看是否可以读取公共配置和环境独有配置
2.4.2 不同微服务中间共享配置
不同微服务之间实现配置共享的原理类似于文件引入,就是定义⼀个公共配置(如:redis-config.yaml
),然后在当前配置中引入。
1、在 nacos 中定义一个 DataID
为 global-config.yaml
的配置,用于所有微服务共享。
2、修改bootstrap.yaml
spring:application:name: product-servicecloud:nacos:config:server-addr: 127.0.0.1:8848 # nacos中⼼地址file-extension: yml # 配置⽂件格式shared-configs:- data-id: global-config.yaml # 配置要引⼊的配置refresh: true # 是否支持该文件的动态刷新,默认不支持falseprofiles:active: dev # 环境标识
3、重启测试即可
文章参考:Java微服务商城高并发秒杀项目实战|Spring Cloud Alibaba真实项目实战+商城双11秒杀+高并发+消息+支付+分布式事物Seata
这篇关于Nacos Config 配置中心支持配置共享的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!