首先給dubbo一個定義

dubbo是一個遠端服務呼叫的分散式框架。

我們通常把專案部署在一個伺服器上，但是如果專案增加需求需要拆分多個並且部署在多個伺服器上（如下圖），web層呼叫service層的服務變成了遠端呼叫，那這個時候我們就用到了dubbo.

1.透明化的遠端方法呼叫，就像呼叫本地方法一樣呼叫遠端方法，只需簡單配置就可以

2.軟負載均衡及容錯機制

3.服務自動註冊與發現，不再需要寫死服務提供方地址，註冊中心基於介面名查詢服務提供者的IP地址，並且能夠平滑新增或刪除服務提供者

Dubbo採用全Spring配置方式，透明化接入應用，只需用Spring載入Dubbo的配置即可

dubbo裡面有兩個角色節點一個是服務提供者，一個是服務消費者

我們可以想到肯定是服務消費者去呼叫服務提供者，但是如果我們有多個服務提供者和多個服務消費者，

那這樣呼叫的話不知道你們暈不暈，反正我是暈了，所以這個時候我們就用到了Registry（註冊中心）: 服務註冊與發現的註冊中心。dubbo推薦的是zookeeper。

那我們在說下zookeeper,zookeeper是用於分散式中一致性處理的框架,說白了zookeeper就相當箇中介，賣樓的（生產者）把樓盤資訊放在中介（註冊中心）那裡，想買樓的（消費者）去中介那裡獲得樓盤資訊

我們還需要個監控中心（用來監控呼叫失敗怎麼辦？掛了怎麼辦？）

Monitor: 統計服務的呼叫次調和呼叫時間的監控中心

Provider（服務提供者）放在容器裡執行，就叫做Container服務執行容器

下面是流程：

自己跟著走一遍，看看自己想的是不是和下面說明一樣。

0 服務容器負責啟動，載入，執行服務提供者。

1. 服務提供者（生產者）在啟動時，向註冊中心註冊自己提供的服務。

2. 服務消費者在啟動時，向註冊中心訂閱自己所需的服務。

3. 註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連線推送變更資料給消費者。

4. 服務消費者，從提供者地址列表中，基於軟負載均衡演算法，選一臺提供者進行呼叫，如果呼叫失敗，再選另一臺呼叫。

5. 服務消費者和提供者，在記憶體中累計呼叫次數和呼叫時間，定時每分鐘傳送一次統計資料到監控中心

以上是我對dubbo和zookeeper的簡單理解 上面的圖是我在別的技術部落格裡面盜的，哈哈 勿噴