背景
在分布式系統(tǒng)中，一次構建、發(fā)布、上線是非常非常重的一個過程，它不像單機時代那樣重啟一臺機器、一個進程就可以了，在分布式系統(tǒng)中，它涉及到將軟件包分發(fā)到可能超過幾千臺機器，然后將幾千臺機器上的應用進程一一重啟，這么一個過程，一個應用一次完整的發(fā)布過程需要多長時間，相信很多核心系統(tǒng)的同學都深有體會；
而在不停應用集群的前提下，調整應用集群的運行特征，是作為一個分布式系統(tǒng)必須解決的一個問題。
從這個角度來看：統(tǒng)一配置中心是一個分布式系統(tǒng)都必須具有的一個角色。
配置中心架構
image.png
配置中心關注點
- 配置中心的弱依賴
應用應該弱依賴于配置中心，如果配置中心掛掉，不能影響應用的正常運行
所以客戶端應該緩存配置數據 - 配置存儲應該做好容災備份
配置中心的數據是不能丟失的，如果丟失了，估計幾百個配置項就無法尋回，這種是無法允許的 - 推送時延和推送成功率
如上節(jié)使用zookeeper來說，watcher機制并不能保證每一次配置的更改都推送給客戶端，這種對于應用也是一件無法允許的事情 - 灰度
如果使用zookeeper來做配置中心，做灰度是一件很難的事情，不是說不能做，是需要客戶端去配合過濾一些不必要的數據，而這種造成了網絡的垃圾開銷及客戶端的復雜度，下文會詳細說 - 集中入口及變更審計能力
Zookeeper配置管理的局限性
- 配置數據大小的問題
對于Zookeeper來說，數據大小直接影響了它的讀寫性能，身單個節(jié)點數據越大，對網絡方面的吞吐就會造成影響，而zookeeper也添加了單個節(jié)點數據內容不能超過1M的限制，這個問題帶來的解決方案有：
1）一個應用一個節(jié)點，節(jié)點的內容存放所有配置數據，結果是一個節(jié)點數據估計有幾十K，當Zookeeper進行數據同步時，帶寬估計會被它全部吃掉；例子有：
http://blog.jobbole.com/112233/
2）一個Key一個節(jié)點，節(jié)點內容對應于Value，一個應用估計對應于幾十個節(jié)點，運維管理成本大幅上升 - 配置數據環(huán)境屬性不同的問題
在現(xiàn)實中，配置數據是要具有環(huán)境屬性的，相當一部分配置在不同的環(huán)境必須設定不同的值，但是也有相當的另一部分配置在不同的環(huán)境要設定為完全一致的值。所以從某個應用的視角看，其100個配置項，可能有50個是每個環(huán)境要不同的值的，而另50個是不區(qū)分環(huán)境；而zookeeper只要把數據寫入了znode中，必然會把數據通知給各個客戶端，這種做法帶來了兩個問題：
1）垃圾網絡開銷；
2）應用需要按照規(guī)則進行過濾不需要的配置信息； - 集群下（Observer模式）同步的問題
zookeeper為了提升寫性能，增加了一直O(jiān)bserver的部署節(jié)點，該類型節(jié)點下不參與投票選舉，只接收投票結果，該種模式一般多用于跨數據中心的部署，然而涉及到跨數據中心，就意味著網絡抖動的問題，每一次網絡抖動都會導致數據同步的重新進行（無論是差異化同步或者全部同步），這種情況下會導致連接到observer節(jié)點的數據不是最新的，從而導致配置數據無法及時通知到達 - Watcher注冊機制
許多人選擇使用zookeeper做配置中心關鍵的一點就是watcher機制，但是使用watcher有幾個要注意點：- Watches通知是一次性的，必須重復注冊.
- 發(fā)生CONNECTIONLOSS之后，只要在session_timeout之內再次連接上（即不發(fā)生SESSIONEXPIRED），那么這個連接注冊的watches依然在。
- 節(jié)點數據的版本變化會觸發(fā)NodeDataChanged，注意，這里特意說明了是版本變化。存在這樣的情況，只要成功執(zhí)行了setData()方法，無論內容是否和之前一致，都會觸發(fā)NodeDataChanged。
- 對某個節(jié)點注冊了watch，但是節(jié)點被刪除了，那么注冊在這個節(jié)點上的watches都會被移除。
- 同一個zk客戶端對某一個節(jié)點注冊相同的watch，只會收到一次通知。即
Watcher對象只會保存在客戶端，不會傳遞到服務端。
另外最主要一點就是zookeeper并不保證每次節(jié)點的變化都會通知到客戶端，原因是因為當一次數據修改，通知客戶端，客戶端再次注冊watch，在這個過程中，可能數據已經發(fā)生了許多次數據修改
