dubbo框架基本分析

時間 2019-11-11

標籤 dubbo 框架基本分析欄目 Dubbo 简体版

原文原文鏈接

Dubbo架構基本分析

1. dubbo簡單介紹

1.1 dubbo是什麼

dubbo是一個分佈式服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。其核心部分包含:git

遠程通信: 提供對多種基於長鏈接的NIO框架抽象封裝，包括多種線程模型，序列化，以及「請求-響應」模式的信息交換方式。
集羣容錯: 提供基於接口方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集羣支持。
自動發現: 基於註冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方能夠平滑增長或減小機器。

1.2 dubbo能作什麼

透明化的遠程方法調用，就像調用本地方法同樣調用遠程方法，只需簡單配置，沒有任何API侵入。
軟負載均衡及容錯機制，可在內網替代F5等硬件負載均衡器，下降成本，減小單點。
服務自動註冊與發現，再也不須要寫死服務提供方地址，註冊中心基於接口名查詢服務提供者的IP地址，而且可以平滑添加或刪除服務提供者。

1.3 dubbo的基本使用演示

Dubbo與Zookeeper、SpringMVC整合和使用github

2. dubbo整體框架圖

2.1 整體結構圖

圖例說明：算法

圖中左邊淡藍背景的爲服務消費方使用的接口，右邊淡綠色背景的爲服務提供方使用的接口，位於中軸線上的爲雙方都用到的接口。
圖中從下至上分爲十層，各層均爲單向依賴，右邊的黑色箭頭表明層之間的依賴關係，每一層均可以剝離上層被複用，其中，Service和Config層爲API，其它各層均爲SPI。
圖中綠色小塊的爲擴展接口，藍色小塊爲實現類，圖中只顯示用於關聯各層的實現類。
圖中藍色虛線爲初始化過程，即啓動時組裝鏈，紅色實線爲方法調用過程，即運行時調時鏈，紫色三角箭頭爲繼承，能夠把子類看做父類的同一個節點，線上的文字爲調用的方法。

2.2 基本服務調用圖（借用官網的圖）

節點角色說明：
- Provider: 暴露服務的服務提供方。
- Consumer: 調用遠程服務的服務消費方。
- Registry: 服務註冊與發現的註冊中心。
- Monitor: 統計服務的調用次調和調用時間的監控中心。
- Container: 服務運行容器。
調用關係說明：
- 0、服務容器負責啓動，加載，運行服務提供者。
- 一、服務提供者在啓動時，向註冊中心註冊本身提供的服務。
- 二、服務消費者在啓動時，向註冊中心訂閱本身所需的服務。
- 三、註冊中心返回服務提供者地址列表給消費者，若是有變動，註冊中心將基於長鏈接推送變動數據給消費者。
- 四、服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，若是調用失敗，再選另外一臺調用。
- 五、服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。

3. 具體分析

如今結合官網文檔，咱們來具體分析下dubbo框架的十個層spring

3.1 各層分析

服務接口層(Service)：該層是與實際業務邏輯相關的，根據服務提供方和服務消費方的業務設計對應的接口和實現。
配置層(Config)：對外配置接口，以ServiceConfig, ReferenceConfig爲中心，能夠直接new配置類，也能夠經過spring解析配置生成配置類
服務代理層(Proxy)：服務接口透明代理，生成服務的客戶端Stub和服務器端Skeleton，以ServiceProxy爲中心，擴展接口爲ProxyFactory
服務註冊層(Registry)：封裝服務地址的註冊與發現，以服務URL爲中心，擴展接口爲RegistryFactory、Registry和RegistryService。可能沒有服務註冊中心，此時服務提供方直接暴露服務。
集羣層(Cluster)：封裝多個提供者的路由及負載均衡，並橋接註冊中心，以Invoker爲中心，擴展接口爲Cluster, Directory, Router, LoadBalance
監控層(Monitor)： RPC調用次數和調用時間監控，以Statistics爲中心，擴展接口爲MonitorFactory, Monitor, MonitorService
遠程調用層(Protocol)：封裝RPC調用，以Invocation, Result爲中心，擴展接口爲Protocol, Invoker, Exporter
信息交換層(Exchange)：封裝請求響應模式，同步轉異步，以Request, Response爲中心，擴展接口爲Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer
網絡傳輸層(Transport)：抽象mina和netty爲統一接口，以Message爲中心，擴展接口爲Channel, Transporter, Client, Server, Codec
數據序列化層(Serialize)：可複用的一些工具，擴展接口爲Serialization、 ObjectInput、ObjectOutput和ThreadPool。

3.2 關係說明

在RPC中，Protocol是核心層，也就是隻要有Protocol + Invoker + Exporter就能夠完成非透明的RPC調用，而後在Invoker的主過程上Filter攔截點。
圖中的Consumer和Provider是抽象概念，只是想讓看圖者更直觀的瞭解哪些類分屬於客戶端與服務器端，不用Client和Server的緣由是Dubbo在不少場景下都使用Provider, Consumer, Registry, Monitor劃分邏輯拓普節點，保持統一律念。
而Cluster是外圍概念，因此Cluster的目的是將多個Invoker假裝成一個Invoker，這樣其它人只要關注Protocol層Invoker便可，加上Cluster或者去掉Cluster對其它層都不會形成影響，由於只有一個提供者時，是不須要Cluster的。
Proxy層封裝了全部接口的透明化代理，而在其它層都以Invoker爲中心，只有到了暴露給用戶使用時，才用Proxy將Invoker轉成接口，或將接口實現轉成Invoker，也就是去掉Proxy層RPC是能夠Run的，只是不那麼透明，不那麼看起來像調本地服務同樣調遠程服務。
而Remoting實現是Dubbo協議的實現，若是你選擇RMI協議，整個Remoting都不會用上，Remoting內部再劃爲Transport傳輸層和Exchange信息交換層，Transport層只負責單向消息傳輸，是對Mina,Netty,Grizzly的抽象，它也能夠擴展UDP傳輸，而Exchange層是在傳輸層之上封裝了Request-Response語義。
Registry和Monitor實際上不算一層，而是一個獨立的節點，只是爲了全局概覽，用層的方式畫在一塊兒。

3.3 總結

結合架構圖和分析，咱們能夠了解到，dubbo做爲一個分佈式服務框架，主要具備以下幾個核心的要點：服務器

服務定義：

服務是圍繞服務提供方和服務消費方的，服務提供方實現服務，而服務消費方調用服務。網絡

服務註冊：

針對於服務提供方，它須要發佈服務，並且因爲應用系統的複雜性，服務的數量、類型也不斷膨脹；對於服務消費方，它最關心如何獲取到它所須要的服務，而面對複雜的應用系統，須要管理大量的服務調用。有時對於服務提供方和服務消費方來講，他們還有可能兼具這兩種角色，即須要提供服務，又須要消費服務。架構

經過將服務統一管理起來，能夠有效地優化內部應用對服務發佈/使用的流程和管理。服務註冊中心能夠經過特定協議來完成服務對外的統一。負載均衡

Dubbo提供的註冊中心有以下幾種類型可供選擇：

Multicast註冊中心
Zookeeper註冊中心
Redis註冊中心
Simple註冊中心

服務監控：

不論是服務提供方，仍是服務消費方，他們都須要對服務調用的實際狀態進行有效的監控，從而改進服務質量。框架

信息交換：

遠程通訊須要指定通訊雙方所約定的協議，在保證通訊雙方理解協議語義的基礎上，還要保證高效、穩定的消息傳輸。異步

dubbo繼承了當前主流的網絡通訊框架，主要包括以下幾個：

Mina
Netty
Grizzly

服務調用：

參看  2.2

註冊/註銷服務：

服務的註冊與註銷，是對服務提供方角色而言。如圖：

服務訂閱/取消：

爲了知足應用系統的需求，服務消費方的可能須要從服務註冊中心訂閱指定的有服務提供方發佈的服務，在獲得通知可使用服務時，就能夠直接調用服務。反過來，若是不須要某一個服務了，能夠取消該服務。如圖：

協議支持：

Dubbo協議
Hessian協議
HTTP協議
RMI協議
WebService協議
Thrift協議
Memcached協議
Redis協議

4. 參考連接

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。