配置中心Config

Posted 2023-04-25

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了配置中心Config相关的知识，希望对你有一定的参考价值。

参考技术A

随着项目日益庞大，每个项目都散落着各种配置文件，如果采用分布式的开发模式，需要的配置文件随着服务增加而不断增多。某一个基础服务信息变更，都会引起一系列的更新和重启，运维苦不堪言也容易出错。配置中心就是是解决此类问题的。

市面上开源的配置中心有很多，BAT每家都出过，360的QConf、淘宝的diamond、百度的disconf都是解决这类问题。国外也有很多开源的配置中心Apache Commons Configuration、owner、cfg4j等等。

为分布式系统中的基础设施和微服务应用提供集中化的外部配置支持，它分为服务端与客户端两个部分。其中服务端也称为分布式配置中心，它是一个独立的微服务应用，用来连接配置仓库并为客户端提供获取配置信息、加密 / 解密信息等访问接口；而客户端则是微服务架构中的各个微服务应用或基础设施，它们通过指定的配置中心来管理应用资源与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息。

由于 Spring Cloud Config 实现的配置中心默认采用 Git 来存储配置信息，所以使用 Spring Cloud Config 构建的配置服务器，天然就支持对微服务应用配置信息的版本管理，并且可以通过 Git 客户端工具来方便的管理和访问配置内容。当然它也提供了对其他存储方式的支持，比如：SVN 仓库、本地化文件系统。

pom.xml中引入 spring-cloud-config-server 依赖，完整依赖配置如下：

创建Spring Boot的程序主类，并添加 @EnableConfigServer 注解，开启Config Server

application.properties`中配置服务信息以及git信息，例如：

Spring Cloud Config也提供 本地存储配置 方式。我们只需要设置属性spring.profiles.active=native，Config Server会默认从应用的src/main/resource目录下检索配置文件。也可以通过spring.cloud.config.server.native.searchLocations=file:F:/properties/属性来指定配置文件的位置。

准备一个 Git 仓库，在上面创建了一个文件夹 config-repo 用来存放配置文件，为了模拟生产环境，我们创建以下三个配置文件：

其中设置了一个from属性，为每个配置文件分别设置了不同的值，如：

为了测试版本控制，在master中，我们都加入1.0的后缀，同时创建一个 config-label-test分支 ，并将各配置文件中的值用2.0作为后缀。

URL与配置文件的映射关系如下：

上面的url会映射 application-profile.properties ** 对应的配置文件， label 对应git上不同的分支，默认为master。 先找给定名称的配置文件，如果找不到去application.yml/application.properties找

尝试构造不同的url来访问不同的配置内容，比如：要访问config-label-test分支，应用的prod环境，可以通过这个url： http://localhost:7001/application/prod/config-label-test

创建一个Spring Boot应用，在pom.xml中引入spring-cloud-starter-config依赖，完整依赖关系如下：

搭建srpingcloud-config server端，配置文件可以用application.yml 或 application.properties，config client端却要使用bootstrap.yml或bootstrap.properties。

格外注意（config client端） ：上面这些属性必须配置在 bootstrap .properties中，config部分内容才能被正确加载。因为config的相关配置会先于application.properties，而 bootstrap.properties的加载也是先于application.properties （bootstrap.yml 的加载也是先于 application.yml）。

创建一个Rest Api来返回配置中心的from属性，具体如下：

启动该应用，并访问： http://localhost:6020/from ，我们就可以根据配置内容输出对应环境的from内容了。

有时，我们需要对配置内容做一些实时更新。server端会自动读取最新提交的内容,client端不会自动获取新的信息。

将config-server和config-client都启动起来，并访问客户端提供的REST API http://localhost:6020/from 来获取配置信息，可以获得返回内容为： git-dev-1.0 。接着，我们可以尝试使用Git工具修改当前配置的内容，比如，将 config-repo/application-dev.properties 中的from的值从 from=git-dev-1.0 修改为 from=git-dev-2.0 ，再访问 http://localhost:6020/from ，可以看到其返回内容还是 git-dev-1.0 。

下面进行改造：在config-client端增加一些内容和操作以实现配置的刷新

在config-clinet的 pom.xml 中新增 spring-boot-starter-actuator 监控模块，其中包含了 /refresh 刷新API。

增加spring-boot-starter-actuator 包，这是一套监控的功能，可以监控程序在运行时状态，其中就包括 /actuator/refresh`的功能。

需要给 加载变量的类上 面加载 @RefreshScope ，在客户端执行 /actuator/refresh 的时候就会更新此类下面的变量值。

Spring Boot 1.5.X 以上默认开通了安全认证，所以要在配置文件 application.yml 中添加以下配置以将 /actuator/refresh 这个 Endpoint 暴露出来

改造完之后，我们以 POST 请求的方式来访问 http://localhost:6020/actuator/refresh 就会更新配置文件至最新版本。

加载 bootstrap. ------>连接config server 加载远程设置 --------> 加载application.的配置**

bootstrap 放一些你不想改的值

本地配置和远程配置冲突以远程的为准

SpringCloud Config分布式配置中心

总体思维导图

大体概述

分布式系统现在面临的问题是什么？

配置问题。

微服务意味着要将单体应用中的业务拆分成一个个子服务，每个服务的粒度相对较小，因此系统中会出现大量的服务。由于每个服务都需要必要的配置信息才能运行，所以一套集中式的，动态的配置管理设施是必不可少的。

SpringCloud提供了ConfigServer来解决这个问题，我们每一个微服务自己带着一个application.yml,上百个配置文件的管理该怎么办？

什么是SpringCloud Config分布式配置中心？

SpringCloud Config为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。

怎么玩？

SpringCloud Config分为服务端和客户端两部分。其中服务端主要是用于写入配置文件的，而客户端主要是去使用配置中心已经被服务端写入的配置文件的。

服务端也称为分布式配置中心，它是一个独立的微服务应用，用来连接配置服务器并为客户端提供获取配置信息，加密/解密信息等访问接口。

客户端则是通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息配置服务器默认采用git来存储配置信息，这样就有助于对环境配置进行版本管理，并且可以通过git客户端工具来方便的管理和访问配置内容。

能干嘛？

1.集中管理配置文件

2.不同环境不同配置，动态化的配置更新，分环境部署比如dev/test/prod/beta/release

3.运行期间动态调整配置，不再需要在每个服务部署的机器上编写配置文件，服务会向配置中心统一拉取配置自己的信息

4.当配置发生变动时，服务不需要重启即可感知到配置的变化并应用新的配置

5.将配置信息以REST接口的形式暴露，post,curl访问刷新均可…

Config配置中心总控中心搭建

什么叫做总控中心？

总控中心其实就是Config配置中心的服务端，我们的微服务需要得到配置信息，虽然说所有的配置都在码云远程仓库中，但是我们的客户端微服务并不会直接去访问码云远程仓库得到配置信息，而是会通过一个中间的微服务，这个中间的微服务就叫做Config配置中心的服务端，也叫作Config总控中心。

Config配置中心服务端是一个单独的微服务，这个微服务只有一个作用，就是它可以访问码云注册中心的配置文件。而其它的客户端微服务不会直接访问码云中的注册中心，而是直接去访问Config配置中心服务端的这个微服务，这样其实客户端微服务已经间接的通过服务端访问到了码云中的注册中心。

在码云上新建仓库

在码云上建立一个名字为springcloud-config的仓库，然后获取仓库地址，如下图：

在本地idea里面创建一个springcloud-config项目和码云中的仓库联系起来

如下图：

这个项目就一个作用，它可以往远程的码云中的配置中心中发布内容。

新建Module模块也就是配置中心的服务端cloud-config-center-3344

新建Module模块cloud-config-center-3344，如下图：

POM

可以看出此工程的pom文件中引入的Config配置中心的依赖是spring-cloud-config-server表示该工程是Config配置中心的服务端。

YML

yml文件里面通过uri指定了配置中心在码云仓库中对应的仓库地址，这样我们在启动cloud-config-center-3344模块之后，就可以通过这个模块访问到远程码云中的配置中心了，访问地址就是127.0.0.1:3344/master/配置文件的名字，但是因为我们在hosts文件中进行了ip地址映射，我们把127.0.0.1映射给了config-3344.com,因此我们可以通过地址config-3344.com:3344/master/配置文件的名字直接访问到远程仓库的配置中心中的配置。

主启动类

Windows下修改hosts文件，增加映射

无论是Linux系统还是Windows系统，它的内部都有一个hosts配置文件，在这个文件里面可以进行地址和域名的映射，这里配置springcould的配置中心和本机地址127.0.0.1的映射，如下图：

启动类启动错误

启动SpringCloud的配置中心服务端的时候哦，出现了错误，如下图：

重新启动错误消失，如下图：

测试

首先需要开启Eureka7001/7002注册中心服务，然后需要开启cloud-config-center-3344服务，启动的时候需要把3344服务先注册到注册中心去，如下图：

现在要试一下，通过我们的配置中心客户端cloud-config-center-3344工程，能不能访问到远程仓库中的配置中心服务端中的配置，如下图：

需要注意的是我们配置中心里面的配置必须要和工程的src目录在同一个目录下，也就是在工程的直接下级，如下图：

对应到码云的远程仓库中如下图：

如果这个配置文件不在配置中心所对应的仓库的直接下级会出现什么情况呢？就是我们搜索的时候会搜索不到内容，如下图：

配置读取规则

记住两种配置读取规则就行了，第一种就是我们上面示例的那种，/{application}-{profile}.yml,这种配置对应的访问地址是config-3344.com:3344/config-dev.yml,它默认是去访问的码云上的master主分支，它其实相当于是

config-3344.com:3344/master/config-dev.yml,这种读取配置文件的规则其实也就是我们第二种配置文件的读取规则，它的规则是这样的**/{label}/{application}-{profile}.yml**,它读取的时候会指定读取的分支，如果我们想要读取master主分支中的开发环境的配置文件，它对应的访问地址是config:3344:3344/master/config-dev.yml如下图：

如果想要读取dev开发分支中的开发环境的配置文件，访问的地址是config-3344.com:3344/dev/config-dev.yml;

第二种配置读取规则是我们常用的配置文件读取规则，因为我们可以指定我们读取的分支是那一个。

其中{lable}表示的是分支，{application}表示的是配置名，{profile}表示的是环境。

Config客户端配置与测试

新建cloud-config-client-3355模块

POM

bootstrap.yml

bootstrap.yml是什么呢？为什么我们之前用的application.yml好好的要突然改成bootstrap.yml呢？

其实bootStrap就相当于是我们学习JVM的类加载器的时候的那个BootStrap根加载器，其实这里的bootstrap.yml配置文件用的就是双亲委派机制，如果最上层的父级存在，那么就不会寻找下层中的东西，所以这里使用bootstrap.yml文件的时候，会先从外部加载配置文件，只要外部有相关的配置，那么即便是在自己的bootstrap.yml配置文件中重新配置此配置也没有效果，程序仍然会用外部的配置，而不会去用bootstrap.yml自身的配置。但是如果要是用的application.yml这个配置文件的话，配置文件中的配置会覆盖外部的配置。所以bootstrap.yml文件和application.yml文件的区别就是：一个是外部配置的优先级高，另外一个是自身的配置的优先级高。

application.yml是用户及的资源配置项,而bootstrap.yml是系统级的，优先级更加高。

Spring Cloud会创建一个"Bootstrap Context",作为Spring应用的"Application Context"的父上下文。初始化的时候，“Bootstrap Context”负责从外部源加载配置属性并解析配置。这两个上下文共享一个从外部获取的"Environment"。

“Bootstrap”属性有高优先级，默认情况下，它们不会被本地配置覆盖。"Bootstrap context"和"Application Context"有着不同的约定，所以新增了一个"bootstrap.yml"文件，保证"Bootstrap Context"和"Application Context"配置的分离。

要将Client模块下的application.yml文件改为bootstrap.yml文件，这很关键，因为bootstrap.yml是比application.yml先加载的。bootstrap.yml优先级高于application.yml。

此模块中的bootstrap.yml文件如下图：

上图中的spring.application.cloud.config标签可以从注册中心中引入配置进来，如果bootstrap.yml中的一些配置和码云注册中心引入进来的外部配置相冲突，那么默认会使用码云配置中心引入的外部配置；如果bootstrap.yml中的配置码云配置中心中没有，那么会使用此配置。所以使用bootstrap.yml配置文件可以把我们自己的配置和外部引入的配置相综合