本文旨在表述出自己對於zookeeper在dubbo的作用的初步理解
在對dubbo進行了初步的探索後，對於zookeeper在其中的作用不甚了解，因為本身對zookeeper就沒有乙個特別具體的概念，所以在這裡思考一下，為什麼要使用zookeeper或者說dubbo為什麼要有註冊中心
一對一的呼叫
server a依賴server b提供的rpc服務，因為server b只有單一的乙份，那麼此時server a只需要server b提供rpc呼叫的ip和port就可以了
一對多的呼叫
server b在使用者量日益擴大的背景下，需要進行橫向擴充套件，此時的server b擴充到了3臺伺服器：01，02，03
這樣做的好處是：
一台宕機，還有兩個正常運轉的server可以提供服務；當訪問量大的時候，可以進行負載均衡(並不是zookeeper實現的，具體的負載均衡演算法需要自己實現，zookeeper能提供給我們的是可用服務列表)
那麼對於server a來說，一下子有3個server b可以使用，該如何選擇呢？如果我選擇了01，我還需要去關心，01是不是掛了，01掛了我選擇誰呢？
對於server b來說，我如何進行負載均衡呢？
其實對於server a來說，我不想要關心server b的主備情況，我希望server b的整個分布對於我這個呼叫方是完全透明的，那麼考慮一下這種結構：
其實這個結構很好理解：由於server b的分布式部署，server a有選擇困難症不知道該選擇哪乙個b，那麼我們就讓中間人幫他選並告訴他，然後server a知道要找誰了，就會去找相關的server。圖中黃色的線代表了註冊通知過程，綠色的線代表了呼叫過程。
例如，server b的3臺伺服器都註冊乙個「獲取使用者列表」的rpc介面到zookeeper中，server a作為客戶端連線zookeeper，向zookeeper討要乙個「獲取使用者列表」介面，拿到這個介面的相關資訊之後，server a再去呼叫具體的server b的某一台伺服器上的服務。即：註冊中心（zookeeper）不做實際的方法呼叫，只做相關資訊的傳遞者。
總結，綜上所述，zookeeper自己本身沒有負載均衡功能，主要提供服務 發布/訂閱 的功能，並通過集群的方式保證服務的一致性和可靠性，但是他的特性可以分布式應用程式基於它來實現類似負載均衡的能力。比如dubbo消費者取得了伺服器列表之後，根據一定的選擇演算法（預設是隨機呼叫）呼叫其中的乙個，就實現了類似負載均衡。
參考文章：
zookeeper在dubbo中作用
最近在給一些人講架構的時候,常被問到乙個問題,dubbo與zk是什麼關係,所以今天我就來簡單整理一下 dubbo建議使用zk作為服務的註冊中心,當然也可以使用redis等等 我覺得這個很好理解哦,哪乙個服務得由哪個機器來提供必需得讓呼叫者知道.也就是ip與服務名稱的對應關係 dubbo服務提供者在z...
zooKeeper在dubbo中的應用
iscoder 2017 05 03 23 38 前面幾篇文章說了很多zookeeper的功能特性，zookeeper是乙個分布式應用下的分布式 開源的協調服務。說了那麼多，那麼到底在實際開發中，zookeeper是怎麼提供服務的呢？這篇文章小段就簡單講述一下zookeeper在dubbo中的應用，...
Zookeeper在Dubbo中的應用
摘要 zookeeper在dubbo中的應用 dubbo的架構 節點角色說明 provider 暴露服務的服務提供方。consumer 呼叫遠端服務的服務消費方。registry 服務註冊與發現的註冊中心。節點角色說明 provider 暴露服務的服務提供方。consumer 呼叫遠端服務的服務消費...