學習dubbo和那必須先要了解Dubbo和Zookeeper關係
您可以把dubbo服務想象成學校裏的一個學生，並且對應有一個學號，zookeeper則是想象成一個教務網管理系統。我們可以通過教務網管理系統，查找到對應的學生。我們首先通過註冊入學，將學生和學號對應綁定。
比方說項目是一個分佈式的項目，web層與 service層被拆分了開來， 部署在不同的tomcat中， 我在web層 需要調用 service層的接口，但是兩個運行在不同tomcat下的服務無法直接互調接口，那麼就可以通過zookeeper和dubbo實現。
我們通過dubbo 建立ItemService這個服務，並且到zookeeper上面註冊，填寫對應的zookeeper服務所在 的IP及端口號。【按照我上面的比喻就是，學生註冊入學（接口是學號，學生本人是impl實現），填寫學校教務網網址（就是zookeeper）】
下面我們的 web層需要來調用 service接口了，由於在不同的工程中，它是無法直接找到service接口的，我們使用dubbo再來引用註冊進入的dubbo服務。
我們先填寫zookeeper服務所在的IP及端口號，再填寫我們需要調用的接口名字。
【按照我上面的比喻，就是填寫學校的教務網網址，我們在教務網中，通過學號（接口名），查詢到對應的學生】
這樣就能實現簡單調用.
zookeeper實現的是資源的訂閱發佈基本原理就是，分佈式的環境下服務方實際上是資源，每個服務方把自己的服務的節點信息，註冊在zk上，消費者通過zk獲取到所需要的服務的相關信息，比如url之類。
但是zk有個很重要的功能，會主動通知消費者所訂閱資源的變化信息，比如，同一個服務某臺機器相關進程關閉後，zk會通知消費者，資源的變化情況，這樣，就實現了服務的動態添加減少。
這一點在分佈式環境下非常重要，設想如下場景
某網站在做搶購活動，突然發現，後臺某個服務資源吃緊，需要增加服務器，而又不能影響當前業務，
簡單來說他的功能類似於註冊中心。
dubbo的服務提供者會在zookeeper上面創建一個臨時節點，表明自己的IP和端口，當消費者需要使用服務時，會先在zookeeper上面查詢，找到服務提供者，做一些負載的選擇（比如隨機、輪流），然後按照這些信息，訪問服務提供者。
zookeeper負責保存了服務提供方和服務消費方的的URI（dubbo自定義的一種URI），服務消費方找到zookeeper，向zookeeper要到服務提供方的URI，然後就找到提供方，並調用提供方的服務。解耦，分佈式，failover。
dubbo是管理中間層的工具，在業務層到數據倉庫間有非常多服務的接入和服務提供者需要調度，dubbo提供一個框架解決這個問題。
注意這裏的dubbo只是一個框架，至於你架子上放什麼是完全取決於你的，就像一個汽車骨架，你需要配你的輪子引擎。這個框架中要完成調度必須要有一個分佈式的註冊中心，儲存所有服務的元數據，你可以用zk，也可以用別的，只是大家都用zk。
zookeeper用來註冊服務和進行負載均衡，哪一個服務由哪一個機器來提供必需讓調用者知道，簡單來說就是IP地址和服務名稱的對應關係。當然也可以通過硬編碼的方式把這種對應關係在調用方業務代碼中實現，但是如果提供服務的機器掛掉調用者無法知曉，如果不更改代碼會繼續請求掛掉的機器提供服務。zookeeper通過心跳機制可以檢測掛掉的機器並將掛掉機器的IP和服務對應關係從列表中刪除。至於支持高併發，簡單來說就是橫向擴展，在不更改代碼的情況通過添加機器來提高運算能力。通過添加新的機器向zookeeper註冊服務，服務的提供者多了能服務的客戶就多了。
結構大致分爲三層：1.facade層（僞註冊中心層）、2.services層、3.web層。
1.facade層，主要是在zookeeper註冊中心中需要註冊的服務和暴露的接口、dto、entity
2.services層，主要是實現接口的具體業務邏輯，我們稱之爲biz，和與數據庫進行交互操作的dao
3.web層，主要是jsp頁面和controller，以及一些css樣式和js文件
項目的大體流程是這樣的，在facade層中註冊（寫好）需要暴露的接口，這些接口在services層中具體實現業務邏輯，web層中jsp頁面請求controller中的方法，controller調用facade中的接口，這裏可以理解爲web層發出請求後去註冊中心裏查詢這個服務接口是否已經註冊並且有相應的服務提供者，如果有，註冊中心會將實現該服務的service的url返回給web層，這樣wb層去訪問註冊中心返回來的url地址，也就是services層中具體的實現方法，services將操作後的結果返回給web層，這樣下來一套流程算是走完。其中，dto用在網絡數據傳輸層中，這並不是實體，只是根據controller需要的字段有選擇的創建的類，而entity不出現在網絡數據傳輸層中，它只在dao層中與數據庫交互，在前臺請求中的參數由dto或者基本類型來承載，所以傳遞到services層中的參數並不是實體，所以，一般在這裏將dto中的數據copy到實體中，再由實體與數據庫進行操作。這樣實體的屬性和結構並不會暴露出去，保證了項目的安全行，而且用dubbo和zookeepe搭建的分佈式項目（並不是說dubbo和zookeeper這倆很強，springcloud也是分佈式的框架，只是將分佈式的項目和單點項目做一個比較），安全性要比一般的單點項目要高，因爲分佈式的項目暴露在外網的只是web層中頁面的訪問地址，對於後面的返回的service的url和具體的操作是在內網環境中配置的，沒有直接的物理操作，安全性是極高的。而且，分佈式項目可有很多個services層和web層，也是可以解決高併發和產品版本衝突。上傳的內容的挺亂的，如果配着前面寫的解釋看應該可以看明白一點。
轉載鏈接：https://www.zhihu.com/question/25070185/answer/227169884
轉載鏈接：http://blog.csdn.net/shiyus1314/article/details/77500780