这是我参与更文挑战的第22天，活动详情查看： 更文挑战
前言
从前有座山，山上有座寺，寺里有着4个殿堂 10个院堂，分别是小雄殿 小宝殿 小金殿 小心殿以及小罗堂，小若堂，小灰堂，小菩院，小律院，小道院，小王院，小舍院，小经阁，小达院。
每个殿院都有一名弟子有钥匙负责关门
一天晚上，方丈被困在小宝殿了，方丈叫让小明叫人过来开锁，然后小明满寺庙找小宝殿负责关门的人，把新钥匙交给他，晚上，有消息说首座被锁在了小王院，轻轻一推，把锁推断了，方丈又小明去找人修锁然后把钥匙交给小王院负责人，在回来的路上，小明发现西堂（一个职位）被关在小经阁，轻轻地叫唤，把小经阁的锁震断了，小明又从修锁师傅手里接过了一把新钥匙，然后跑去交给对应的负责人。
事后，寺里新增了一个职位————监院并且由小明担任，由监院拿着所有的钥匙，以后换锁，新钥匙只需要交给监院就行，再也不用着急忙慌的找各自的负责人啦！
为什么需要配置中心？
当服务越来越多（殿院关门负责人），每个服务又有各自的配置信息（相当与各个殿院的钥匙），比如数据库的连接信息，mysql、redis 、mongo 相关的配置，业务有关系的，比如说七牛存储、短信相关、邮件相关，或者一些业务上的开关 当某个服务的配置信息发生改变时，该服务必须要重启，重启过程就相当于小明拿新钥匙交给负责人的路上，一方面是耗时，另一方面，万一钥匙负责人正在做功课，小明是等他做完再给呢，还是中断他正在做的事，重启服务，要么我们需要在服务处于闲置状态下重启才不会对系统造成影响
Spring Cloud Config功能
Config提供了两个方面的功能
- 集中管理配置文件
- 配置信息自动刷新
Spring Cloud Config放在哪里？
- 配置服务放在配置服务的内存中（即本地）
- 放在远程Git仓库中
Spring Cloud Config组成
- 分两个角色，一是config server，二是config client
- 集中式 管理分布式环境下的应用配置
- 基于 Spring 环境，无缝 与 Spring 应用集成
- 可用于 任何 语言开发的程序
- 默认实现基于 git 仓库，可以进行 版本管理
- 可替换 自定义实现
Sonfig Server
Config Server是一个可横向扩展、集中式的配置服务器，它用于集中管理应用程序各个环境下的配置，默认使用Git存储配置文件内容，也可以使用SVN存储（据小编看到的一些博文说svn已经逐渐用的少了），或者是本地文件存储。 拉取配置时更新 git 仓库副本，保证是最新结果
- 支持数据结构丰富，yml, json, properties 等
- 配合 eureke 可实现服务发现，配合 cloud bus 可实现配置推送更新
- 配置存储基于 git 仓库，可进行版本管理
- 简单可靠，有丰富的配套方案
Config Client
Config Client是Config Server的客户端，主要负责操作存储在Config Server的配置内容，也就是对Config Server的配置内容进行curd
Config Client的使用
可用于存在配置信息（比如application.yml或application.properties）文件的服务，只需要在配置文件中指明需要使用Config Server哪个配置文件
spring:
application:
name: config-client
cloud:
#Config客户端配置
config:
label: master #分支名称
name: config #配置文件名称
profile: dev #读取后缀名称
uri: http://localhost:6666 #配置中心地址服务端的地址
今日小结
配置中心的技术点说的其实很简单，配置中心也是一个比较容易理解它是什么的组件，当然，深入理解它的原理方面，小编还有待加强，今天主要花时间在编一个与配置中心搭边的故事，想了很多中场景，但是又觉得用不上，最后想了一个小明的故事，好了，今日事今日毕，再见~
