SpringCloud Config分布式配置中心
①微服务概述中提到了:SpringCloud Config。
就目前而言，对于微服务业界并没有一个统一的、标准的定义（While there is no precise definition of this architectural style）
但通常而言， 微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行在其独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务（这个管理就是SpringCloud Config），可以使用不同的语言来编写服务，也可以使用不同的数据存储
②分布式系统面临的---配置问题。
微服务意味着要将单体应用中的业务拆分成一个个子服务，每个服务的粒度相对较小，因此系统中会出现大量的服务。由于每个服务都需要必要的配置信息才能运行，所以一套集中式的、动态的配置管理设施是必不可少的。SpringCloud提供了ConfigServer来解决这个问题，我们每一个微服务自己带着一个application.yml，上百个配置文件的管理......
③SpringCloud Config分布式配置中心是什么。
SpringCloud Config有Server（服务）端，即SpringCloud ConfigServer 和
SpringCloud Config的Client（客户）端，即SpringCloud ConfigClient端。
SpringCloud ConfigServer自己就是一个分布式的微服务。
SpringCloud Config为微服务架构中的微服务提供集中化的外部配置支持（可以使配置和编码分开），如：其中一个或者一些微服务，需要连接的数据库有变动，连接的数据库的用户名和密码已经修改，数据库一般由运维工程师和DBA来维护。一种方法是，运维工程师或者DBA通知开发工程师来修改。第二种是，运维工程师（或者叫配置工程师，也许他/她根本不懂java，甚至没有权限来写java代码。但是他/她有权限来更改GitHub上的某些配置内容。）在GitHub远程端修改了配置文件，这个修改被SpringCloud ConfigServer感应到，然后由SpringCloud ConfigServer去通知SpringCloud ConfigClient A、B、C。。。。。。。。。，通知这些config的客户端（即开发工程师），哪些微服务的数据库配置文件需要作出改变。配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。可以处理动态的多种环境的切换，更加的灵活。
④SpringCloud Config分布式配置中心怎样使用呢。
SpringCloud Config分为服务端和客户端两部分。
服务端也称为分布式配置中心，它是一个独立的微服务应用，用来连接配置服务器并为客户端提供获取配置信息，加密/解密信息等访问接口
客户端则是通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息配置服务器默认采用git来存储配置信息，这样就有助于对环境配置进行版本管理，并且可以通过git客户端工具来方便的管理和访问配置内容。
⑤SpringCloud Config分布式配置能干嘛？
1、集中管理配置文件。
2、不同环境不同配置，动态化的配置更新，分环境部署比如dev（开发环境）/test（测试环境）/prod（生产环境）/beta/release。
3、运行期间动态调整配置，不再需要在每个服务部署的机器上编写配置文件，服务会向配置中心统一拉取配置自己的信息。
4、当配置发生变动时，服务不需要重启即可感知到配置的变化并应用新的配置。
5、将配置信息以REST接口的形式暴露。
由于SpringCloud Config默认使用Git来存储配置文件(也有其它方式,比如支持SVN和本地文件)，但最推荐的还是Git，而且使用的是http/https访问的形式。最推荐与GitHub整合配置。
