一,配置中心简介
1.背景分析
我们知道,除了代码之外,软件还有一些配置信息,比如数据库的用户名和密码,还有一些我们不想写死在代码里的东西,例如像线程池大小、队列长度等运行参数,以及日志级别、算法策略等, 还有一些是软件运行环境的参数,如Java 的内存大小,应用启动的参数,包括操作系统的一些 参数配置…… 所有这些东西,我们都叫做软件配置。以前,我们把软件配置写在一个配置文件中,就像 Windows 下的 ini 文件,或是 Linux 下的 conf 文件。然而,在分布式系统下,这样的方式就变得非常不好管理,并容易出错。假如生产环境下,项目现在正在运行,此时修改了配置文件,我们需要让这些配置生效,通常的做法是不是要重启服务。但重启是不是会带来系统服务短时间的暂停,从而影响用户体验呢,还有可能会带来经济上的很大损失(例如双11重启下服务)。基于这样的背景,配置中心诞生了。
2.配置中心概述
配置中心最基础的功能就是存储一个键值对,用户发布一个配置(configKey),然后客户端获取这个配置项(configValue);进阶的功能就是当某个配置项发生变更时,不停机就可以动态刷新服务内部的配置项,例如,在生产环境上我们可能把我们的日志级别调整为 error 级别,但是,在系统出问题我们希望对它 debug 的时候,我们需要动态的调整系统的行为的能力,把日志级别调整为 debug 级别。还有,当你设计一个电商系统时,设计大促预案一定会考虑,同时涌进来超过一亿人并发访问的时候,假如系统是扛不住的,你会怎么办,在这个过程中我们一般会采用限流,降级。系统的限流和降级本质上来讲就是从日常的运行态切换到大促态的一个行为的动态调整,这个本身天然就是配置起到作用的一个相应的场景。
3.配置中心的选型
在面向分布式的微服务系统中,如何通过更高效的配置管理方式,实现微服务系统架构持续“无痛”的演进,并动态调整和控制系统的运行时态,配置中心的选型和设计起着举足轻重的作用。市场上主流配置中心有Apollo(携程开源),nacos(阿里开源),Spring Cloud Config(Spring Cloud 全家桶成员)。我们在对这些配置中心进行选型时重点要从产品功能、使用体验、实施过程和性能等方面进行综合考量。本次课程我们选择nacos,此组件不仅提供了注册中心,还具备配置中心的功能。
4.小节面试分析
- 什么是配置中心?(存储项目配置信息的一个服务)
- 为什么要使用配置中心?(集中管理配置信息,动态发布配置信息)
- 市场上有哪些主流的配置中心?(Apollo,nacos,……)
二,Nacos配置快速入门
1.添加依赖
在已有的sca-provider项目中添加如配置依赖,例如:
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>
2.修改配置文件
配置文件加载顺序
将项目中的application.yml的名字修改为bootstrap.yml配置文件(启动优先级最高),代码如下:
spring:
application:
name: sca-provider
cloud:
nacos:
discovery:
server-addr: localhost:8848
config:
server-addr: localhost:8848
file-extension: yml
3.Nacos基本配置
打开nacos配置中心,新建配置,如图所示:
其中Data ID的值要与bootstrap.yml中定义的spring.application.name的值相同(服务名-假如有多个服务一般会创建多个配置实例,不同服务对应不同的配置实例)。
4.Controller处理器操作
在ProviderController中添加一个获取日志级别(trace<debug<info<warn<error)的方法,控制台只会打印大于等于你配置的日志级别的信息,代码如下:
@RestController
public class ProviderController{
private static final Logger log= LoggerFactory.getLogger(ProviderApplication.class);
@Value("${logging.level.com.jt:error}")
private String logLevel;
@GetMapping("/provider/doGetLogLevel")
public String doGetLogLevel(){
log.trace("==log.trace==");
log.debug("==log.debug==");
log.info("==log.info==");
log.warn("==log.warn==");
log.error("==log.error==");
return "log level is "+logLevel;
}
……
}
结果: 最初: Nacos配置动态更新实现 修改配置信息:
修改后结果: 发现后台变了,而传出的数据没变
所以完整代码:
@RefreshScope
@RestController
public class ProviderController{
private static final Logger log= LoggerFactory.getLogger(ProviderApplication.class);
@Value("${logging.level.com.cy:error}")
private String logLevel;
@GetMapping("/provider/doGetLogLevel")
public String doGetLogLevel(){
log.trace("==log.trace==");
log.debug("==log.debug==");
log.info("==log.info==");
log.warn("==log.warn==");
log.error("==log.error==");
return "log level is "+logLevel;
}
……
}
这里@RefreshScope的作用是在配置中心的相关配置发生变化以后,能够及时看到类中属性值的更新(底层是通过重新创建Controller对象的方式,对属性进行了重新初始化) 不添加这个注解,无论刷新几次,ProviderController只创建一次,所以@Value("${logging.level.com.cy:error}")不能够及时更新,当使用这个标签后,没刷新一次,ProviderController都会创建一次,所以能够及时更新。 假如对配置的信息访问不到,请检测项目配置文件的名字是否为bootstrap.yml,检查配置文件中spring.application.name属性的值是否与配置中心的data-id名相同,还有你读取的配置信息缩进以及空格写的格式是否正确.
5.SpringBoot日志打印
不多废话,直接上图
logging:
level:
com.cy: error
file:
path: F:/logs
pattern:
console: '%-5level %logger : %msg%n'
file: '%d %-5level %thread %logger %msg %n'
后台打印: 日志本地位置: 本地日志格式:
6.小节面试分析
- 配置中心一般都会配置什么内容?(可能会经常变化的配置信息,例如连接池,日志、线程池、限流熔断规则)
- 什么信息一般不会写到配置中心?(服务端口,服务名,服务的注册地址,配置中心)
- 项目中为什么要定义bootstrap.yml文件?(此文件被读取的优先级比较高,可以在服务启动时读取配置中心的数据)
- Nacos配置中心宕机了,我们的服务还可以读取到配置信息吗?(可以从内存,客户端获取了配置中心的配置信息以后,会将配置信息在本地内存中存储一份.)
- 微服务应用中我们的客户端如何获取配置中心的信息?(我们的服务一般首先会从内存读取配置信息,同时我们的微服务还可以定时向nacos配置中心发请求拉取(pull)更新的配置信息)
- 微服务应用中客户端如何感知配置中心数据变化?(当数据发生变化时,nacos找到它维护的客户端,然后通知客户端去获取更新的数据,客户端获取数据以后更新本地内存,并在下次访问资源时,刷新@Value注解描述的属性值,但是需要借助@RefreshScope注解对属性所在的类进行描述)
- 服务启动后没有从配置中心获取我们的配置数据是什么原因?(依赖,配置文件名字bootstrap.yml,配置中心的dataId名字是否正确,分组是否正确,配置的名字是否正确,缩进关系是否正确,假如是动态发布,类上是否有@RefreshScope注解)
- 你项目中使用的日志规范是什么?(SLF4J)
- 你了解项目中的日志级别吗?(debug,info,error,…,可以基于日志级别控制日志的输出)
三,Nacos配置管理模型
1.概述
Nacos 配置管理模型由三部分构成,如图所示:
其中:
- Namespace:命名空间,对不同的环境进?隔离,?如隔离开发环境和?产环境。
- Group:分组,将若?个服务或者若?个配置集归为?组。
- Service/DataId:某?个服务或配置集,一般对应一个配置文件。
2.命名空间设计
Nacos中的命名空间一般用于配置隔离,这种命名空间的定义一般会按照环境(开发,生产等环境)进行设计和实现.我们默认创建的配置都存储到了public命名空间,如图所示: 创建新的开发环境并定义其配置,然后从开发环境的配置中读取配置信息,该如何实现呢? 第一步:创建新命名空间,如图所示: 命名空间成功创建以后,会在如下列表进行呈现。 在指定命名空间下添加配置,也可以直接取配置列表中克隆,例如: 注意!这里的目标空间是上述dev的命名空间ID 此时我们修改dev命名空间中Data Id的sca-provider配置,如图所示: 修改项目module中的配置文件bootstrap.yml,添加如下配置,关键代码如下:
spring:
application:
name: sca-provider
cloud:
nacos:
discovery:
server-addr: localhost:8848
config:
server-addr: localhost:8848
file-extension: yml
namespace: 28c62626-924f-4464-b8ba-980eba12ebfa
其中,namespace后面的字符串为命名空间的id,可直接从命名空间列表中进行拷贝. 重启服务,继续刷新http://localhost:8081/config/doGetLogLevel地址。检测输出,看看输出的内容是什么,是否为dev命名空间下配置的内容,如图所示:
3.分组设计及实现
当我们在指定命名空间下,按环境或服务做好了配置以后,有时还需要基于服务做分组配置,例如,一个服务在不同时间节点(节假日,活动等)切换不同的配置,可以在新建配置时指定分组名称,如图所示: 配置发布以后,修改boostrap.yml配置类,在其内部指定我们刚刚创建的分组,代码如下: 在ProviderController类中添加属性和方法用于获取和输出DEV_GROUP_51配置中设置的线程数,代码如下:
@Value("${server.tomcat.threads.max:200}")
private Integer maxThread;
@RequestMapping("/provider/doGetMaxThread")
public String doGetMaxThread(){
return "server.threads.max is "+maxThread;
}
然后重启服务,进行测试,检测内容输出,如图所示: 默认是200,这里是300说明配置成功
4.共享配置设计及读取
当同一个namespace的多个配置文件中都有相同配置时,可以对这些配置进行提取,然后存储到nacos配置中心的一个或多个指定配置文件,哪个微服务需要,就在服务的配置中设置读取即可。例如: 第一步:在nacos中创建一个共享配置文件,例如: 第二步:在指定的微服务配置文件(bootstrap.yml)中设置对共享配置文件的读取,例如: 见红色区域内容。
spring:
application:
name: sca-provider
cloud:
nacos:
discovery:
server-addr: localhost:8848
config:
server-addr: localhost:8848
file-extension: yml
namespace: 28c62626-924f-4464-b8ba-980eba12ebfa
group: DEV_GROUP_51
shared-configs[0]:
data-id: app-public-dev.yml
refresh: true
第三步:在指定的业务类中读取和应用共享配置即可,例如:
@Value("${page.pageSize:10}")
private Integer pageSize;
@GetMapping("/provider/doGetPageSize")
public String doGetPageSize(){
return "page size is "+pageSize;
}
第四步:启动服务进行访问测试。
5.小节面试分析
- Nacos配置管理模型的背景?(环境不同配置不同)
- Nacos配置中的管理模型是怎样的?(namespace,group,service/data-id)
- Nacos客户端(微服务)是否可以读取共享配置?(可以)
- Nacos配置管理优先级高于yml配置,Nacos有的配置,yml中也有的话会被覆盖,只有Nacos没有的,yml中配置才会生效。
|