Cloud如何選擇分布式配置中心？

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

一般在隨著我們的微服務項目越來越大的時候，對配置文件的管理就顯得愈加復雜，總不能每次有修改都得去一個個找配置文件，這時候，分布式的配置服務就是必不可少的微服務一環(huán)了。

它主要是為了支持配置服務放在配置服務的內(nèi)存中（即本地），也支持放在遠程Git，SVN等倉庫中。之后統(tǒng)一維護、統(tǒng)一更新、統(tǒng)一管理。

官方建議是使用Spring Cloud Config組件，但用過的人都會覺得.. 它的統(tǒng)一和自動更新都不怎么方便。

另外BAT也都開源過分布式配置中心組件，淘寶的diamond、百度的disconf、360的QConf，國外的也有像cfg4j這些。

diamond：淘寶內(nèi)部絕大多數(shù)系統(tǒng)的配置，由diamond來進行統(tǒng)一管理。簡單說一下幾點，它的推拉模型是一種全量拉取的，大概15s一次，而且只支持KV結(jié)構(gòu)的數(shù)據(jù)，而不是配置文件模式，在集群數(shù)據(jù)同步的情況下，一般是server寫操作是寫入數(shù)據(jù)庫再寫入本地文件，client訂閱數(shù)據(jù)時，訪問的是本地文件，不查詢數(shù)據(jù)庫，保證了訂閱不會因數(shù)據(jù)庫而出現(xiàn)問題，總體來說簡單易用，但是我覺得有點小問題，就是沒有訪問修改的權(quán)限控制。

disconf：來自百度的分布式配置管理平臺，這套組件大多數(shù)互聯(lián)網(wǎng)公司都有使用，像滴滴、網(wǎng)易，當然還有百度。與diamond有許多的不同，比如它是基于Zookeeper的實時推送，而不是定時拉取，另外它的數(shù)據(jù)可以是配置文件模式也可以是配置項模式（K-V），在實效、穩(wěn)定和易用性上，應該都優(yōu)于diamond，不過好像已經(jīng)不再維護。

P.S

我們系統(tǒng)目前基于官方的建議，還是搭配的git、使用的SpringCloudConfig。對于其刷新機制的大坑，我們沒有采用消息總線的方式（要是隊列掛了不就刷不到了嗎..），而是采取了長輪訓加上mysql的自定義函數(shù)mysql-udf-http來監(jiān)聽配置文件的變化， 一旦有變化，就推送服務，以此來解決。

——沒事待在家里不出門的 居家程序員。（我不想脫發(fā)！）