引言：

分布式系统面临的配置问题：
微服务意味着要将单体应用中的业务拆分成一个个子服务 ，每个服务的粒度相对较小，因此系统中会出现大量的服务。由于每个服务都需要必要的配置信息才能运行,所以一套集中式的、动态的配置管理设施是必不可少的。如果我们每个微服务自己带着一个application.yml配置文件，上百个配置文件的管理，我们肯定会特别抓狂的，所以SpringCloud提供了ConfigServer（分布式配置中心）来解决这个问题。

1.分布式配置中心是什么？

SpringCloud Config分为和两部分。

• 服务端也称为分布式配置中心，它是一个独立的微服务应用，用来连接配置服务器并为客户端提供获取配置信息，加密/解密信息等访问接口。
• 客户端则是通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息配置服务器，默认采用git来存储配置信息,这样就有助于对环境配置进行版本管理,并且可以通过git客户端工具方便的管理和访问配置内容。

2.能干什么？

• 集中管理配置文件。
• 不同环境不同配置，动态化的配置更新，分环境部署比如dev/test/prod/beta/release。
• 运行期间动态调整配置，不再需要在每个服务部署的机器上编写配置文件，服务会向配置中心统一拉取配置自己的信息。
• 当配置发生变动时，服务不需要重启即可感知到配置的变化并应用新的配置。
• 将配置信息以REST接口的形式暴露。

注意：
本篇博客所讲的配置是利用Git以及GitHub来进行一个配置整合，把GitHub当做分布式配置中心的云仓库。

1.新建一个仓库，仓库名称为springcloud-config：

2.将我们配置好的三个配置文件上传到GitHub上：

其中三个配置文件内容分别如下所示：

• application-dev.yml:

• application-pro.yml:

• application-test.yml:

具体操作方法可以参照我的另外一篇博客：使用Git提交本地项目到GitLab的几种方式，这篇博客写的是如何提交文件到GitLab上，提交文件到GitHub也是一样的操作。

3.操作全部成功完成之后，仓库内容如下所示：

至此GitHub云配置仓库搭建完成。

1.新建一个子模块configserver-3344，在pom.xml文件中导入分布式配置服务端依赖：

2.application.yml配置文件如下：

3.在启动类中加上@EnableConfigServer注解，开启分布式配置中心功能：

4.先启动eureka注册中心，再启动configserver-3344。

5.三种读取配置规则：（其中label为分支，name为名称，profile为环境）

• 第一种，/{label}/{name}-{profile}.yml，访问http://localhost:3344/master/application-test.yml：

• 第二种， /{name}-{profile}.yml，访问http://localhost:3344/application-test.yml，默认访问分支为master主分支：

-第三种， /{name}-{profile}/{label}.yml，访问http://localhost:3344/application-test.yml/master，返回的是一个json串：

一般常用的是第一种方式

至此，分布式配置服务端搭建完成。

1.新建一个子模块configclient-3355，在pom.xml文件中导入分布式配置客户端依赖：

2.将application.yml配置文件改名为bootstrap.yml

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

在该文件中加入以下配置：

需要注意的是：

3.然后新建一个控制器，写一个读取云端配置的方法：

如果分布式配置中心配置成功，configclient-3355就能从configserver-3344上拿到它从github仓库中读取的配置文件信息。

4.依次启动eureka，configserver-3344，configclient-3355：

5.访问http://localhost:3355/configInfo，成功得到配置信息：

至此，分布式配置客户端搭建完成。

1.动态刷新是什么？

简单来说就是当Github上的配置文件内容发生变化时，分布式配置的服务端和客户端能够得到及时、实时的更新。

2.为什么需要使用动态刷新？

平时开发我们经常会涉及一些配置文件的更改操作，比如Linux运维修改Github上的配置文件内容。那我们服务端和客户端能否得到及时的更新呢？

毫无疑问，ConfigServer配置中心是可以得到实时更新效果的，因为它是直连GitHub仓库，但是ConfigClient是通过ConfigServer间接访问GitHUb上的配置文件的，那么它能否得到实时的更新呢？

我们可以做一个实验：

首先，我们将GitHub上面的application-dev.yml配置文件的版本修改为2.0：

再不重启任何服务的情况下，访问ConfigServer：http://localhost:3344/master/application-dev.yml/：

发现ConfigServer能够进行实时的更新

再访问ConfigClient：http://localhost:3355/configInfo

发现版本却还是显示为1.0，无论刷新多少次都没有效果！除非重启客户端服务！

那难道每次我们每次修改云端的配置文件，客户端都需要进行重启吗？如果真的需要这么操作的话那将会是灾难级的，当我们微服务模块越来越多的情况下，分布式配置的客户端就会越来越多，那每次都需要重启操作，这将是一件特别影响性能的事情！所以我们引入了Config客户端动态刷新的概念。

3.实现过程

在configclient-3355的pom.xml文件中引入actuator监控依赖：

修改bootstrap.yml配置文件，添加以下内容，暴露监控端口：

在控制器中加入@RefreshScope注解，开启客户端配置热更新：

4.重启服务后，将GitHub上面的application-dev.yml配置文件的版本修改为3.0：

在不重启任何服务的情况下，访问ConfigServer：http://localhost:3344/master/application-dev.yml/：

特别注意：

在访问ConfigClient之前需要先发送post请求：http://localhost:3355/actuator/refresh，刷新config-client，在这里我用的是postman发送post请求：

之后在不重启任何服务的情况下，再访问ConfigClient：http://localhost:3355/configInfo

发现版本号已经变成了3.0，成功实现了客户端3355刷新到最新配置内容，避免了服务的重启，实现了分布式配置中心客户端的动态刷新功能！！！