本文旨在表述出自己對於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做的？
- ...