百度的disconf，和攜程的apollo。

disconf，操作簡單，介面簡單

apollo，比disconf更加好用。能夠集中化管理應用不同環境、不同叢集的配置，配置修改後能夠實時推送到應用端，並且具備規範的許可權、流程治理等特性。

Apollo支援4個維度管理Key-Value格式的配置：

1. application (應用)：一個應用通常對應一個專案，也可以將一些公共的配置放到一個公共的application中，供其他的應用使用。

2. environment (環境)：一個應用通常對應不同的環境，apollo支援的環境有dev，fat，uat，pro，也可以自定義環境，目前沒必要。

3. cluster (叢集)：不是使用叢集的情況，使用的是default叢集。

4. namespace (名稱空間)：一組同類別的配置通常放在一個名稱空間中，比如mysql,rabbitmq的配置放在2個不同的命名空間裡。

可以瀏覽這篇文章，https://www.toutiao.com/i6598070560574407182/

分散式配置中心 可謂是SpringCloud的必備武器之一了。

一般在隨著我們的微服務專案越來越大的時候，對配置檔案的管理就顯得愈加複雜，總不能每次有修改都得去一個個找配置檔案，這時候，分散式的配置服務就是必不可少的微服務一環了。

它主要是為了支援配置服務放在配置服務的記憶體中（即本地），也支援放在遠端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來監聽配置檔案的變化， 一旦有變化，就推送服務，以此來解決。