基本概念
Dubbo是一個分佈式服務框架，採用全 Spring 配置方式，透明化接入應用，對應用沒有任何 API 侵入，只需用 Spring 加載 Dubbo 的配置即可，Dubbo 基於 Spring 的 Schema 擴展 進行加載。
如果不想使用 Spring 配置，可以通過 API 的方式 進行調用。
ZooKeeper是一個分佈式的，開放源碼的分佈式應用程序協調服務，是Google的Chubby一個開源的實現，是Hadoop和Hbase的重要組件。它是一個爲分佈式應用提供一致性服務的軟件，提供的功能包括:配置維護、域名服務、分佈式同步、組服務等。
ZooKeeper的目標就是封裝好複雜易出錯的關鍵服務，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。
Dubbo架構
節點角色說明：
Provider: 暴露服務的服務提供方。
Consumer: 調用遠程服務的服務消費方。
Registry: 服務註冊與發現的註冊中心。
Monitor: 統計服務的調用次調和調用時間的監控中心。
Container: 服務運行容器。
調用關係說明：
0. 服務容器負責啓動，加載，運行服務提供者。
1. 服務提供者在啓動時，向註冊中心註冊自己提供的服務。
2. 服務消費者在啓動時，向註冊中心訂閱自己所需的服務。
3. 註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連接推送變更數據給消費者。
4. 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。
5. 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。
服務配置
服務提供方/生產者
服務消費方/消費者
Zookeeper+Dubbo
Zookeeper作爲Dubbo服務的註冊中心，Dubbo原先基於數據庫的註冊中心，沒采用Zookeeper，Zookeeper一個分佈式的服務框架，是樹型的目錄服務的數據存儲，能做到集羣管理數據 ，這裏能很好的作爲Dubbo服務的註冊中心，Dubbo能與Zookeeper做到集羣部署，當提供者出現斷電等異常停機時，Zookeeper註冊中心能自動刪除提供者信息，當提供者重啓時，能自動恢復註冊數據，以及訂閱請求
Dubbo建議使用Zookeeper作爲服務的註冊中心。
1. Zookeeper的作用：
zookeeper用來註冊服務和進行負載均衡，哪一個服務由哪一個機器來提供必需讓調用者知道，簡單來說就是ip地址和服務名稱的對應關係。當然也可以通過硬編碼的方式把這種對應關係在調用方業務代碼中實現，但是如果提供服務的機器掛掉調用者無法知曉，如果不更改代碼會繼續請求掛掉的機器提供服務。zookeeper通過心跳機制可以檢測掛掉的機器並將掛掉機器的ip和服務對應關係從列表中刪除。至於支持高併發，簡單來說就是橫向擴展，在不更改代碼的情況通過添加機器來提高運算能力。通過添加新的機器向zookeeper註冊服務，服務的提供者多了能服務的客戶就多了。
2. dubbo：
是管理中間層的工具，在業務層到數據倉庫間有非常多服務的接入和服務提供者需要調度，dubbo提供一個框架解決這個問題。
注意這裏的dubbo只是一個框架，至於你架子上放什麼是完全取決於你的，就像一個汽車骨架，你需要配你的輪子引擎。這個框架中要完成調度必須要有一個分佈式的註冊中心，儲存所有服務的元數據，你可以用zk，也可以用別的，只是大家都用zk。
3. zookeeper和dubbo的關係：
Dubbo的將註冊中心進行抽象，是得它可以外接不同的存儲媒介給註冊中心提供服務，有ZooKeeper，Memcached，Redis等。
引入了ZooKeeper作爲存儲媒介，也就把ZooKeeper的特性引進來。首先是負載均衡，單註冊中心的承載能力是有限的，在流量達到一定程度的時候就需要分流，負載均衡就是爲了分流而存在的，一個ZooKeeper羣配合相應的Web應用就可以很容易達到負載均衡；資源同步，單單有負載均衡還不夠，節點之間的數據和資源需要同步，ZooKeeper集羣就天然具備有這樣的功能；命名服務，將樹狀結構用於維護全局的服務地址列表，服務提供者在啓動的時候，向ZK上的指定節點/dubbo/${serviceName}/providers目錄下寫入自己的URL地址，這個操作就完成了服務的發佈。其他特性還有Mast選舉，分佈式鎖等。
相關說明摘自：https://blog.csdn.net/zhailihua/article/details/78460194