dubbo 選用zookeeper的緣由

dubbo主要是一個分佈式服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。簡單的說，dubbo就是個服務框架，若是沒有分佈式的需求，實際上是不須要用的，只有在分佈式的時候，纔有dubbo這樣的分佈式服務框架的需求，而且本質上是個服務調用的東東，說白了就是個遠程服務調用的分佈式框架（告別Web Service模式中的WSdl，以服務者與消費者的方式在dubbo上註冊） 
來個圖片就簡單明瞭 
 
上圖是傳統方式的，假如我有四臺服務器，每臺服務器都提供相同的服務，若是我消費者去掉用的時候，確定要在四個當中選擇某一個去調用，但是選擇哪個就是一個難題，固然這就涉及到負載均衡問題了，需用到F5(其實我也沒用過F5。。。)或者咱們在消費者這邊加代碼邏輯判斷達到負載均衡的效果，還有每次調用的時候都要查詢當前有哪些服務提供者，這是很耗開銷的。

方案都是一步一步進化的。 

咱們在消費者和服務提供者之間加了一層服務路由。服務路由提供F5功能同事還提供代理服務的地址，代理地址是穩定的，這樣就算服務提供者地址改變了，消費者直接調用代理服務器地址給 服務器路由，讓服務器路由本身去查詢，減少開銷

最終方案

咱們利用zookeeper生成的節點樹，服務器提供者在啓動的時候，將提供的服務名稱和地址以節點的方式註冊都服務器zookeeper服務器配置中心，消費者經過服務器配置中心獲取須要的服務名稱節點下的服務地址。由於znode有非持久節點的特性，服務器能夠動態的從服務配置中心一處，而且觸發消費者的watcher方法！！！ 
消費者只有在第一次調用的時候直接本地緩存服務器列表信息，而不需喲從新發起請求到服務器配置中心區獲取相應 的服務器列表，直到服務器地址列表有變化（機器下線或者上線），變動廚房消費者watcher進行服務地址的從新查詢。正是由於赭紅無中心化的結構，使得服務消費者在服務信息沒變動時候，幾乎不依賴配置中心，解決了負載均衡設備致使的單點故障的問題，大大獎勵了服務配置中心的壓力