Dubbo是Alibaba開源的分佈式服務框架,它最大的特色是按照分層的方式來架構,使用這種方式可使各個層之間解耦合(或者最大限度地鬆耦合)。從服務模型的角度來看,Dubbo採用的是一種很是簡單的模型,要麼是提供方提供服務,要麼是消費方消費服務,因此基於這一點能夠抽象出服務提供方(Provider)和服務消費方(Consumer)兩個角色。關於註冊中心、協議支持、服務監控等內容,詳見後面描述。spring
Dubbo的整體架構,如圖所示性能優化
Dubbo框架設計一共劃分了10個層,而最上面的Service層是留給實際想要使用Dubbo開發分佈式服務的開發者實現業務邏輯的接口層。圖中左邊淡藍背景的爲服務消費方使用的接口,右邊淡綠色背景的爲服務提供方使用的接口, 位於中軸線上的爲雙方都用到的接口。服務器
下面,結合Dubbo官方文檔,咱們分別理解一下框架分層架構中,各個層次的設計要點:微信
從上圖能夠看出,Dubbo對於服務提供方和服務消費方,從框架的10層中分別提供了各自須要關心和擴展的接口,構建整個服務生態系統(服務提供方和服務消費方自己就是一個以服務爲中心的)。網絡
根據官方提供的,對於上述各層之間關係的描述,以下所示:架構
在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實際上不算一層,而是一個獨立的節點,只是爲了全局概覽,用層的方式畫在一塊兒。
從上面的架構圖中,咱們能夠了解到,Dubbo做爲一個分佈式服務框架,主要具備以下幾個核心的要點:
服務定義
服務是圍繞服務提供方和服務消費方的,服務提供方實現服務,而服務消費方調用服務。
服務註冊
對於服務提供方,它須要發佈服務,並且因爲應用系統的複雜性,服務的數量、類型也不斷膨脹;對於服務消費方,它最關心如何獲取到它所須要的服務,而面對複雜的應用系統,須要管理大量的服務調用。並且,對於服務提供方和服務消費方來講,他們還有可能兼具這兩種角色,即既須要提供服務,有須要消費服務。
經過將服務統一管理起來,能夠有效地優化內部應用對服務發佈/使用的流程和管理。服務註冊中心能夠經過特定協議來完成服務對外的統一。Dubbo提供的註冊中心有以下幾種類型可供選擇:
服務監控
不管是服務提供方,仍是服務消費方,他們都須要對服務調用的實際狀態進行有效的監控,從而改進服務質量。
遠程通訊與信息交換
遠程通訊須要指定通訊雙方所約定的協議,在保證通訊雙方理解協議語義的基礎上,還要保證高效、穩定的消息傳輸。Dubbo繼承了當前主流的網絡通訊框架,主要包括以下幾個:
服務調用
下面從Dubbo官網直接拿來,看一下基於RPC層,服務提供方和服務消費方之間的調用關係,如圖所示:
上圖中,藍色的表示與業務有交互,綠色的表示只對Dubbo內部交互。上述圖所描述的調用流程以下:
接着,將上面抽象的調用流程圖展開,詳細如圖所示:
註冊/註銷服務
服務的註冊與註銷,是對服務提供方角色而言,那麼註冊服務與註銷服務的時序圖,如圖所示:
服務訂閱/取消
爲了知足應用系統的需求,服務消費方的可能須要從服務註冊中心訂閱指定的有服務提供方發佈的服務,在獲得通知可使用服務時,就能夠直接調用服務。反過來,若是不須要某一個服務了,能夠取消該服務。下面看一下對應的時序圖,如圖所示:
協議支持
Dubbo支持多種協議,以下所示:
在通訊過程當中,不一樣的服務等級通常對應着不一樣的服務質量,那麼選擇合適的協議即是一件很是重要的事情。你能夠根據你應用的建立來選擇。例如,使用RMI協議,通常會受到防火牆的限制,因此對於外部與內部進行通訊的場景,就不要使用RMI協議,而是基於HTTP協議或者Hessian協議。
Dubbo以包結構來組織各個模塊,各個模塊及其關係,如圖所示:
能夠經過Dubbo的代碼(使用Maven管理)組織,與上面的模塊進行比較。簡單說明各個包的狀況:
若是你們想學習以上路線內容,在此我向你們推薦一個架構學習交流羣。交流學習羣號:478030634 裏面會分享一些資深架構師錄製的視頻錄像:有Spring,MyBatis,Netty源碼分析,高併發、高性能、分佈式、微服務架構的原理,JVM性能優化、分佈式架構等這些成爲架構師必備的知識體系。還能領取免費的學習資源,目前受益良多