SpringCloud Config分布式配置中心_springcloud config 配置码云的仓库地址

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配置文件可以把我们自己的配置和外部引入的配置相综合

主启动类

业务类

测试

Config配置中心的服务端和客户端微服务都需要注册到Eureka注册中心中，因此首先要开启Eureka7001/7002服务端，接着要开启Config3344配置中心服务端，最后需要开启Config3355配置中心客户端，如下图：

Eureka注册中心如下图：

然后让配置中心服务端首先自测，看看能不能访问到码云注册中心的配置，如下图：

然后去浏览器中访问配置中心客户端暴露的接口，看看能不能访问到码云注册中心的config.info配置的内容，如下图：

并且从上图中可以看到，Config配置中心客户端和Config配置中心服务端和码云中的配置中心的配置全部都是一致的，所以客户端配置与测试成功，但是现在真的就没有问题了吗？请往下看。

修改config-dev.yml配置并提交到码云中

更改码云注册中心中的配置，如下图：

刷新配置中心服务端，如下图：

刷新配置中心客户端，如下图：

**结论：**我们如果在码云配置中心中更改配置，那么配置中心服务端可以立即刷新，但是配置中心客户端不会立即刷新，它的配置仍然和没有修改之前是保持一致的。

易错点

配置中心服务端和配置中心客户端中的分支的指定必须要保持一致，如下图：

比如说，上面的服务端中指定的分支是dev，那么客户端也必须指定dev分支，否则的话，客户端是加载不到码云注册中心中的配置的。

Config客户端之动态刷新

POM引入actuator监控

如下图：

修改YML，暴露监控端口

修改业务类Controller

在Controller控制器上需要加上这样一个注解@RefreshScope,如下图：

测试

现在再在码云的配置中心中修改配置之后，配置中心服务端3344和配置中心客户端3355都可以成功刷新。

先修改配置中心的内容，如下图：

然后去刷新3344服务端，如下图：

接着去刷新3355客户端，如下图：

原因

在码云配置中心中更改配置之后，需要运维人员发送Post请求刷新3355配置中心客户端，即需要在命令行终端发送一个请求，请求内容:curl -X POST “http://localhost:3355/actuator/refresh”，如下图：

但是我的上面的那个请求没办法成功发送，不知道为什么，写的和阳哥是一样的，但是阳哥的是可以成功发送的，我的却不能。按理来说成功发送之后，配置中心客户端就可以自动刷新了。

目前动态刷新并没有实现，所以在码云的配置中心修改配置之后，一定要重启一下配置中心客户端微服务。