.Net配置中心-Zookeper版

簡介

   zookeeper的基本概念和做用這裏不作介紹，如今不少的公司都在使用它，提及它的做用，可能最早想到的是配置中心，能夠將配置項做爲一個node存儲在zookeeper中，其餘應用能夠「關注」這個節點，當配置的值發生變化的時候，其餘應用能夠很快的被通知到。

   這裏有一個細節，就是通知的次數，我在初次認識zookeeper的時候，覺得「關注」了某個節點後，以後這個節點的值發生變化均可以通知到，可是實際狀況是客戶端在「關注」了某個節點後，這個節點的首次變化會被通知到，以後的變化都不會再通知，若是想獲得以前的變化，須要在首次變動通知到後，再次「關注」這個節點，也就是說，zoookeeper中的「關注」通知是一次性的，相似於Web中Request/Response。

    基於這種狀況，zookeeper的Java客戶端Curator作了必定的優化，可是.Net尚未，基於此，我寫了一個zookeeper Watch的幫助類，能夠實現「一次關注，屢次通知」。

ZookeeperWatchHelp

  ZookeeperWatchHelp的核心很簡單，就是在"關注"了某個節點後，當節點發生變動，通知到應用程序後，馬上再次"關注"，以後才執行變動的處理程序。 

  目前代碼已經開源，地址是：https://github.com/zhaoyb/ZookeeperWatcherHelp

 

配置中心zookeeper版本

   以前的配置中心是基於心跳的，當配置發生變化，並不能馬上通知到客戶端，對於某些應用場景可能不適用，因此升級爲zookeeper版本。

   zookeeper版本的核心思想： 將應用Id(AppId)做爲一個node存入到zookeeper中，node的data是應用的版本號，修改配置的時候，除了修改應用的版本號，還要修改zookeeper中對用node的data。 客戶端在啓動的使用，註冊對指定節點數據變動的關注，當節點的值發生變化，會通知到客戶端，客戶端請求服務端拉取最新的配置。 

 

zookeeper版配置中心-服務端

在啓動的時候，主動建立一個節點，做爲配置中心的根節點。

在配置發生變化的時候，處理更新版本號，還要更新zookeeper中對應節點的data。節點的名稱就是應用的名稱。

 

zookeeper版配置中心-客戶端

客戶端的啓動方式和以前相似

在啓動的時候，首先會實例化zookeeper對象，須要zookeeper服務器的host和port，這些其實也是配置，因此會到服務端指定的應用下面獲取配置(這些配置須要事先配置好)，在拉取到zookeeper的配置後，實例化zookeeper配置，並註冊關注。

 

 

zookeeper的客戶端自己具備重連機制，因此當某個服務器宕機，會自動重連到另外的機器，這些對上層應用來講是透明的，可是爲了保證高可用，仍是作了一個降級處理，就是會每隔20秒鐘(這個時間能夠更長）主動到服務端校驗一次版本號。