一、为什么会有spring cloud config
1、微服务意味着要将单体应用中的业务拆分成一个个子服务，每个服务的粒度相对较小，因此系统中会出现大量的服务，由于每个服务都需要必要的配置信息才能运行，所以一套集中式的、动态的配置管理是必不可少的。
2、当我们系统业务扩展到一定程度的时候；免不了会增加很多的配置文件和信息，例如证书文件、接口对接的参数信息、数据库连接信息等；传统的单体式架构系统，SSH、SSM还是Struts等，只能是一个文件一个文件的增加堆积到项目系统中。每次更改配置信息的时候，都要重启服务器，影响线上业务浪费时间等。当配置文件数量达到一定程度的时候，整个项目就会看起来非常臃肿冗余，更甚者可能会拿错配置信息导致程序崩溃等。那么，这时候分布式系统采用的配置中心的优势就突出出来了。由业务拆分的多个模块系统的各配置文件，全部配置在配置中心统一管理；与程序分离，做到动态配置获取配置信息。无需重启服务器即可动态刷新加载配置信息。（本篇文章只是讲解了分布式配置中心，本博客会持续更新博主get到的技能。）
二、介绍spring cloud config。
Spring Cloud Config 分为两个部分：Config Server 和 Config Client。下面介绍这两部分怎么工作。
Config Server：服务端也称为分布式配置中心，它是一个独立的微服务应用。用来连接配置服务器并为 Spring Client 客户端提供配置信息。
Config Client ：客户但通过指定的配置中心来管理应用资源、以及业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息。
本篇文章是采用从git上获取配置信息
git中上传的配置文件格式：{spring.application.name}-{type}.properties
例：我的服务名字是bins-eureka-gateway。
type也是有一定讲究的
开发环境（dev)：开发环境是程序猿们专门用于开发的服务器，配置可以比较随意，为了开发调试方便，一般打开全部错误告。
测试环境(test)：一般是克隆一份生产环境的配置，一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上。
生产环境（prod）：是值正式提供对外服务的，一般会关掉错误报告，打开错误日志。
因此根据我的服务名字加上开发环境（type）则配置文件名称为bins-eureka-gateway-dev.yml（当然porperties类型也可以的）
您也可以去我的git地址，查看我的配置文件。
三、搭建spring cloud config配置中心
1、spring cloud config server
pom.xml文件添加相关依赖：
application.yml文件
当然这个端口号也是可以改变的，但是配置文件就不能建applicaiton.yml（用户级别）而是bootstrap.yml（系统级别），因为微服务默认会在8888端口号去寻找配置文件信息，由于application.yml文件是用户级别的配置文件，并不能修改这个默认配置。因此需要系统级别的配置文件才能够修改配置文件的端口号信息。
启动类上要添加@EnableConfigServer。
git上我上传了eureka-feign-dev.yml里面是我前几篇博客中配置好的服务降级限流等。
启动spring cloud config server。发现配置中心server会从远端git拉取配置文件并方在本地git一份，
测试一下是否可以访问到配置文件：http://localhost:8888/gateway-service-dev.yml
因为我的是网关中的一些配置，因此网关服务的配置中心还需要添加以下配置连接spring cloud config
下面测试一下网关gateway是否可以从config中获取配置文件信息。
启动注册中心，配置中心，网关，测试服务。
gateway成功从config中读取到了配置信息。实现路由转发。
当然您也可以是在我的基础上用我的代码测试一下熔断降级，和服务限流。
