網際網路的發展，網站應用的規模不斷擴大，常規的垂直應用架構已無法應對，分散式服務架構以及流動計算架構勢在必行，Dubbo是一個分散式服務框架，在這種情況下誕生的。現在核心業務抽取出來，作為獨立的服務，使前端應用能更快速和穩定的響應。

Zookeeper的作用

zookeeper用來註冊服務和進行負載均衡，哪一個服務由哪一個機器來提供必需讓呼叫者知道，簡單來說就是ip地址和服務名稱的對應關係。當然也可以通過硬編碼的方式把這種對應關係在呼叫方業務程式碼中實現，但是如果提供服務的機器掛掉呼叫者無法知曉，如果不更改程式碼會繼續請求掛掉的機器提供服務。zookeeper通過心跳機制可以檢測掛掉的機器並將掛掉機器的ip和服務對應關係從列表中刪除。至於支援高併發，簡單來說就是橫向擴充套件，在不更改程式碼的情況通過新增機器來提高運算能力。通過新增新的機器向zookeeper註冊服務，服務的提供者多了能服務的客戶就多了。

dubbo的作用

是管理中間層的工具，在業務層到資料倉庫間有非常多服務的接入和服務提供者需要排程，dubbo提供一個框架解決這個問題。
注意這裡的dubbo只是一個框架，至於你架子上放什麼是完全取決於你的，就像一個汽車骨架，你需要配你的輪子引擎。這個框架中要完成排程必須要有一個分散式的註冊中心，儲存所有服務的元資料，你可以用zk，也可以用別的，只是大家都用zk。

zookeeper和dubbo的關係

Dubbo的將註冊中心進行抽象，是得它可以外接不同的儲存媒介給註冊中心提供服務，有ZooKeeper，Memcached，Redis等。
引入了ZooKeeper作為儲存媒介，也就把ZooKeeper的特性引進來。首先是負載均衡，單註冊中心的承載能力是有限的，在流量達到一定程度的時候就需要分流，負載均衡就是為了分流而存在的，一個ZooKeeper群配合相應的Web應用就可以很容易達到負載均衡；資源同步，單單有負載均衡還不夠，節點之間的資料和資源需要同步，ZooKeeper叢集就天然具備有這樣的功能；命名服務，將樹狀結構用於維護全域性的服務地址列表，服務提供者在啟動的時候，向ZK上的指定節點
/dubbo/${serviceName}/providers
目錄下寫入自己的URL地址，這個操作就完成了服務的釋出。其他特性還有Mast選舉，分散式鎖等。

Zookeeper的特性

資料釋出與訂閱（配置中心）：
釋出與訂閱模型，即所謂的配置中心，顧名思義就是釋出者將資料釋出到ZK節點上，供訂閱者動態獲取資料，實現配置資訊的集中式管理和動態更新。例如全域性的配置資訊，服務式服務框架的服務地址列表等就非常適合使用。

負載均衡：
這裡說的負載均衡是指軟負載均衡。在分散式環境中，為了保證高可用性，通常同一個應用或同一個服務的提供方都會部署多份，達到對等服務。而消費者就須要在這些對等的伺服器中選擇一個來執行相關的業務邏輯，其中比較典型的是訊息中介軟體中的生產者，消費者負載均衡。

命名服務(Naming Service)：
命名服務也是分散式系統中比較常見的一類場景。在分散式系統中，通過使用命名服務，客戶端應用能夠根據指定名字來獲取資源或服務的地址，提供者等資訊。被命名的實體通常可以是叢集中的機器，提供的服務地址，遠端物件等等——這些我們都可以統稱他們為名字（Name）。其中較為常見的就是一些分散式服務框架中的服務地址列表。通過呼叫ZK提供的建立節點的API，能夠很容易建立一個全域性唯一的path，這個path就可以作為一個名稱。

分散式通知/協調：
ZooKeeper中特有watcher註冊與非同步通知機制，能夠很好的實現分散式環境下不同系統之間的通知與協調，實現對資料變更的實時處理。使用方法通常是不同系統都對ZK上同一個znode進行註冊，監聽znode的變化（包括znode本身內容及子節點的），其中一個系統update了znode，那麼另一個系統能夠收到通知，並作出相應處理。