今天動力節點java學院小編為大家介紹“Java前沿技術——Dubbo分布式服務框架介紹”，想要學習Java前沿技術的小伙伴們，就跟隨小編的一起看看最詳細的Dubbo分布式服務框架介紹吧。

　　隨著業務的發展、用戶量的增長、系統并發訪問需求越來越大，系統數量增多，調用依賴關系也變得復雜，為了確保系統高可用、高并發的要求，系統的架構也從單體時代慢慢遷移至服務SOA時代，根據不同服務對系統資源的要求不同，我們可以更合理的配置系統資源，使系統資源利用率最大化。而Dubbo則是SOA服務化治理方案的一個核心框架。

　　Dubbo作為阿里巴巴內部的SOA服務化治理方案的核心框架，在2012年時已經每天為2000+個服務提供3,000,000,000+次訪問量支持，并被廣泛應用于阿里巴巴集團的各成員站點。Dubbo自2011年開源后，已被許多非阿里系公司使用，其中既有當當網、網易考拉等互聯網公司，也有中國人壽、青島海爾等傳統企業。

1、Dubbo框架介紹

　　Dubbo是一個高性能服務框架，致力于提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案，使得應用可通過高性能RPC實現服務的輸出和輸入功能，和Spring框架可以無縫集成。

　　作為一個分布式服務框架，以及SOA治理方案，Dubbo其功能主要包括：

　　（1）高性能NIO通訊及多協議集成

　　（2）服務動態尋址與路由

　　（3）軟負載均衡與容錯

　　（4）依賴分析與服務降級

　　Dubbo最大的特點是按照分層架構思維構建應用服務，使用這種方式可以使各個層之間解耦合(或者最大限度地松耦合)。從服務模型的角度來看，Dubbo采用的是一種非常簡單的模型，要么是提供方提供服務，要么是消費方消費服務，所以基于這一點可以抽象出服務提供方(Provider)和服務消費方(Consumer)兩個角色。

　　Dubbo包含遠程通訊、服務集群和服務發現與注冊三個核心部分。提供透明化的遠程方法調用，實現像調用本地方法一樣調用遠程方法，只需簡單配置，沒有任何API侵入。同時具備軟負載均衡及容錯機制，可在內網替代F5等硬件負載均衡器，降低成本，減少單點。可以實現服務自動注冊與發現，不再需要寫死服務提供方地址，注冊中心基于接口名查詢服務提供者的IP地址，并且能夠平滑添加或刪除服務提供者。

　　Remoting：遠程通訊，提供對多種NIO框架抽象封裝，包括“同步轉異步”和“請求-響應”模式的信息交換方式。

　　Cluster：服務集群，提供基于接口方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集群支持。

　　Registry：服務發現與注冊，基于注冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。

2、 Dubbo組件角色

Dubbo組件

　　Dubbo服務組件調用關秕說明 ：

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

　　服務提供者Provider在啟動時，向注冊中心注冊自己提供的服務。

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

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

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

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

Dubbo服務結構

　　3、Dubbo總體架構

image

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

　　下面，結合Dubbo官方文檔，我們分別理解一下框架分層架構中，各個層次的設計要點：

　　服務接口層(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。Protocol是服務域，它是Invoker暴露和引用的主功能入口，它負責Invoker的生命周期管理。Invoker是實體域，它是Dubbo的核心模型，其它模型都向它靠擾，或轉換成它，它代表一個可執行體，可向它發起invoke調用，它有可能是一個本地的實現，也可能是一個遠程的實現，也可能一個集群實現。

　　信息交換層(Exchange)：封裝請求響應模式，同步轉異步，以Request和Response為中心，擴展接口為Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。

　　網絡傳輸層(Transport)：抽象mina和netty為統一接口，以Message為中心，擴展接口為Channel、Transporter、Client、Server和Codec。

　　數據序列化層(Serialize)：可復用的一些工具，擴展接口為Serialization、 ObjectInput、ObjectOutput和ThreadPool。

　　從上圖可以看出，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實際上不算一層，而是一個獨立的節點，只是為了全局概覽，用層的方式畫在一起。

以上就是動力節點java學院小編介紹的“Java前沿技術——Dubbo分布式服務框架介紹”的內容，希望對大家有幫助，更多精彩內容請關注動力節點java學院官網。

相關免費視頻教程推薦

Dubbo分布式服務框架介紹免費視頻教程下載：http://www.dabaquan.cn/xiazai/2419.html

什么是dubbo免費視頻教程下載：http://www.dabaquan.cn/xiazai/2418.html