在沒有開始用**來解釋之前
,用圖最能夠表達一些關係,關於
dubbo
的內部邏輯呼叫關係
,借用官方的圖示來說明一下
,如下圖
通過上圖中的乙個個方框我們稱之為節點
,總共有
5個節點
,這五個節點可以看成五個角色
,每個角色都有一定的功能
.每個角色的意思如下:
provider:
暴露服務的服務提供方。
在實際專案中一般稱這個角色為提供者
.它主要是向註冊中心註冊其提供的服務，並匯報呼叫時間到監控中心，此時間不包含網路開銷。
consumer:
呼叫遠端服務的服務消費方。
既然有提供者
,對應的這就是消費者。服務消費者向註冊中心獲取服務提供者位址列表，並根據負載演算法直接呼叫提供者，同時匯報呼叫時間到監控中心，此時間包含網路開銷。
registry:
服務註冊與發現的註冊中心。
註冊中心這個概念將會在接下來多次提到
, 它是乙個比較關鍵的角色
.它的角色是主要負責服務位址的註冊與查詢，相當於目錄服務，服務提供者和消費者只在啟動時與註冊中心互動，註冊中心不**請求，壓力較小
monitor:
統計服務的呼叫次調和呼叫時間的監控中心。
用來監控各個服務提供者和消費者的相關情況
.例如負責統計各服務呼叫次數，呼叫時間等，統計先在記憶體彙總後每分鐘一次傳送到監控中心伺服器，並以報表展示。
container:
服務執行容器。
容器就很好理解了
,dubbo
可以基於
spring
容器來提供和消費.
額外說明
:註冊中心，服務提供者，服務消費者三者之間均為長連線，監控中心除外，註冊中心通過長連線感知服務提供者的存在，服務提供者宕機，註冊中心將立即推送事件通知消費者。
到現在已經知道五個角色都是幹什麼的了
,現在再回到上面的圖
,我們從0到
5將這個五個角色串起來.
0.服務容器負責啟動，載入，執行服務提供者。
1.服務提供者在啟動時，向註冊中心註冊自己提供的服務。
2.服務消費者在啟動時，向註冊中心訂閱自己所需的服務。
3.註冊中心返回服務提供者位址列表給消費者，如果有變更，註冊中心將基於長連線推送變更資料給消費者。
4.服務消費者，從提供者位址列表中，基於軟負載均衡演算法，選一台提供者進行呼叫，如果呼叫失敗，再選另一台呼叫。
5.服務消費者和提供者，在記憶體中累計呼叫次數和呼叫時間，定時每分鐘傳送一次統計資料到監控中心。
以上的流程便是
dubbo
的內部邏輯流程
,這是從比較巨集觀的角度去它的內部邏輯
.這裡提到的註冊中心
,在專案中用到比較多的是
zookeeper.
在下篇文章會對
zookeeper
進行初步的介紹
,原因是在隨後對
dubbo
的相關**示例中用到了它.
Dubbo之旅 擴充套件協議
在實際工作中運用 dubbo 的時候,以上系列的文章基本上能夠滿足專案的基本需求,當然 對於一些特殊的需求 dubbo 可以對其進行擴充套件 dubbo 擁有者豐富的擴充套件內容 這次主要將會帶領大家去感受一下 dubbo 的協議擴充套件和註冊中心擴充套件 首先要說的是協議擴充套件.為什麼要擴充套件...
Dubbo之旅 問題彙總
在工作和學習的過程中 具體運用 dubbo 的時候遇到了很多的問題 這些問題一方面讓自己進一步了解所謂的 dubbo,另一方面通過對它們的總結和分析能夠在工作中加倍的提高效率 接下來將會對遇到的和別人總結的一些常見的問題進行彙總.1.增加提供服務版本號和消費服務版本號.這個具體來說不算是乙個問題 而...
Dubbo之旅 擴充套件註冊中心
在上篇文章中我們介紹了關於協議的擴充套件 並了解擴充套件它所需要的需求 本篇主要是對註冊中心的擴充套件進行著重的探索.同樣的問題 為什麼我們需要去擴充套件註冊中心的 主要有以下三個需求.1 多註冊中心註冊 需求 xx 銀行有些服務來不及在上海部署，只在北京部署，而上海的其它應用需要引用此服務，就可以...