zookeeper在dubbo中幹什麼

本文旨在表述出本身對於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）不作實際的方法調用，只作相關信息的傳遞者。

 

更多須要關注的細節：

• dubbo的在向zookeeper註冊服務時，放了些什麼數據進去？
• dubbo的負載均衡是dubbo本身作的，仍是zookeeper作的？
• ...