Spring Cloud Config配置中心
我在学习Spring Cloud Config配置中心时理解了它体系下的配置中心的强大。实现了配置的远程管理、微服务的配置更新。Spring Cloud Config配置中心体系还是有其不足的地方。虽然它实现了配置和服务的分离。但是做不到实时的更新。需要手动触发POST /refresh Api接口（如果使用Spring Cloud Bus的话也是一致，不过它实现了一致更新的优点，但是也是需要手动触发 POST /bus/refresh API才能使微服务配置重新生效），虽然可以使用git的Watcher机制，当我更新新的配置文件时(对，Spring Cloud Config 使用的文件配置格式)，会触发git的Watcher然后触发/bus/refresh或者/refresh接口，使得配置能够在微服务中更新。
Spring Cloud Config 不足之处
Spring Cloud Config的不足之处，肯定是和现有的开源框架相比较得出来的结论。但是从管理者的角度来说（可能是从中国人的角度），最好能够可视化，如果不能可视化的话，我也不知道原有的配置是什么，也无法在线对其它相关的服务，程序进行管理，配置上是否冲突。方便开发和运维进行配置(有的公司对于配置可能是归属于运维的职责)。第二，能够实现实时的推送，当然可能需要依赖第三方中间件。至于探究国内开源框架和Spring Cloud Config的优劣，方便公司选型的或者了解的请百度 https://www.colabug.com/4227288.html。
简单的提及一下携程的Apollo,主要是说一下的我的看法。 携程的框架是基于微服务的配置中心，主要的组件ConfigService、AdminService、Eureka Registry Center、Config Client、Config Core、 Web。服务提供者ConfigService和AdminService 提供配置和权限的管理，Eureka Registry Center提供服务之间的联系和心跳查询，防止服务的崩溃，Client主要是外接配置使用者。上述的架构还是比较成熟，将微服务使用的轻车熟路。但是唯一的不开心的地方就是Config Client组件的开发，Client(Apollo-Client)使用的是Guice作为IOC容器，为了兼容Spring XML配置等，重新开发Spring XML配置类，这可能只是架构选型的问题，可能对于我这种使用Spring熟的人有的不快吧，还有携程对于以前使用的大量遗留框架(大量.NET架构)的兼容，其实使得这个Apollo显得臃肿。
正文 DisConf
Disconf主要的组件有三个：Disconf-core、 Disconf-client、Disconf-web。Disconf-core实现了Http连接、zookeeper的配置和常用的工具类的使用，代码写的是有的薄。对于远程服务的选择策略、以及重试策略，不如Spring Cloud Config Client Rule提供的策略多，默认是轮询策略、3次重试策略。
//TIDO：内容下次更新