一般在随着大家的微服务项目越来越大的时候，对配置文件的管理就显得愈加复杂，总不能每次有修改都得去一个个找配置文件，这时候，分布式的配置服务就是必不可少的微服务一环了。
它主要是为了支持配置服务放在配置服务的内存中（即本地），也支持放在远程Git，SVN等仓库中。之后统一维护、统一更新、统一管理。
官方建议是使用Spring Cloud Config组件，但用过的人都会觉得.. 它的统一和自动更新都不怎么方便。
另外BAT也都开源过分布式配置中心组件，淘宝的diamond、百度的disconf、360的QConf，国外的也有像cfg4j这些。
diamond：淘宝内部绝大多数系统的配置，由diamond来进行统一管理。简单说一下几点，它的推拉模型是一种全量拉取的，大概15s一次，而且只支持KV结构的数据，而不是配置文件模式，在集群数据同步的情况下，一般是server写操作是写入数据库再写入本地文件，client订阅数据时，访问的是本地文件，不查询数据库，保证了订阅不会因数据库而出现问题，总体来说简单易用，但是偶觉得有点小问题，就是没有访问修改的权限控制。
disconf：来自百度的分布式配置管理平台，这套组件大多数互联网公司都有使用，像滴滴、网易，当然还有百度。与diamond有许多的不同，比如它是基于Zookeeper的实时推送，而不是定时拉取，另外它的数据可以是配置文件模式也可以是配置项模式（K-V），在实效、稳定和易用性上，应该都优于diamond，不过好像已经不再维护。
P.S
大家系统目前基于官方的建议，还是搭配的git、使用的SpringCloudConfig。对于其刷新机制的大坑，大家没有采用消息总线的方式（要是队列挂了不就刷不到了吗..），而是采取了长轮训加上mysql的自定义函数mysql-udf-http来监听配置文件的变化， 一旦有变化，就推送服务，以此来解决。
——没事待在家里不出门的 居家程序员。（偶不想脱发！）
