dubbo本質：一個Jar套件,一個分散式框架,，一個遠端服務呼叫的分散式框架。
1）既然是新手教學，肯定很多同學不明白什麼是分散式和遠端服務調用，為什麼要分散式，為什麼要遠端調用。我簡單畫個對比圖說明（圖1看到圖2。畫板畫的，勿噴）。
你想一下，以前什麼的都在一個伺服器上，呼叫方法直接就自然而然地呼叫了，沒啥問題。現在因為需求增多拆分了這麼多，部署在不同的伺服器上，那是不是相對以前都在一個伺服器上，現在分散式後，web層呼叫service層的服務變成了遠端呼叫？那怎麼像以前一樣都在一個伺服器上自然而然地呼叫方法呢？ dubbo來解決。這就是下面dubbo的好處。
1.透明化的遠端方法調用，就像調用本地方法一樣調用遠端方法，只需簡單配置，沒有任何API侵入。
2.軟負載平衡及容錯機制，可在內網取代F5等硬體負載平衡器，降低成本，減少單點。
3. 服務自動註冊與發現，不再需要寫死服務提供者位址，註冊中心基於介面名稱查詢服務提供者的IP位址，並且能夠平滑新增或刪除服務提供者。 （下面講解）
Dubbo採用全Spring配置方式，透明化接入應用，對應用沒有任何API侵入，只需用Spring加載Dubbo的配置即可，Dubbo基於Spring的Schema擴展進行加載。
在講解他的架構圖之前，我們先普及下幾個概念。
節點角色說明：
Provider（生產者）: 暴露服務的服務提供者。
Consumer（消費者）: 呼叫遠端服務的服務消費方。
如圖，我們可以簡單理解為web1234需要呼叫service1234的服務，所以web1234是消費者，service1234是生產者。
那如果按照上面，消費者呼叫生產者的服務，那是不是如下圖：
你看暈不暈？暈不暈？暈不暈？反正我是暈了，萬一分散式得更多呢？ ，所以我們需要他：
Registry（註冊中心）: 服務註冊與發現的註冊中心。 dubbo推薦的是zookeeper。什麼是zookeeper？ zookeeper是用於分散式中一致性處理的框架。更多的可以查看我之前的文章：這麼說吧,zookeeper 很簡單，其實就是個框架，是一致性處理用的。簡單的講，zookeeper就是個中介，賣樓的（生產者）把樓盤資訊放在中介（註冊中心）那裡，想買樓的（消費者）去中介那裡取得樓盤資源清單。於是，我們的圖變成了這樣：
是不是好很多了？還不夠， 我們還需要個監控中心（幹嘛用的？當然是監控用的，呼叫失敗怎麼辦？掛了怎麼辦？）： Monitor: 統計服務的呼叫次調和呼叫時間的監控中心。 （不畫圖了）
然後，Provider放在容器裡運行，就叫做Container服務運行容器。 （不畫圖了）
最終dubbo架構，如圖（從0開始看起）：
相關推薦：
以上是Dubbo+zokeeper基礎講解的詳細內容。更多資訊請關注PHP中文網其他相關文章！
