一、拓展：系统日志
1、java日志
【强制】应用中不可直接使用日志系统（Log4j、Logback）中的 API，而应依赖使用日志框架 SLF4J 中的 API，使用门面模式的日志框架，有利于维护和各个类的日志处理方式统一。
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
//创建log日志对象
private static final Logger logger = LoggerFactory.getLogger(类名.class);
或者
private static final Logger logger = LoggerFactory.getLogger(类名);
2、日志级别
日志级别：trace（跟踪） < debug（调试） < info（常规信息） < warn（警告） < error （错误信息）
默认级别是：info（常规信息）
log.trace("==log.trace=="); //跟踪
log.debug("==log.debug=="); //调试
log.info("==log.info=="); //常规信息
log.warn("==log.warn=="); //警告
log.error("==log.error=="); //错误信息
3、案例
第一种：输出log日志
//http://localhost:8081/provider/doGetLogLevel
@GetMapping("/provider/doGetLogLevel")
public String doGetLogLevel(){
System.out.println("输出日志");
//日志级别trace<debug<info<warn<error
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;
}
默认级别是 info，输出显示只能比info级别高的，因此，只输出info、warn、error三个级别
第二种：修改日志文件级别，修改为debug，输出log日志
修改application.yml配置文件
#配置日志的默认级别(经常变化的数据一般会写到配置中心)
logging:
level:
com.jt: debug
修改了默认级别，是 debug，输出显示只能比info级别高的，因此，只输出debug、info、warn、error四个级别
二、NACOS配置中心简介
1、背景分析
我们知道，除了代码之外，软件还有一些配置信息，比如数据库的用户名和密码，还有一些我们不想写死在代码里的东西，例如像线程池大小、队列长度等运行参数，以及日志级别、算法策略等， 还有一些是软件运行环境的参数，如Java 的内存大小，应用启动的参数，包括操作系统的一些 参数配置…… 所有这些东西，我们都叫做软件配置。以前，我们把软件配置写在一个配置文件中，就像 Windows 下的 ini 文件，或是 Linux 下的 conf 文件。然而，在分布式系统下，这样的方式就变得非常不好管理，并容易出错。假如生产环境下，项目现在正在运行，此时修改了配置文件，我们需要让这些配置生效，通常的做法是不是要重启服务。但重启是不是会带来系统服务短时间的暂停，从而影响用户体验呢，还有可能会带来经济上的很大损失（例如双11重启下服务）。基于这样的背景，配置中心诞生了。
2、配置中心概述
配置中心最基础的功能就是存储一个键值对，用户发布一个配置（configKey），然后客户端获取这个配置项（configValue）；进阶的功能就是当某个配置项发生变更时，不停机就可以动态刷新服务内部的配置项，例如，在生产环境上我们可能把我们的日志级别调整为 error 级别，但是，在系统出问题我们希望对它 debug 的时候，我们需要动态的调整系统的行为的能力，把日志级别调整为 debug 级别。还有，当你设计一个电商系统时，设计大促预案一定会考虑，同时涌进来超过一亿人并发访问的时候，假如系统是扛不住的，你会怎么办，在这个过程中我们一般会采用限流，降级。系统的限流和降级本质上来讲就是从日常的运行态切换到大促态的一个行为的动态调整，这个本身天然就是配置起到作用的一个相应的场景。
配置中心的选型
在面向分布式的微服务系统中，如何通过更高效的配置管理方式，实现微服务系统架构持续“无痛”的演进，并动态调整和控制系统的运行时态，配置中心的选型和设计起着举足轻重的作用。市场上主流配置中心有Apollo(携程开源)，nacos(阿里开源)，Spring Cloud Config(Spring Cloud 全家桶成员）。我们在对这些配置中心进行选型时重点要从产品功能、使用体验、实施过程和性能等方面进行综合考量。本次课程我们选择nacos，此组件不仅提供了注册中心，还具备配置中心的功能。
3、Nacos配置中心模型
4、小节面试分析
什么是配置中心？（存储项目配置信息的一个服务）
为什么要使用配置中心？(集中管理配置信息，动态发布配置信息)
市场上有哪些主流的配置中心？(Apollo,nacos,……)
三、Nacos配置快速入门
1、添加依赖
在已有的sca-provider项目中添加如配置依赖，例如：
<!--nacos配置中心依赖-->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>
2、修改配置文件
2.1）修改配置文件
将项目中的application.yml的名字修改为bootstrap.yml配置文件（启动优先级最高），代码如下：
server:
port: 8081
spring:
application:
name: sca-provider
cloud:
nacos:
config: #配置中心的配置
server-addr: localhost:8848
file-extension: yml
discovery: #注册中心
server-addr: localhost:8848
2.2）配置文件加载顺序
3、Nacos基本配置
打开nacos配置中心，新建配置，如图所示：
其中Data ID的值要与bootstrap.yml中定义的spring.application.name的值相同(服务名-假如有多个服务一般会创建多个配置实例，不同服务对应不同的配置实例)。
4、Controller处理器操作
在ProviderController中添加一个获取日志级别(debug<info<warn<error)的方法，代码如下：
//获取配置文件中日志级别
@Value("${logging.level.com.jt:}")
private String logLevel;
//http://localhost:8081/provider/doGetLogLevel
@GetMapping("/provider/doGetLogLevel")
public String doGetLogLevel(){
System.out.println("输出日志");
//日志级别trace<debug<info<warn<error
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;
}
Controller编写好以后，启动配置中心服务，然后进行访问测试。打开浏览器直接在地址栏输入http://localhost:8081/provider/doGetLogLevel，检测输出结果是否为我们配置中配置的信息，如图所示。
配置的日志级别是 debug，输出显示只能比info级别高的，因此，只输出debug、info、warn、error四个级别
说明：假如对配置的信息访问不到，请检测项目配置文件的名字是否为bootstrap.yml，检查配置文件中spring.application.name属性的值是否与配置中心的data-id名相同，还有你读取的配置信息缩进以及空格写的格式是否正确
5、@RefreshScope
@RefreshScope的作用是在配置中心的相关配置发生变化以后，能够及时看到类中属性值的更新（底层是通过重新创建Controller对象的方式，对属性进行了重新初始化）
6、Nacos配置动态更新实现
修改代码，加上@RefreshScope注解
/**定义Controller对象(这个对象在spring mvc中给他的定义是handler),
* 基于此对象处理客户端的请求*/
@RefreshScope//这个注解描述类时,当配置中心数据发生变化会对属性进行重新初始化
/**定义Controller对象(这个对象在spring mvc中给他的定义是handler),
* 基于此对象处理客户端的请求*/
@RestController
public class ProviderController {
//获取配置文件中日志级别
@Value("${logging.level.com.jt:}")
private String logLevel;
//http://localhost:8081/provider/doGetLogLevel
@GetMapping("/provider/doGetLogLevel")
public String doGetLogLevel(){
System.out.println("输出日志");
//日志级别trace<debug<info<warn<error
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的日志级别配置（warn）并重新重新发布，如图所示：
修改Nacos的日志级别配置（error）并重新重新发布，如图所示：
7、注意
配置中心写，这里也写，保证有一个可用
server:
port: 8081
spring:
application:
name: sca-provider
cloud:
nacos:
config: #配置中心的配置
server-addr: localhost:8848
file-extension: yml
discovery: #注册中心
server-addr: localhost:8848
# 配置日志(经常变化的数据一般会写到配置中心)，配置中心写，这里也写，保证有一个可用
logging:
level:
com.jt: error
8、nacos是拉取(Pull)配置信息
9、小节面试分析
配置中心一般都会配置什么内容？(可能会经常变化的配置信息，例如连接池，日志、线程池、限流熔断规则)
什么信息一般不会写到配置中心?(服务端口，服务名，服务的注册地址，配置中心)
项目中为什么要定义bootstrap.yml文件？(此文件被读取的优先级比较高，可以在服务启动时读取配置中心的数据)
Nacos配置中心宕机了，我们的服务还可以读取到配置信息吗？(可以从内存,客户端获取了配置中心的配置信息以后,会将配置信息在本地内存中存储一份.)
微服务应用中我们的客户端如何获取配置中心的信息?(我们的服务一般首先会从内存读取配置信息，同时我们的微服务还可以定时向nacos配置中心发请求拉取(pull)更新的配置信息)
微服务应用中客户端如何感知配置中心数据变化？(当数据发生变化时,nacos找到它维护的客户端，然后通知客户端去获取更新的数据，客户端获取数据以后更新本地内存,并在下次访问资源时,刷新@Value注解描述的属性值，但是需要借助@RefreshScope注解对属性所在的类进行描述)
服务启动后没有从配置中心获取我们的配置数据是什么原因?(依赖,配置文件名字bootstrap.yml,配置中心的dataId名字是否正确,分组是否正确,配置的名字是否正确,缩进关系是否正确,假如是动态发布,类上是否有@RefreshScope注解)
你项目中使用的日志规范是什么?(SLF4J)
你了解项目中的日志级别吗?(debug,info,error,…,可以基于日志级别控制日志的输出)
四、Nacos配置管理模型
1、概述
Nacos 配置管理模型由三部分构成，如图所示：
其中：
Namespace：命名空间，对不同的环境进⾏隔离，⽐如隔离开发环境和⽣产环境。
Group：分组，将若⼲个服务或者若⼲个配置集归为⼀组。
Service/DataId：某⼀个服务或配置集，一般对应一个配置文件。
Nacos配置管理模型：
寻找顺序：public----Group----Data Id
2、命名空间设计
Nacos中的命名空间一般用于配置隔离，这种命名空间的定义一般会按照环境（开发，生产等环境）进行设计和实现.我们默认创建的配置都存储到了public命名空间，如图所示：
3、命名空间快速入门
创建新的开发环境并定义其配置，然后从开发环境的配置中读取配置信息，该如何实现呢？
第一步：创建新命名空间，如图所示：
命名空间成功创建以后，会在如下列表进行呈现。
第二步：克隆配置，在指定命名空间下添加配置，也可以直接取配置列表中克隆，例如：
克隆成功以后，我们会发现在指定的命名空间中有了我们克隆的配置，如图所示：
第三步：此时我们修改dev命名空间中Data Id的sca-provider配置，如图所示：
第四步：修改提供方（sca-provider）项目module中的配置文件bootstrap.yml,添加如下配置，关键代码如下：
server:
port: 8070
spring:
application:
name: nacos-config
cloud:
nacos:
config:
server-addr: 127.0.0.1:8848
group: DEV_GROUP_51 # Group, default is DEFAULT_GROUP
file-extension: yml # Configure the data format of the content, default to properties
namespace: 5c27fe4a-1141-4836-a14e-cbac77fb2130
其中，namespace后面的字符串为命名空间的id，可直接从命名空间列表中进行拷贝.
第五步、重启服务，继续刷新
访问：http://localhost:8081/provider/doGetLogLevel地址，检测输出，看看输出的内容是什么，是否为dev命名空间下配置的内容，如图所示：
五、分组设计及实现
我们还可以创建生产环境，依次类推进行设计和实现即可。
当我们在指定命名空间下，按环境或服务做好了配置以后，有时还需要基于服务做分组配置，例如，一个服务在不同时间节点(节假日，活动等)切换不同的配置，可以在新建配置时指定分组名称。
1、配置模型：
2、Tomcat 请求处理分析
3、在sca-provider项目种修改线程池的配置
第一步：在dev的空间创建配置文件，如图所示：
server:
tmocat:
threads:
max: 300 ##默认200
第二步：配置发布以后，修改boostrap.yml配置类，在其内部指定我们刚刚创建的分组，代码如下：
spring:
application:
name: sca-provider
cloud:
nacos:
config: #配置中心的配置
server-addr: localhost:8848 #配置中心地址
file-extension: yml #配置文件的类型
namespace: 4c251f40-8b1c-4d82-ab10-8133d9686f4c #dev命名空间的id
group: DEFAULT_GROUP_51 #配置中心的组名
discovery: #注册中心
server-addr: localhost:8848
第三步：在ProviderController类中添加属性和方法用于获取和输出DEV_GROUP_51配置中设置的线程数，代码如下：
//线程池默认最大值是200
@Value("${server.tomcat.threads.max:200}")
private Integer maxThread;
@RequestMapping("/provider/doGetMaxThread")
public String doGetMaxThread(){
return "server.threads.max is "+maxThread;
}
第四步：然后重启服务，进行测试，检测内容输出，如图所示：
http://localhost:8081/provider/doGetMaxThread
4、在nasoc中配置线程池的配置
第一步：修改dev的空间，组名是：DEFAULT_GROUP_51的配置文件，如图所示：
server:
tmocat:
threads:
max: 300
spring:
cloud:
nacos:
config: #配置中心的配置
namespace: 4c251f40-8b1c-4d82-ab10-8133d9686f4c #dev命名空间的id
group: DEFAULT_GROUP_51 #配置中心的组名
logging:
level:
com.jt: error
第二步：然后重启服务，进行测试，检测内容输出，如图所示：
5、共享配置设计及读取
当同一个namespace的多个配置文件中都有相同配置时，可以对这些配置进行提取，然后存储到nacos配置中心的一个或多个指定配置文件，哪个微服务需要，就在服务的配置中设置读取即可。例如：
第一步：在nacos中创建一个共享配置文件，例如：
文件名：app-common-dev.yml
第二步：在指定的微服务配置文件(bootstrap.yml)中设置对共享配置文件的读取，例如：
# 共享配置
shared-configs[0]: #0表示一个数组下标
data-id: app-common-dev.yml
group: DEFAULT_GROUP
refresh: true #默认false
第三步：在指定的业务类中读取和应用共享配置即可，例如：
//共享配置
@Value("${page.pageSize:10}")
private Integer pageSize;
@GetMapping("/provider/doGetPageSize")
public String doGetPageSize() {
//return String.format()
return "page size is " + pageSize;
}
第四步：启动服务进行访问测试。
http://localhost:8081/provider/doGetPageSize
第五步：查看在nacos中创建一个共享配置文件app-common-dev.yml
六、Java线程池构成分析
七、线程池任务执行过程
八、小节面试分析
Nacos配置管理模型的背景？(环境不同配置不同)
Nacos配置中的管理模型是怎样的？（namespace,group,service/data-id）
Nacos客户端(微服务)是否可以读取共享配置?(可以)
九、总结(Summary)
1、重难点分析
配置中心的选型。(市场活跃度、稳定性、性能、易用)
Nacos配置中心基本应用。(新建，修改、删除配置以后，在Nacos客户端应用配置)
配置管理模型应用。(namespace,group,service/dataId)
Nacos配置变更的动态感知。(底层原理分析)
2、FAQ分析
为什么需要配置中心？(动态管理发布配置，无需重启服务，更好保证服务的可用)
配置中一般要配置什么内容？(经常变化的配置数据-日志级别，线程池、连接池、…)
市面上有哪些主流配置中心？(Nacos,….)
配置中心选型时要重点考虑哪些因素？(市场活跃度、稳定性、性能、易用)
Nacos客户端(微服务业务)如何动态感知配置中心数据变化的？(nacos2.0之前nacos客户端采用长轮询机制每隔30秒拉取nacos配置信息.)
Nacos配置管理模型是怎样的？（命名空间-namespace,分组-group,服务实例-dataId）
755
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
