一：定义
用来为分布式系统中的基础设施和微服务应用提供集中化的外部配置支持，它分为服务端与客户端两个部分。其中服务端也称为分布式配置中心，它是一个独立的微服务应用，用来连接配置仓库并为客户端提供获取配置信息、加密 / 解密信息等访问接口；而客户端则是微服务架构中的各个微服务应用或基础设施，它们通过指定的配置中心来管理应用资源与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息。
客户端从应用配置管理获取配置信息的流程
1：应用启动时，根据bootstrap.properties中配置的应用名{application}，环境名{profile},分支名{label}向config server请求配置信息
2：config server根据自己维护的Git仓库信息和客户端传递过来的配置定位信息去查找配置信息
3：通过git clone将找到的配置信息下载到config server的文件系统中
4：config server创建Spring的applicationContext实例，并从git本地仓库中加载配置文件，最后将配置文件读出返回给客户端使用
5：客户端应用在获得外部配置文件后加载到客户端的applicationContext实例，该配置内容的优先级高于客户端jar包内部的配置内容。所以jar包重复的内容将不会再被加载。
二：实现方式
第一种方式：Git版和动态刷新
构建了config-server，连接到Git仓库
在Git上创建了一个config-repo目录，用来存储配置信息
构建了config-client，来获取Git中的配置信息
在config-client中开启了Refresh，动态刷新配置信息
第二种方式：服务化与高可用
另外一种方式更为简单的方法就是把config-server 也注册为服务，这样所有客户端就能以服务的方式进行访问。通过这种方法，只需要启动多个指向同一Git仓库位置的config-server就能实现高可用了
消息总线：Spring Cloud Bus
其实本质是利用了MQ的广播机制在分布式的系统中传播消息，目前常用的有Kafka 和 RabbitMQ。其中配置中心客户端刷新就是消息总线典型的应用场景之一。整个系统的架构图如下。包括了git仓库，config server和几个微服务应用的实例，这些微服务实例都引入了Spring Cloud Bus，所以它们都连接到了RabbitMQ的消息总线上
当系统启动时，图上的三个service A实例会请求config server以获取配置信息，而config server则根据配置的仓库信息和定位信息去Git仓库获取配置消息并返回。
此时，若我们修改service A的配置信息，首先，通过Git管理工具去仓库中修改对应的属性值，但是这个修改是不会触发service A的实例进行属性更新。我们向service A的实例3发送post请求，访问/bus/refresh接口，此时service A的实例3就会将刷新请求发送到消息总线上，该消息会被service A的实例1和2从总线中获得，并重写从config server中获取他们的配置信息，进而实现了配置消息的动态更新。
架构优化：
在config server中也引入spring cloud bus，将配置服务端加到消息总线上
/bus/refresh不在发到具体的服务实例上，而是给配置服务端，并通过destination指定需要更新配置的服务实例。这样具体的服务实例不需要承担触发配置更新的职责。