服务配置中心和nacos 的实践

配置中心简介

背景分析

我们知道，除了代码之外，软件还有一些配置信息，比如数据库的用户名和密码，还有一些我们不想写死在代码里的东西，例如像线程池大小、队列长度等运行参数，以及日志级别、算法策略等， 还有一些是软件运行环境的参数，如Java 的内存大小，应用启动的参数，包括操作系统的一些 参数配置…… 所有这些东西，我们都叫做软件配置。以前，我们把软件配置写在一个配置文件中，就像 Windows 下的 ini 文件，或是 Linux 下的 conf 文件。然而，在分布式系统下，这样的方式就变得非常不好管理，并容易出错。假如生产环境下，项目现在正在运行，此时修改了配置文件，我们需要让这些配置生效，通常的做法是不是要重启服务。但重启是不是会带来系统服务短时间的暂停，从而影响用户体验呢，还有可能会带来经济上的很大损失（例如双11重启下服务）。基于这样的背景，配置中心诞生了。

配置中心概述

配置中心最基础的功能就是存储一个键值对，用户发布一个配置（configKey），然后客户端获取这个配置项（configValue）；进阶的功能就是当某个配置项发生变更时，不停机就可以动态刷新服务内部的配置项，例如，在生产环境上我们可能把我们的日志级别调整为 error 级别，但是，在系统出问题我们希望对它 debug 的时候，我们需要动态的调整系统的行为的能力，把日志级别调整为 debug 级别。还有，当你设计一个电商系统时，设计大促(比如:双十一等访问量较高的活动)预案一定会考虑，同时涌进来超过一亿人并发访问的时候，假如系统是扛不住的，你会怎么办，在这个过程中我们一般会采用限流，降级。系统的限流和降级本质上来讲就是从日常的运行态切换到大促态的一个行为的动态调整，这个本身天然就是配置起到作用的一个相应的场景。

配置中心的选型

在面向分布式的微服务系统中，如何通过更高效的配置管理方式，实现微服务系统架构持续“无痛”的演进，并动态调整和控制系统的运行时态，配置中心的选型和设计起着举足轻重的作用。市场上主流配置中心有Apollo(携程开源)，nacos(阿里开源)，Spring Cloud Config(Spring Cloud 全家桶成员）。我们在对这些配置中心进行选型时重点要从产品功能、使用体验、实施过程和性能等方面进行综合考量。本次课程我们选择nacos，此组件不仅提供了注册中心，还具备配置中心的功能。

小节面试分析

什么是配置中心？（存储项目配置信息的一个服务）
为什么要使用配置中心？(集中管理配置信息，动态发布配置信息)
市场上有哪些主流的配置中心？(Apollo,nacos,……)
Nacos配置快速入门
添加依赖
在已有的sca-provider项目中添加如配置依赖,例如:

<dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
  </dependency>

修改配置文件

将项目(sca-provider)中的application.yml的名字修改为bootstrap.yml配置文件（启动优先级最高），代码如下：

读取时bootstrap.yml会比application.yml优先读取;

添加的代码

  config:
        server-addr: 127.0.0.1:8848
        group: DEFAULT_GROUP # Group, default is DEFAULT_GROUP
        file-extension: yml # Configure the data format of the content, default to properties

全部代码

spring:
  application:
    name: sca-provider
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848
      config:
        server-addr: 127.0.0.1:8848
        group: DEFAULT_GROUP # Group, default is DEFAULT_GROUP
        file-extension: yml # Configure the data format of the content, default to properties

Nacos基本配置

打开nacos配置中心，新建配置，如图所示：

将下面的 内容写完,在点击–>发布在点击—>返回;

其中Data IDs的值要与bootstrap.yml中定义的spring.application.name的值相同(服务名-假如有多个服务一般会创建多个配置实例，不同服务对应不同的配置实例)。

Controller处理器操作

在ProviderController中添加一个获取日志级别(debug

目的:跟踪代码并进行测试代码

@RefreshScope //动态刷新配置
@RestController
public class ProviderController{
 //org.slf4j.Logger (Log4J,Logback都是基于此规范实现的日志库)
    //org.slf4j.LoggerFactory
    //getLogger(哪个类中输出的日志)
    private static final Logger log= LoggerFactory.getLogger(ProviderApplication.class);
    @Value("${logging.level.com.cy:error}")
    private String logLevel;
    @GetMapping("/provider/doGetLogLevel")
    public String doGetLogLevel(){
      //System.out.println("log.level="+logLevel);
      //日志优先级 trace
      //下面的日志级别是有小到大的级别
       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对象的方式,对属性进行了重新初始化),Controller编写好以后，启动配置中心服务，然后进行访问测试。，打开浏览器直接在地址栏输入http://localhost:8081/provider/doGetLogLevel，检测输出结果是否为我们配置中配置的信息，如图所示。

说明,假如对配置的信息访问不到,请检测项目配置文件的名字是否为bootstrap.yml,检查配置文件中spring.application.name属性的值是否与配置中心的data-id名相同,还有你读取的配置信息缩进以及空格写的格式是否正确.

Nacos配置动态更新实现

修改Nacos的日志级别配置并重新重新发布，如图所示

刷新浏览器url，检测其配置输出。

小节面试分析

配置中心一般都会配置什么内容？(可能会经常变化的配置信息，例如连接池，日志、线程池、限流熔断规则)
什么信息一般不会写到配置中心?(服务端口，服务名，服务的注册地址，配置中心)
项目中为什么要定义bootstrap.yml文件？(此文件被读取的优先级比较高，可以在服务启动时读取配置中心的数据)
Nacos配置中心宕机了，我们的服务还可以读取到配置信息吗？(可以从内存,客户端获取了配置中心的配置信息以后,会将配置信息在本地内存中存储一份.)
微服务应用中我们的客户端如何获取配置中心的信息?(为了考虑性能我们的服务一般首先会从内存读取配置信息，同时我们的微服务还可以定时向nacos配置中心发请求拉取(pull)更新的配置信息，但是在一定时间间隔内还可能会出现不一致的配置，所以nacos服务端而言，当配置变化时,会通知客户端然后更新客户端.)
微服务应用中客户端如何感知配置中心数据变化？(当数据发生变化时,nacos找到它维护的客户端，然后通知客户端去获取更新的数据，客户端获取数据以后更新本地内存,并在下次访问资源时,刷新@Value注解描述的属性值，但是需要借助@RefreshScope注解对属性所在的类进行描述)
服务启动后没有从配置中心获取我们的配置数据是什么原因?(依赖,配置文件名字bootstrap.yml,配置中心的dataId名字是否正确,分组是否正确,配置的名字是否正确,缩进关系是否正确,假如是动态发布,类上是否有@RefreshScope注解)
你项目中使用的日志规范是什么?(SLF4J)
你了解项目中的日志级别吗?(debug,info,error,…,可以基于日志级别控制日志的输出)

Nacos配置管理模型

概述

Nacos 配置管理模型由三部分构成，如图所示：

其中：

Namespace：命名空间，对不同的环境进⾏隔离，⽐如隔离开发环境和⽣产环境。
Group：分组，将若⼲个服务或者若⼲个配置集归为⼀组。
Service/DataId：某⼀个服务或配置集，一般对应一个配置文件。
命名空间设计
Nacos中的命名空间一般用于配置隔离，这种命名空间的定义一般会按照环境（开发，生产等环境）进行设计和实现.我们默认创建的配置都存储到了public命名空间，如图所示：

创建新的开发环境并定义其配置，然后从开发环境的配置中读取配置信息，该如何实现呢？

第一步：创建新命名空间，如图所示：

命名空间成功创建以后，会在如下列表进行呈现。

在指定命名空间下添加配置，也可以直接取配置列表中克隆，例如：

克隆成功以后，我们会发现在指定的命名空间中有了我们克隆的配置，如图所示：

此时我们修改dev命名空间中Data Id的sca-provider配置，如图所示：

修改项目module中的配置文件bootstrap.yml,添加如下配置，关键代码如下：

spring:
  cloud:
    nacos:
      config:
        namespace: 6058fd3f-0d4d-44f2-85d6-5fc7d2348046

其中，namespace后面的字符串为命名空间的id，可直接从命名空间列表中进行拷贝.
重启服务，继续刷新http://localhost:8081/config/doGetLogLevel地址。检测输出，看看输出的内容是什么，是否为dev命名空间下配置的内容，如图所示：

我们还可以创建生产环境，依次类推进行设计和实现即可。

分组设计及实现
当我们在指定命名空间下，按环境或服务做好了配置以后，有时还需要基于服务做分组配置，例如，一个服务在不同时间节点(节假日，活动等)切换不同的配置，可以在新建配置时指定分组名称，如图所示：

配置发布以后，修改boostrap.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

在NacosConfigController类中添加属性和方法用于获取和输出DEV_GROUP_51配置中设置的线程数，代码如下：

@Value("${server.tomcat.threads.max:200}")
private Integer maxThread;

@RequestMapping("/provider/doGetMaxThread")
public String doGetMaxThread(){
    return "server.threads.max is  "+maxThread;
}

然后重启服务，进行测试，检测内容输出，如图所示:

共享配置设计及读取
当同一个namespace的多个配置文件中都有相同配置时，可以对这些配置进行提取，然后存储到nacos配置中心的一个或多个指定配置文件，哪个微服务需要，就在服务的配置中设置读取即可。例如：

第一步：在nacos中创建一个共享配置文件，例如：

第二步：在指定的微服务配置文件(bootstrap.yml)中设置对共享配置文件的读取，例如：
见红色区域内容

spring:
  application:
    name: nacos-config
  cloud:
    nacos:
      config:
        server-addr: localhost:8848
        # 命名空间
        namespace: 83ed55a5-1dd9-4b84-a5fe-a734e4a6ec6d
        # 分组名
        # group: DEFAULT_GROUP
        # 配置中心文件扩展名
        file-extension: yml
        # 共享配置
        shared-configs[0]:
                data-id: app-public-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;
}

第四步：启动服务进行访问测试。

小节面试分析

Nacos配置管理模型的背景？(环境不同配置不同)
Nacos配置中的管理模型是怎样的？（namespace,group,service/data-id）
Nacos客户端(微服务)是否可以读取共享配置?(可以)
总结(Summary)

重难点分析

配置中心的选型。(市场活跃度、稳定性、性能、易用)
Nacos配置中心基本应用。(新建，修改、删除配置以后，在Nacos客户端应用配置)
配置管理模型应用。(namespace,group,service/dataId)
Nacos配置变更的动态感知。(底层原理分析)

FAQ分析

为什么需要配置中心？(动态管理发布配置，无需重启服务，更好保证服务的可用)
配置中一般要配置什么内容？(经常变化的配置数据-日志级别，线程池、连接池、…)
市面上有哪些主流配置中心？(Nacos,….)
配置中心选型时要重点考虑哪些因素？(市场活跃度、稳定性、性能、易用)
Nacos客户端(微服务业务)如何动态感知配置中心数据变化的？(nacos2.0之前nacos客户端采用长轮询机制拉取nacos服务的配置信息，pull（每隔30秒）+“push(是在服务端的配置信息变更以后，通知服务端中处于等待状态的客户端队列中的客户端对象，并更新客户端对应的响应数据，然后返回响应)”)
Nacos配置管理模型是怎样的？（命名空间-namespace,分组-group,服务实例-dataId）
Bug分析
 。。。。