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：內容下次更新