一个大的项目或者系统中会有大量的微服务，每个服务都会有application.yml文件，如果你想更改一些配置，你需要对每个微服务进行修改但是要是有上百个微服务那就完了，你一天不用干别的了，就改配置文件玩儿了。所以我们需要一个东西能够让一些配置一次修改处处生效。 SpringCloud提供了ConfigServer来解决这个问题。SpringCloud Config为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置(所有配置文件我只认中心git仓库)。
我们可以将三个Client的一些共同的配置如数据库连接放在ConfigServer里。剩下一些不同的放在各自的配置文件里，公私分明。修改完了之后就可以提交到远程仓库了。
SpringCloud Config分为服务端和客户端两部分。服务端也称为分布式配置中心，它是一个独立的微服务应用，用来连接配置服务器并为客户端提供获取配置信息。
客户端则是通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息。配置服务器默认采用git来存储配置信息，这样有助于对环境配置进行版本管理。
2.Config服务端配置中心的搭建服务端为各个不同的微服务应用的所有环境提供了一个中心化的外部配置即git远程仓库所以我们要先创建一个远程仓库这里我选择国产的gitee因为github翻墙不好办，网速也挺慢，应该怎么办，害得是国产。首先新创建一个仓库，在仓库中加入这么几个测试用的配置文件文件
我的仓库地址(其实是从尚硅谷周阳老师那copy下来的他的在github上怕你们翻墙费劲)，其中把本地文件提交到远程git仓库看这里提交远程git仓库。这样我们就完成了中心化外部配置，git仓库的搭建。
然后我们在idea里面新建moudle文件，在pom文件中添加依赖
提前在hosts文件中添加127.0.0.1 config-3344.com
然后添加application.yml文件
然后再主启动类上添加@EnableConfigServer注解，开启eureka7001，和这个3344。测试一下看看服务端是不是能读到配置文件中的内容。
可以看到能正确的读到测试配置文件的内容说明config端配置成功。
3.Config客户端配置与测试创建客户端的moudle，在pom文件中添加config的依赖这个依赖和之前的不一样
这个不是spring-cloud-starter-config-server，因为他是客户端所以没有那个server。然后这个module的yml文件也和之前不一样，之前的都叫application.yml，这个应该是bootstrap.yml是系统级的，优先级更高，SpringCloud会创建一个“Bootstrap Context"，作为Spring应用的”Application Context"的父上下文。初始化的时候，"Bootstrap Context"负责从外部源加载配置属性并解析配置。这两个上下文共享一个从外部获取的“Environment”。这个类似于Config的Client端，bootstrap是从ConfigServer获取的相关配置，application.yml是自己的配置
#bootstrap.ymlserver: port: 3355spring: application: name: config-client cloud: config: label: master #分支名称 name: config #配置文件名称 profile: dev #读取后缀名称 上述三个综合http://localhost:3344/master/config-dev.yml uri: http://localhost:3344 #配置中心的地址#服务注册到eureka地址eureka: client: service-url: #设置与eureka server交互的地址查询服务和注册服务都需要依赖这个地址 defaultZone: http://localhost:7001/eureka #单机版
这个配置文件的config部分就是首先到3344上去找，然后去找master，然后访问这上面的name-profile(config-dev)文件。
主启动类没啥特别的加上两个注解@EnableEurekaClient，@SpringBootApplication。
业务类controller，客户端通过这个controller访问到3344上的配置文件。
@RestControllerpublic class ConfigController { @Value("${config.info}") private String configInfo; @GetMapping("/configInfo") public String getConfigInfo() { return configInfo; }}
打开7001Eureka配置中心，3344ConfigServer，3355ConfigClient。首先测试一下从3344获取dev.yml文件，
然后通过ConfigClient3355客户端访问3344这个中心节点，看看能不能通过3344从Gitee上获得相应的配置文件。
可以看出两者结果一样。说明ConfigClient能通过3344访问到远程仓库的配置文件。
现在我们在gitee上修改配置文件。version从7改到1
提交之后能再访问3344能马上看到version从7变成1。
但是客户端一点反应没有，需要你重启项目。
这玩意儿不能运维每次改完配置就在群里喊一声兄弟们改配置了大家重启一下。如果次次都是这样的话，那这个Config就太鸡肋了。所以一定有办法解决这个问题。
这就是我们的动态刷新通过动态刷新就能避免每次更新配置都需要重启客户端微服务3355。要想解决这个问题首先要添加一个依赖
这个就是监控我只要有一点变化就能被监控到。
在yml文件当中添加暴露监控端点
# 暴露监控端点 否则 curl -X POST "http://localhost:3355/actuator/refresh" 不可使用management: endpoints: web: exposure: include: "*"
在业务类ConfigController上添加一个注解@RefreshScope。然后修改完gitee远程仓库的值之后还需要运维人员再次发一个POST请求"http://localhost:3355/actuator/refresh" 。把远程仓库的version改成7。刷新3344
刷新3355
发现还是2(之前测试改的2)，没有变成7。然后我们通过curl -X POST "http://localhost:3355/actuator/refresh"post请求通知一下他应该改了。
然后我们可以看到3355成功动态刷新
假如有多个微服务3355/3366/3377。。。。每个微服务都要执行一次post请求，到时候写个脚本也行，但是如果有些不希望改，那这个就不行了，这样很难做到精准打击。所以我们就引出了Bus消息总线。Config配上Bus才是动态刷新更改配置文件的王炸组合。