一. 为什么需要配置中心？
配置文件是我们再熟悉不过的了，尤其是 Spring Boot 项目，除了引入相应的 maven 包之外，剩下的工作就是完善配置文件了，例如 mysql、redis 、security 相关的配置。除了项目运行的基础配置之外，还有一些配置是与我们业务有关系的，比如说业务存储、短信相关、邮件相关，或者一些业务上的开关。
对于一些简单的项目来说，我们一般都是直接把相关配置放在单独的配置文件中，以 properties 或者 yml 的格式出现，更省事儿的方式是直接放到 application.properties 或 application.yml 中。但是这样的方式有个明显的问题，那就是，当修改了配置之后，必须重启服务，否则配置无法生效。
目前有一些用的比较多的开源的配置中心，比如携程的 Apollo、蚂蚁金服的 disconf 等，对比 Spring Cloud Config，这些配置中心功能更加强大。有兴趣的可以拿来试一试。
接下来，我们开始在 Spring Boot 项目中集成 Spring Cloud Config，并以 gitee作为配置存储。除了 git 外，还可以用数据库、svn、本地文件等作为存储。
本文主要从以下两块来说一下 Config 的使用。
1.基础版的配置中心（不集成 Eureka）;
2.结合 Eureka 版的配置中心;
二. 基础版配置中心的使用
最简单的配置中心，就是启动一个服务作为服务方，之后各个需要获取配置的服务作为客户端来这个服务方获取配置。
1.先在 gitee 中建立配置文件
目录结构如下：
这里方便演示我们把数据库文件的配置搬到码云上，如下图所示：
后面我们演示如何不用本地的db.properties,而是用码云上的配置，如下图：
注意，码云上的配置文件名也不是随便命名，如下图：
比方这里的cart-service就是我们之前讲的服务提供者提供的服务名，dev和pro分别代表开发版和测试版。
2. 开始创建配置中心服务端
(1) 新建maven项目cloud_config_server，目录结构如图：
(2) pom文件中添加依赖
<!-- 引入config server依赖 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-server</artifactId>
</dependency>
(3) 新建application.properties,添加配置如下：
(4)通过@EnableConfigServer注解开启SpringCloud Config 的服务端功能
(5)启动服务，这时候我们就可以通过浏览器地址来访问码云上的配置了。
Spring Cloud Config 有它的一套访问规则，我们通过这套规则在浏览器上直接访问就可以。
/{application}/{profile}[/{label}]
/{application}-{profile}.yml
/{label}/{application}-{profile}.yml
/{application}-{profile}.properties
/{label}/{application}-{profile}.properties
{application} 就是应用服务名，对应到配置文件上来，就是配置文件的名称部分，例如这里对应cart-service。
{profile} 就是配置文件的版本，我们的项目有开发版本、测试环境版本、生产环境版本，对应到配置文件上来就是以 application-{profile}.yml 加以区分，例如cart-service-dev.yml、cart-service-pro.yml。所以{profile}对应我们这里的dev，pro。
{label} 表示 git 分支，默认是 master 分支，如果项目是以分支做区分也是可以的，那就可以通过不同的 label 来控制访问不同的配置文件了。
比方说我们在浏览器中输入地址：http://localhost:888/cart-service/dev/master，就能得到如下结果：
3. 在客户端使用配置
这里我们不专门新建一个客户端项目，就使用我们之前的cloud_cart_service2作为客户端，如图所示：
1. 在pom文件中添加config 客户端依赖
<!-- 引入config 客户端依赖 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-config</artifactId>
</dependency>
2. 新增bootstrap.properties配置文件：
3. application.yml文件保持不变，如图：
4. 启动类保持不变：
5. 数据源的配置我们之前是加载本地配置文件的方式，现在我们注释掉，应用码云上的配置，如图：
为了方便观察是否取到了码云上的配置，我们在下面的代码中输出url变量名，如图：
启动运行，观察日志发现已经取到了:
6. 关于配置文件bootstrap.properties和配置文件application.yml的区别：
(1).加载顺序上的区别
bootstrap.yml（bootstrap.properties）先加载
application.yml（application.properties）后加载
bootstrap.yml 用于应用程序上下文的引导阶段，由父Spring ApplicationContext加载。父ApplicationContext 被加载到使用application.yml的之前。
在 Spring Boot 中有两种上下文，一种是 bootstrap, 另外一种是 application, bootstrap 是应用程序的父上下文，也就是说 bootstrap 加载优先于 applicaton。bootstrap 主要用于从额外的资源来加载配置信息，还可以在本地外部配置文件中解密属性。这两个上下文共用一个环境，它是任何Spring应用程序的外部属性的来源。bootstrap 里面的属性会优先加载。
(2).bootstrap/ application 的应用场。
bootstrap.yml 和application.yml 都可以用来配置参数。
bootstrap.yml 可以理解成系统级别的一些参数配置。
application 配置文件这个容易理解，application.yml 可以用来定义应用级别的，主要用于 Spring Boot 项目的自动化配置。
(3).bootstrap 配置文件有以下几个应用场景。
使用 Spring Cloud Config 配置中心时，这时需要在 bootstrap 配置文件中添加连接到配置中心的配置属性来加载外部配置中心的配置信息；
一些固定的不能被覆盖的属性
一些加密/解密的场景；
(4)需要说明的是如果spring.application.name和server.port在bootstrap和application中都可配置了，那么application中的配置会覆盖掉bootstrap中的配置，所以请不要重复配置。
三. 结合Eureka的配置中心
鉴于我们之前的服务都纳入Eureka注册中心统一管理，那么我们的配置中心服务也是可以纳入进来的。接下来我们来改造上面的基础版本。
1. 在配置中心服务端pom文件加入Eureka的客户端依赖：
2. 在配置文件中加入配置：向注册中心注册自己：
3. 在启动类上加入注解@EnableDiscoveryClient， 实现服务注册和发现
4. 接下来我们来看一下客户端的改造，首先改造bootstrap.properties
这里要把application.yml中的eureka.client.serviceUrl.defaultZone: http://192.168.1.27:911/eureka这个配置移到bootstrap.properties这里来，因为要先注册自己才能发现服务，才能使用配置中心服务config-server。
5. application.yml去掉注册中心的配置即可，如图：
6.启动，运行，注册中心如下图所示：
我们发现配置中心服务注册上来了，客户端也注册上来了。
启动cloud_cart_service2之后，我们观察日志，发现码云上的配置也取到了，如下图：
如果对您有帮助，请点个赞吧