原先每一个微服务都有一个自己的yml配置软件,在企业里面微服务工程可能有好几十个,每个微服务自带一个yml,这样的话运维的压力很大.

多个微服务客户端 Client 的配置文件都交给Config Server 分布式客户端配置信息管理, 然后Config Server和Git GitHub 等等产生关联,从git上面获取最新信息然后下载到本地, Config Server获取最新的配置信息之后,会挨个分发给微服务Client.

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


详情配置信息见 尚硅谷 48视频

新建项目 microservicecloud-config-3344 这个项目就是Config Server

pom.xml和yml配置信息参考项目 ,
启动类需要添加注解@EnableConfigServer

然后新建工程
microservicecloud-config-client-3355

然后配置文件什么都参考原来的

这里新建一个bootstrap.yml 配置文件

bootstrap.yml配置文件是系统级别的,优先级相比application.yml 更高

SpringCloud会创建一个Bootstrap Context ,作为Spring应用的Application Context的父上下文,初始化的时候,Bootstrap Context 负责从外部源加载配置属性并解析配置,这两个上下文共享一个从外部获取的Environment.
Bootstrap属性有高优先级,默认情况下,它们不会被本地配置覆盖,Bootstrap context 和 Application Context 有着不同的约定,
所以新增一个bootstrap.yml文件,保证Bootstrap Context 和 Application Context 配置的分离.


讲解Zookeeper的时候其实实现过分布式的配置中心，springcloudconfig的核心作用其实就是在于对配置进行管理

虽然springcloud使用springboot进行开发，节省了大量的配置文件，但每个服务依然有自己的application.yml配置文件，而且每个服务一般都有负载均衡，所以，这么依赖对于配置文件的统一管理就非常有必要了。




上图是springcloudconfig总体结构图。
左边这一块我们很熟悉，最开始有个eureka，它通过配置文件application.yml启动，在这个配置文件里面会指定端口，实例名，注册地址等

对于服务提供商来说，它也需要把相关信息写到application.yml文件中，比如数据库配置，端口，项目名称等，其中最重要的就就是要指定eureka的具体位置

这是前面反复说过的，但现在是基于cloudConfig的配置中心，最开始启动eureka的时候，eureka的具体配置就不是写死在eureka的application.yml文件中了，这个时候也会有application.yml（bootstrap.yml）配置文件，只是这里的配置指定的时候config的配置中心，在eureka启动的时候读取【配置中心】的配置，并启动

对于服务提供商也是同样的道理，以产品服务为例，它的application.yml文件也不在指定具体的配置，真实需要访问的数据库，端口等信息也是在启动的时候直接从【配置中心】读取。

所以说config配置中心在其中占据非常重要的位置，但config里面的配置从哪来呢？其实是从git服务器里面来的，开发者需要把相关的配置上传到git服务器，这里的git服务器可以自己搭建，也可以直接用github，后面项目为了方便就直接使用github了。