分佈式環境下配置中心實現思考【推薦】

轉載註明出處： 季義欽的博客

最近在考慮分佈式環境下配置中心實現。

個人配置中心須要以下功能：

一、服務動態註冊和發現（包括負載均衡）

二、配置信息的讀取和寫入

三、配置信息、服務信息的監視（變化時通知）

針對配置中心有以下要求：

一、集羣支撐

二、快速的寫入和讀取

三、強一致性

四、跨語言client支持

對於配置中心很難設計。

光用Zookeeper吧，發現一是跨語言支持很差，須要大量跨語言支持的開發，並且沒辦法在上面增長大量的算法和邏輯。

若是在Zookeeper前面加一層服務來做爲輔助的話，又怕成爲單點壓力。

下面是我畫的一個架構圖，但願你們幫忙看看，踊躍討論。

但願各位無論有什麼意見和建議、都在下面評論裏面留下本身的想法，幫助我改進，謝謝

============================= 20140818晚補充==============================

其實我想了想，單點壓力並非太大的問題。

能夠爲Java服務構造集羣來解決，使用Nginx等負載均衡器作負載均衡，這樣單點壓力問題就沒有了。

可是這樣還有單點故障問題。

一旦負載均衡器出現故障，配置中心便沒法使用，整個系統也就沒法使用。

這個問題也能夠經過增長多個負載均衡器來實現，客戶端維護一個負載均衡器地址列表，選定一個做爲有效負載均衡器。

當請求達到必定超時時限時，就換一個來試，直到成功，並將新的負載均衡器的地址做爲當前有效地址記錄。

不過這樣作稍微有些麻煩。

其實除了上面講到的兩點以外，在Zookeeper前面加一層服務還有兩個很是關鍵的缺點：

一、watch機制難以實現。

二、自動檢測鏈接到Zookeeper 集羣是否存活(Zookeeper中有短暫的znode的概念)沒法實現，只能借用於定時向Java服務報告本身的情況這種傳統的作法。

其實能夠換一種思路，一樣是增長一個輔助服務，可是咱們並不讓其屏蔽掉後面的Zookeeper集羣，而是作一些算法方面的工做，好比當客戶端請求服務地址時，根據必定的負載均衡算法返回最合適的服務地址，然而這就須要爲Zookeeper Server集羣開發不一樣語言的客戶端。

直到最近ETCD進入個人視線，其提供REST API接口，即便用HTTP請求便可與Server集羣交互，在跨語言方面支持好像很好，有待繼續深刻了解。

====================== 2014年12月補充 ====================

Zookeeper對跨語言支持也比較成熟了，能夠用於生產環境！

ETCD也能夠用，二者均可以，可是相對來講Zookeeper應用較廣，成熟度較高，社區比較活躍，性能也高很多。