我们知道,除了代码之外,软件还有一些配置信息,比如数据库的用户名和密码,还有一些我们不想写死在代码里的东西,例如像线程池大小、队列长度等运行参数,以及日志级别、算法策略等, 还有一些是软件运行环境的参数,如Java 的内存大小,应用启动的参数,包括操作系统的一些 参数配置…… 所有这些东西,我们都叫做软件配置。以前,我们把软件配置写在一个配置文件中,就像 Windows 下的 ini 文件,或是 Linux 下的 conf 文件。然而,在分布式系统下,这样的方式就变得非常不好管理,并容易出错。假如生产环境下,项目现在正在运行,此时修改了配置文件,我们需要让这些配置生效,通常的做法是不是要重启服务。但重启是不是会带来系统服务短时间的暂停,从而影响用户体验呢,还有可能会带来经济上的很大损失(例如双11重启下服务)。基于这样的背景,配置中心诞生了。
一、概述
配置中心最基础的功能就是存储一个键值对,用户发布一个配置(configKey),然后客户端获取这个配置项(configValue);进阶的功能就是当某个配置项发生变更时,不停机就可以动态刷新服务内部的配置项
主流配置中心:Apollo(携程开源),nacos(阿里开源),Spring Cloud Config(Cloud全家桶成员)
功能:存储项目配置信息的一个服务
作用:集中管理配置信息,动态发布配置信息
二、实操测试
1.在pom里添加依赖
<!--nacos配置中心的依赖(nacos.io)-->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>
2.修改配置文件
config: #服务配置(将动态的配置写在配置中心)
server-addr: localhost:8848
file-extension: yml #配置中心指定的配置信息格式的扩展名
3.动态配置日志的输出级别
3.1添加日志输出
在类上添加@Slf4j注解(lombok提供的)
@GetMapping("provider/echo/{msg}")
public String doRestEcho1(@PathVariable String msg) throws InterruptedException {
log.info("doRestEcho1 start {}",System.currentTimeMillis());//{} 标识占位符
return server+":"+msg;
}
这里默认日志输出级别是info
3.2在nacos配置中心新建配置
这里我们配置的日志输出级别是error
注意:其中Data ID的值要与bootstrap.yml中定义的spring.application.name的值相同(服务名-假如有多个服务一般会创建多个配置实例,不同服务对应不同的配置实例)。
4.测试
访问url进行日志的查看
思考:这里我们可以看到日志没有输出,这是为什么呢?
解答:配置中心配置了error,级别比这个高,所以下面语句不会输出,只会输出error等级或者比error等级高的,但是error就是最高等级了,所以我们想要输出可以动态的去改变配置中心的级别
日志级别:trace<debug<info<warn<error 一般默认是info,调试用debug,上线用error
动态刷新机制:
对于nacos配置中心而言,有系统内部对配置变化的感知,还有外部系统对配置的感知,假如我们系统在浏览器中能看到日志级别的变化就好了
1.创建动态获取日志级别类
@Value("${logging.level.com.cy:error}")
private String logLevel;
@GetMapping("provider/deGetLogLevel")
public String deGetLogLevel(){
//随着级别的变化动态的输出
log.trace("==log.trace==");//跟踪
log.debug("==log.debug==");//调试
log.info("==log.info==");//常规信息
log.warn("==log.warn==");//警告
log.error("==log.error==");//错误信息
return "log is level"+logLevel;
}
2.在类上添加@RefreshScope注解
@RefreshScope的作用是在配置中心的相关配置发生变化以后,能够及时看到类中属性值的更新(底层是通过重新创建Controller对象的方式,对属性进行了重新初始化),Controller编写好以后,启动配置中心服务,然后进行访问测试
作用:
- 此属性会在属性构建时初始化
- 服务启动时会将所有的配置信息(配置文件或者配置中心)读取到Environment对象
- @Value用于告诉spring从Environment中读取配置信息
- 将读取的配置信息赋值给对象的属性
三、Nacos配置管理模型
Nacos 配置管理模型由三部分构成,如图
- Namespace:命名空间,对不同的环境进⾏隔离,⽐如隔离开发环境和⽣产环境。
- Group:分组,将若⼲个服务或者若⼲个配置集归为⼀组。
- Service/DataId:某⼀个服务或配置集,一般对应一个配置文件。
1.新建命名空间
Nacos中的命名空间一般用于配置隔离,这种命名空间的定义一般会按照环境(开发,生产等环境)进行设计和实现.我们默认创建的配置都存储到了public命名空间
可以克隆操作,然后修改日志输出级别为debug
在yml文件里进行配置
spring:
cloud:
nacos:
config:
namespace: 6058fd3f-0d4d-44f2-85d6-5fc7d2348046
namespace后面的字符串为命名空间的id,可直接从命名空间列表中进行拷贝.
重启服务发现配置成功,输出的日志级别变为了debug及以上
2.新建分组
2.1新建配置,在配置时把默认的DEFAULT_GROUP分组改成自己的分组名称
2.2在yml文件中添加组名称
2.3创建测试类进行测试
@RefreshScope
@RestController
public class ProviderController{
@Value("${server.tomcat.threads.max:200}")
private Integer maxThread;
@GetMapping("/provider/doGetMaxThread")
public String doGetMaxThread(){
return "server.threads.max is "+maxThread;
}
2.4结果
测试成功
3.共享配置
当同一个namespace的多个配置文件中都有相同配置时,可以对这些配置进行提取,然后存储到nacos配置中心的一个或多个指定配置文件,哪个微服务需要,就在服务的配置中设置读取即可。
3.1创建共享配置
3.2在yml文件中进行引入
shared-configs[0]:
data-id: app-public-dev.yml
refresh: true #默认false,共享配置更新,引用此配置的地方是否要更新
可以引入多个,只需要修改数组里的编号即可,不能相同
shared-configs[0]:
data-id: app-public-dev.yml
refresh: true #默认false,共享配置更新,引用此配置的地方是否要更新
shared-configs[1]:
data-id: 自定义共享配置名
refresh: true #默认false'''
3.3创建测试类
@RefreshScope
@RestController
public class ProviderPageController {
@Value("${page.pageSize:10}")
private Integer pageSize;
@GetMapping("provider/doGetPageSize")
public String doGetPageSize(){
//return String.format()
return "page size is "+pageSize;
}
}
直接引入即可
3.4测试
测试成功
总结
- 配置中心的选型。(市场活跃度、稳定性、性能、易用)
- Nacos配置中心基本应用。(新建,修改、删除配置以后,在Nacos客户端应用配置)
- 配置管理模型应用。(namespace,group,service/dataId)
- Nacos配置变更的动态感知。(底层原理分析)
- 配置中心可以动态管理发布配置,无需重启服务,更好保证服务的可用