nacos 首先它是用java写的其实就是一个springboot工程,它功能有很多,这里我们主要了解一下nacos 的服务发现和配置管理功能。
nacos 是阿里的开源项目,应用于微服务,微服务是将单体应用拆分成一个个服务节点,nacos主要功能是服务发现和微服务的配置集中管理。
配置管理
理解配置中心
什么是配置?
应用程序在启动和运行的时候往往需要读取一些配置信息,配置基本上伴随着应用程序的整个生命周期,比如:数据库连接参数、启动参数等。
配置主要有以下几个特点:
- 配置是独立于程序的只读变量
配置对于程序是只读的,程序通过读取配置来改变自己的行为,但是程序不应该去改变配置
- 配置伴随应用的整个生命周期
配置贯穿于应用的整个生命周期,应用在启动时通过读取配置来初始化,在运行时根据配置调整行为。比如:启动时需要读取服务的端口号、系统在运行过程中需要读取定时策略执行定时任务等。
- 配置可以有多种加载方式
常见的有程序内部hard code,配置文件,环境变量,启动参数,基于数据库等
- 配置需要治理
同一份程序在不同的环境(开发,测试,生产)、不同的集群(如不同的数据中心)经常需要有不同的配置,所以需要有完善的环境、集群配置管理
什么是配置中心
在微服务架构中,当系统从一个单体应用,被拆分成分布式系统上一个个服务节点后,配置文件也必须跟着迁移(分割),这样配置就分散了,不仅如此,分散中还包含着冗余,如下图:
假设这时候你有很多服务,然后你这时候分别对每个服务进行配置文件的管理,这时候你就会发现配置文件是冗余的,而且每个服务会有多个实例,这时候你就发现,配置文件特别的分散,所以基于微服务开发的化,需要一个配置中心集中去管理配置
下图是配置中心的功能图
配置中心的服务流程如下:
1、用户在配置中心更新配置信息。
2、服务A和服务B及时得到配置更新通知,从配置中心获取配置。
总得来说,配置中心就是一种统一管理各种应用配置的基础服务组件
配置中心是微服务化不可缺少的一个系统组件,在这种背景下中心化的配置服务即配置中心应运而生,一个合格的配置中心需要满足如下特性:
- 配置项容易读取和修改
- 分布式环境下应用配置的可管理性,即提供远程管理配置的能力
- 支持对配置的修改的检视以把控风险
- 可以查看配置修改的历史记录
- 不同部署环境下应用配置的隔离性
Nacos配置管理
发布配置
首先在nacos发布配置,nacos-restful-consumer服务从nacos读取配置。
浏览器访问 http://127.0.0.1:8848/nacos,
打开nacos控制台,并点击菜单配置管理->配置列表:
在Nacos添加如下的配置:
nacos-restful-consumer:
Namespace: public
Data ID: nacos‐restful‐consumer.yaml
Group : DEFAULT_GROUP
配置格式: YAML
配置内容: common:
name: application1 config
这样一个简单的配置就发布成功了
获取配置
用spring的注解就可以实现
在nacos-restful-consumer工程的controller中增加获取配置的web访问端点/configs,通过标准的spring @Value方式。但这种方式 ,是静态的
@Value("${common.name}")
private String common_name;
@GetMapping(value = "/configs")
public String getvalue(){
return common_name;
}
当然要添加naco配置管理的客户端
要想从配置中心获取配置添加nacos-config的依赖
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring‐cloud‐starter‐alibaba‐nacos‐config</artifactId>
</dependency>
我们要想让nacos知道从哪获取配置,我们需要在bootstrap.yml添加配置
spring:
cloud:
nacos:
config:
server‐addr: 127.0.0.1:8848 # 配置中心地址
file‐extension: yaml
group: DEFAULT_GROUP
注意:要使用配置中心就要在bootstrap.yml中来配置,bootstrap.yml配置文件的加载顺序要比application.yml要优先。
折摸着就能根据application.name和扩展名,就能让nacos找到nacos配置管理中心的这个yaml文件
基于上面的例子,若要实现配置的动态更新,只需要进行如下改造
// 注入配置文件上下文
@Autowired
private ConfigurableApplicationContext applicationContext;
@GetMapping(value = "/configs")
public String getConfigs(){
return applicationContext.getEnvironment().getProperty("common.name");
}
配置管理模型
Nacos抽象定义了Namespace、Group、Data ID的概念,具体这几个概念代表什么,取决于我们把它们看成什
么,这里推荐给大家一种用法,如下图:
Namespace:代表不同环境,如开发、测试、生产环境。
Group:代表某项目,如XX医疗项目、XX电商项目
DataId:每个项目下往往有若干个工程,每个配置集(DataId)是一个工程的主配置文件
自定义扩展的 Data Id 配置
了解扩展配置文件得优先级问题
ext-config扩展配置
pring Cloud Alibaba Nacos Config可支持自定义 Data Id 的配置。 一个完整的配置案例如下所示:
可以看到:
通过 spring.cloud.nacos.config.ext-config[n].data-id 的配置方式来支持多个 Data Id 的配置。
通过 spring.cloud.nacos.config.ext-config[n].group 的配置方式自定义 Data Id 所在的组,不明确 配置的话,默认是 DEFAULT_GROUP。
我们也可以发现扩展配置我们是用数组表示得。这点要注意,因为这里边有优先级问题
通过测试发现:
扩展配置优先级是 spring.cloud.nacos.config.ext-config[n].data-id 其中 n 的值越大,优先级越高。
通过内部相关规则(应用名、扩展名 )自动生成相关的 Data Id 配置的优先级最大。然后主配置文件优于扩展文件配置