一、dubbo是什么？

1）本質：一個Jar包,一個分布式框架,，一個遠程服務調用的分布式框架。

既然是新手教學，肯定很多同學不明白什么是分布式和遠程服務調用，為什么要分布式，為什么要遠程調用。我簡單畫個對比圖說明（圖1看到圖2。畫板畫的，勿噴）。

你想一下，以前什么的都在一個服務器上，調用方法直接就自然而然調用了，沒啥問題。現在因為需求增多拆分了這么多個，部署在不同的服務器上，那是不是相對以前都在一個服務器上，現在分布式后，web層調用service層的服務變成了遠程調用？那怎樣像以前那樣都在一個服務器上自然而然調用方法呢？dubbo來解決。這就是下面dubbo的好處。

二、Dubbo的好處？

1.透明化的遠程方法調用，就像調用本地方法一樣調用遠程方法，只需簡單配置，沒有任何API侵入。

2.軟負載均衡及容錯機制，可在內網替代F5等硬件負載均衡器，降低成本，減少單點。

3. 服務自動注冊與發現，不再需要寫死服務提供方地址，注冊中心基于接口名查詢服務提供者的IP地址，并且能夠平滑添加或刪除服務提供者。（下面講解）

Dubbo采用全Spring配置方式，透明化接入應用，對應用沒有任何API侵入，只需用Spring加載Dubbo的配置即可，Dubbo基于Spring的Schema擴展進行加載。

三、dubbo架構圖如下所示：

講解他的架構圖之前，我們先普及下幾個概念。

節點角色說明：

Provider（生產者）: 暴露服務的服務提供方。

Consumer（消費者）: 調用遠程服務的服務消費方。

如圖，我們可以簡單理解為web1234需要調用service1234的服務，所以web1234是消費者，service1234是生產者。

那如果按照上面，消費者調用生產者的服務，那是不是如下圖：

你看著暈不暈？暈不暈？暈不暈？反正我是暈了，萬一分布式得更多呢？，所以我們需要他：

Registry（注冊中心）: 服務注冊與發現的注冊中心。dubbo推薦的是zookeeper。什么是zookeeper？zookeeper是用于分布式中一致性處理的框架。更多的可以查看我之前的文章：這么說吧,zookeeper 很簡單，其實就是個框架，是一致性處理用的。簡單的講，zookeeper就是個中介，賣樓的（生產者）把樓盤信息放在中介（注冊中心）那里，想買樓的（消費者）去中介那里獲得樓盤資源清單。于是，我們的圖變成了這樣：

是不是好很多了？還不夠， 我們還需要個監控中心（干嘛用的？當然是監控用的，調用失敗怎么辦？掛了怎么辦？）： Monitor: 統計服務的調用次調和調用時間的監控中心。（不畫圖了）

然后，Provider放在容器里運行，就叫做Container服務運行容器。（不畫圖了）

最終dubbo架構，如圖（從0開始看起）：

自己腦海里按照上圖走了一遍后，看看自己想的是不是和下面說明一樣。

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

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

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

3. 注冊中心返回服務提供者地址列表給消費者，如果有變更，注冊中心將基于長連接推送變更數據給消費者。

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

5. 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心