Dubbo入門(3)-架構原理

做者：不洗碗工做室 - Marklux

出處：Dubbo入門(3)-架構原理

版權歸做者全部，轉載請註明出處

前言

在以前的兩篇文章中，咱們瞭解了有關分佈式服務的基本概念和簡單的使用。如今來了解一下dubbo是如何提供這些功能的、如何運做的，以及整個框架的層次結構。

本文參考自Dubbo架構設計詳解及Dubbo官方用戶手冊

核心功能

首先要了解Dubbo提供的三大核心功能：

1. 通訊

   提供多種對NIO框架的抽象方式，給不一樣服務間的互相通訊及調用提供多種方式。包括同步、異步、請求與響應等模型。

2. 服務治理

   維護服務之間的調用關係，而且提供服務容錯、負載均衡、動態配置等功能。使得開發者可以實時瞭解服務總體的運行狀況。

3. 註冊中心

   提供服務註冊中心，使得服務可以動態的添加、刪除並實時更新落地到消費方。

節點架構

參考dubbo官方手冊提供的這個節點架構圖：

解釋一下各個節點所扮演的角色：

• Provider

  暴露服務的提供方

• Consumer

  調用遠程服務的消費方

• Container

  服務運行容器

• Registry

  服務註冊中心，用於服務發現

• Monitor

  統計服務調用狀況的監控中心

接着須要瞭解總體的調用關係和流程：

1. 服務容器負責啓動、加載和運行服務提供者（能夠理解爲：服務提供者爲開發者編寫的業務代碼，而服務容器提供一個運行環境，使得開發者能夠不用關心啓動和鏈接的相關細節）

2. 服務提供者在啓動時，向註冊中心註冊本身的服務。而服務的消費者在啓動時，在註冊中心中訂閱本身所需的服務。

3. 註冊中心返回服務提供者地址列表給消費者，若是有變動，註冊中心將基於長鏈接推送變動數據給消費者。

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

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

優點特性

上述的節點架構，給dubbo帶來了幾個很是強大的特性，也是dubbo的優點所在：

連通性

全部的節點之間都是連通的，而且經過優化下降網絡調用的消耗。

體現爲：

• 註冊中心負責服務地址的註冊與查找，至關於目錄服務，服務提供者和消費者只在啓動時與註冊中心交互，註冊中心不轉發請求，壓力較小
• 監控中心負責統計各服務調用次數，調用時間等，統計先在內存彙總後每分鐘一次發送到監控中心服務器，並以報表展現
• 服務提供者向註冊中心註冊其提供的服務，並彙報調用時間到監控中心，此時間不包含網絡開銷
• 服務消費者向註冊中心獲取服務提供者地址列表，並根據負載算法直接調用提供者，同時彙報調用時間到監控中心，此時間包含網絡開銷
• 註冊中心，服務提供者，服務消費者三者之間均爲長鏈接，監控中心除外
• 註冊中心經過長鏈接感知服務提供者的存在，服務提供者宕機，註冊中心將當即推送事件通知消費者
• 註冊中心和監控中心所有宕機，不影響已運行的提供者和消費者，消費者在本地緩存了提供者列表
• 註冊中心和監控中心都是可選的，服務消費者能夠直連服務提供者

健壯性

即使服務中的某些節點沒法正常工做，系統總體不會崩潰，而是經過多種容錯策略儘量下降損失。

體現爲：

• 監控中心宕掉不影響使用，只是丟失部分採樣數據
• 數據庫宕掉後，註冊中心仍能經過緩存提供服務列表查詢，但不能註冊新服務
• 註冊中心對等集羣，任意一臺宕掉後，將自動切換到另外一臺
• 註冊中心所有宕掉後，服務提供者和服務消費者仍能經過本地緩存通信
• 服務提供者無狀態，任意一臺宕掉後，不影響使用
• 服務提供者所有宕掉後，服務消費者應用將沒法使用，並沒有限次重連等待服務提供者恢復

伸縮性

當服務的規模須要調整時，沒必要暫停服務從新部署，而是能夠動態切換，體現爲：

• 註冊中心爲對等集羣，可動態增長機器部署實例，全部客戶端將自動發現新的註冊中心
• 服務提供者無狀態，可動態增長機器部署實例，註冊中心將推送新的服務提供者信息給消費者

升級性

當服務集羣進一步增大，可能須要過渡到流動計算架構。但dubbo自己的服務結構不會爲升級提供阻力。

水平分層結構

上面從節點劃分的角度出發瞭解了dubbo的基本組件及其之間的關係，如今作一下水平分層，來看一下整個框架的全部組成，參考下圖：

Dubbo框架設計一共劃分了10個層，而最上面的Service層是留給實際想要使用Dubbo開發分佈式服務的開發者實現業務邏輯的接口層。圖中左邊淡藍背景的爲服務消費方使用的接口，右邊淡綠色背景的爲服務提供方使用的接口， 位於中軸線上的爲雙方都用到的接口。

下面簡要說明一下各層的做用（因爲我還沒讀過源碼，因此只是參考文檔得出的我的理解）

1. 服務接口層(Service)

   業務邏輯實現的地方，也是使用框架的開發者真正編寫代碼的地方

2. 配置層(Config)

   配置總體運行參數的地方。

3. 服務代理層(Proxy)

   接口調用透明化代理，將Invoker轉化成用戶直接調用的接口。沒有這層依然能夠實現RPC，可是須要用戶手動組建Invoker，不能實現透明化調用。

4. 服務註冊層(Registry)

   封裝服務地址的註冊和發現功能，若是沒有服務註冊層，則須要服務提供者本身直接暴露服務調用地址。

5. 集羣層(Cluster)

   封裝多個提供者的路由並提供負載均衡，橋接註冊中心。實現多個服務提供方整合爲一個服務提供方的映射。

6. 監控層(Monitor)

   檢測RPC的調用次數和調用狀況。

7. 遠程調用層(Protocol)

   核心層，封裝RPC調用。Protocol負責管理Invoker的生命週期。而Invoker是Dubbo的核心模型，表明一個 可執行體 ，全部的調用都基於Invoker，不管是本地或是遠程調用，仍是集羣調用。

8. 信息交換層(Exchange)

   封裝各類通訊模式：請求-響應、同步轉異步等。

9. 網絡傳輸層(Transport)

   抽象mina和netty爲統一接口，提供基礎nio的能力。

10. 數據序列化層(Serialize)

    提供一些基本的可複用的工具。

調用流程分析

基於下圖分析在RPC層服務消費者與服務提供者之間的調度關係。

如咱們以前總結的，主要分爲3步：

1. 服務提供方發佈服務到服務註冊中心
2. 服務消費方從註冊中心訂閱服務
3. 服務調用方調用已訂閱的服務

將細節展開，參考下圖：

小結

dubbo自己的結構其實並不複雜，並且分層清晰。

瞭解dubbo的架構，有助於理解分佈式系統的設計思路，而且更容易上手。

後續也會從源碼角度分析dubbo系統的實現。

前言

在以前的兩篇文章中，咱們瞭解了有關分佈式服務的基本概念和簡單的使用。如今來了解一下dubbo是如何提供這些功能的、如何運做的，以及整個框架的層次結構。

本文參考自Dubbo架構設計詳解及Dubbo官方用戶手冊

核心功能

首先要了解Dubbo提供的三大核心功能：

1. 通訊

   提供多種對NIO框架的抽象方式，給不一樣服務間的互相通訊及調用提供多種方式。包括同步、異步、請求與響應等模型。

2. 服務治理

   維護服務之間的調用關係，而且提供服務容錯、負載均衡、動態配置等功能。使得開發者可以實時瞭解服務總體的運行狀況。

3. 註冊中心

   提供服務註冊中心，使得服務可以動態的添加、刪除並實時更新落地到消費方。

節點架構

參考dubbo官方手冊提供的這個節點架構圖：

解釋一下各個節點所扮演的角色：

• Provider

  暴露服務的提供方

• Consumer

  調用遠程服務的消費方

• Container

  服務運行容器

• Registry

  服務註冊中心，用於服務發現

• Monitor

  統計服務調用狀況的監控中心

接着須要瞭解總體的調用關係和流程：

1. 服務容器負責啓動、加載和運行服務提供者（能夠理解爲：服務提供者爲開發者編寫的業務代碼，而服務容器提供一個運行環境，使得開發者能夠不用關心啓動和鏈接的相關細節）

2. 服務提供者在啓動時，向註冊中心註冊本身的服務。而服務的消費者在啓動時，在註冊中心中訂閱本身所需的服務。

3. 註冊中心返回服務提供者地址列表給消費者，若是有變動，註冊中心將基於長鏈接推送變動數據給消費者。

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

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

優點特性

上述的節點架構，給dubbo帶來了幾個很是強大的特性，也是dubbo的優點所在：

連通性

全部的節點之間都是連通的，而且經過優化下降網絡調用的消耗。

體現爲：

• 註冊中心負責服務地址的註冊與查找，至關於目錄服務，服務提供者和消費者只在啓動時與註冊中心交互，註冊中心不轉發請求，壓力較小
• 監控中心負責統計各服務調用次數，調用時間等，統計先在內存彙總後每分鐘一次發送到監控中心服務器，並以報表展現
• 服務提供者向註冊中心註冊其提供的服務，並彙報調用時間到監控中心，此時間不包含網絡開銷
• 服務消費者向註冊中心獲取服務提供者地址列表，並根據負載算法直接調用提供者，同時彙報調用時間到監控中心，此時間包含網絡開銷
• 註冊中心，服務提供者，服務消費者三者之間均爲長鏈接，監控中心除外
• 註冊中心經過長鏈接感知服務提供者的存在，服務提供者宕機，註冊中心將當即推送事件通知消費者
• 註冊中心和監控中心所有宕機，不影響已運行的提供者和消費者，消費者在本地緩存了提供者列表
• 註冊中心和監控中心都是可選的，服務消費者能夠直連服務提供者

健壯性

即使服務中的某些節點沒法正常工做，系統總體不會崩潰，而是經過多種容錯策略儘量下降損失。

體現爲：

• 監控中心宕掉不影響使用，只是丟失部分採樣數據
• 數據庫宕掉後，註冊中心仍能經過緩存提供服務列表查詢，但不能註冊新服務
• 註冊中心對等集羣，任意一臺宕掉後，將自動切換到另外一臺
• 註冊中心所有宕掉後，服務提供者和服務消費者仍能經過本地緩存通信
• 服務提供者無狀態，任意一臺宕掉後，不影響使用
• 服務提供者所有宕掉後，服務消費者應用將沒法使用，並沒有限次重連等待服務提供者恢復

伸縮性

當服務的規模須要調整時，沒必要暫停服務從新部署，而是能夠動態切換，體現爲：

• 註冊中心爲對等集羣，可動態增長機器部署實例，全部客戶端將自動發現新的註冊中心
• 服務提供者無狀態，可動態增長機器部署實例，註冊中心將推送新的服務提供者信息給消費者

升級性

當服務集羣進一步增大，可能須要過渡到流動計算架構。但dubbo自己的服務結構不會爲升級提供阻力。

水平分層結構

上面從節點劃分的角度出發瞭解了dubbo的基本組件及其之間的關係，如今作一下水平分層，來看一下整個框架的全部組成，參考下圖：

Dubbo框架設計一共劃分了10個層，而最上面的Service層是留給實際想要使用Dubbo開發分佈式服務的開發者實現業務邏輯的接口層。圖中左邊淡藍背景的爲服務消費方使用的接口，右邊淡綠色背景的爲服務提供方使用的接口， 位於中軸線上的爲雙方都用到的接口。

下面簡要說明一下各層的做用（因爲我還沒讀過源碼，因此只是參考文檔得出的我的理解）

1. 服務接口層(Service)

   業務邏輯實現的地方，也是使用框架的開發者真正編寫代碼的地方

2. 配置層(Config)

   配置總體運行參數的地方。

3. 服務代理層(Proxy)

   接口調用透明化代理，將Invoker轉化成用戶直接調用的接口。沒有這層依然能夠實現RPC，可是須要用戶手動組建Invoker，不能實現透明化調用。

4. 服務註冊層(Registry)

   封裝服務地址的註冊和發現功能，若是沒有服務註冊層，則須要服務提供者本身直接暴露服務調用地址。

5. 集羣層(Cluster)

   封裝多個提供者的路由並提供負載均衡，橋接註冊中心。實現多個服務提供方整合爲一個服務提供方的映射。

6. 監控層(Monitor)

   檢測RPC的調用次數和調用狀況。

7. 遠程調用層(Protocol)

   核心層，封裝RPC調用。Protocol負責管理Invoker的生命週期。而Invoker是Dubbo的核心模型，表明一個 可執行體 ，全部的調用都基於Invoker，不管是本地或是遠程調用，仍是集羣調用。

8. 信息交換層(Exchange)

   封裝各類通訊模式：請求-響應、同步轉異步等。

9. 網絡傳輸層(Transport)

   抽象mina和netty爲統一接口，提供基礎nio的能力。

10. 數據序列化層(Serialize)

    提供一些基本的可複用的工具。

調用流程分析

基於下圖分析在RPC層服務消費者與服務提供者之間的調度關係。

如咱們以前總結的，主要分爲3步：

1. 服務提供方發佈服務到服務註冊中心
2. 服務消費方從註冊中心訂閱服務
3. 服務調用方調用已訂閱的服務

將細節展開，參考下圖：

小結

dubbo自己的結構其實並不複雜，並且分層清晰。

瞭解dubbo的架構，有助於理解分佈式系統的設計思路，而且更容易上手。

後續也會從源碼角度分析dubbo系統的實現。