之前在因公司產品項目做微服務拆分時使用了dubbo和zokeeper但感覺對他們的認知還是不太清楚。所以最近重新複習看了一下。用通俗的方式些事一下（如有錯誤請指正）
zokeeper （註冊中心）主要功能是服務註冊與發現的註冊中心。是用於分佈式中一致性處理的框架（建議理解爲數據庫，集中存儲其他系統可調用），以下爲zokeeper主要工作：
-
數據發佈訂閱，即註冊中心。
-
負載均衡
-
命名服務。zookeeper的節點結構天然支持命名服務，即把信息集中存儲，並以樹狀管理，方便統一查閱。
-
分佈式協調通知。協調通知實際上與發佈訂閱類似，由於引入的第三方的zookeeper，實際上對很多種協調通知做了解耦。
-
集羣管理與master選舉。通過上面的第二點特性，可以輕易得知集羣機器存活狀況，從而輕鬆管理集羣；通過上面第一點特性，可以做出master爭搶。
-
分佈式鎖。實際上就是第一點特性的應用。
-
分佈式隊列。實際上就是第三點特性的應用。
-
分佈式的併發等待。類似於多線程的join問題，主任務的執行依賴於其他子任務全部執行完畢，在單機多線程裏可以用join，但是分佈式環境下如何實現呢。利用zookeeper，可以創建一個主任務節點，旗下子任務一旦執行完畢，則在主任務節點下掛一個子任務節點，等節點數量足夠，則認爲主任務可以開始執行。
dubbo （遠程服務調用的分佈式框架）主要實現應用與zokeeper等註冊中心鏈接調用的工具（類jdbc工具類），dubbo爲你實現了低層中的註冊、訂閱、調用等功能，讓使用者專注於業務。以下爲dubbo的主要工作：
0 服務容器負責啓動，加載，運行服務提供者。
1. 服務提供者（生產者）在啓動時，向註冊中心註冊自己提供的服務。
2. 服務消費者在啓動時，向註冊中心訂閱自己所需的服務。
3. 註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連接推送變更數據給消費者。
4. 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。
5. 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心
這麼理解的話比較簡單，把zokeeper理解爲數據庫、dubbo理解爲鏈接數據庫的jdbc ，那麼就可以理解他們的關係。
以上是我對dubbo與zokeeper他們關係的理解，如有不正確的希望指正。