Dubbo:RPC架構、SOA架構

Dubbo缺省協義采用了單一化的長連接和NIO異步通信，適用小信息量大高并發的服務項目通話和服務項目顧客機械設備數遠高于服務供應商機械設備數的狀況。

做為RPC:適用dubbo、hession、json、fastjson等各種各樣傳輸協議，底端由mina、netty長連接傳送!非常典型的provider和cusomer模式!

做為SOA:具備管理與服務作用，出示服務項目申請注冊和發覺!用zookeeper完成認證中心!啟動，服務項目方將在認證中心申請注冊全部插口，并訂購configurators、服務項目消費方訂購provide、configurators、routers、訂購變動時，zk消息推送providers、configuators、routers、啟動申請注冊長連接、通訊proveider和provider運行后，在后臺管理運行計時器，將數據統計發送至monitor(監控管理中心)!出示各種各樣不正確體制和負載平衡發展戰略!

Consumer服務項目顧客，Provider服務供應商。Container服務項目器皿。消費自然是invoke服務提供者，invoke這條實線是圖上的表明同歩的含意，在具體啟用全過程中，Provider的部位對Consumer而言是全透明的，之前啟用服務項目的部位(IP地址)和下一次啟用服務項目的部位是不確定性的。這個地方完成了軟負載。

服務供應商先運行start，隨后申請注冊register服務項目。

消費預定subscribe服務項目，要是沒有預定自身要想的服務項目，就持續試著預定。新的服務項目在認證中心申請注冊后，認證中心將這種服務項目根據notify向顧客出示。

Monitor它是一種監控，圖上的斜線表明Consumer和Provider根據多線程向Monitor發送短信，Consumer和Provider將信息內容儲存在本地硬盤中，均值1min發送短信。Monitor在全部架構中是可選擇的(圖上的斜線并不是可選擇的含意)，Monitor作用必須獨立配備，不配備或配備后，Monitor掛掉不容易危害服務項目的啟用。

什么叫netty?

netty是根據nio的顧客、網絡服務器終端設備程序編寫架構，netty出示多線程、量化策略的網絡技術應用架構和專用工具，能夠快速開發設計能用的顧客終端設備和網絡服務器。

netty是根據nio包裝jdknio，使方式更為靈便。

dubbo的基本原理?

復位全過程的關鍵點:

圖中的第一步是將服務項目裝車到器皿中，提前準備申請注冊服務項目。類似Spring中的運行全過程，當spring啟動，將bean裝車到器皿里時，先要剖析bean。因而，dubbo也要先閱讀文章文檔剖析服務項目。

剖析服務項目:剖析服務項目:

1.根據dubbo.jar內的Meta-inf/spring.handlers配備，spring在碰到dubbo名字室內空間時，招回dubonamespandler類。

2.全部dubo標識，統一用dubobeandefinitionParser剖析，根據一對一特性投射，將XML標識剖析為bean目標。

在ServiceConfig.export或ReferenceConfig.get復位時，將Bean目標變換為url文件格式，將Bean特性變換為url參數。

隨后將URL傳送給Protocol拓展點，依據拓展點的Adaptive體制，依據URL的協義頭開展不一樣協義的服務項目曝出和引入。

a.只曝露服務項目端口號。

在沒有應用認證中心的狀況下，這類狀況一般適用開發工具，服務項目的啟用和出示同樣的IP，只需打開服務的端口號就可以。

ServiceConfig剖析的URL格式以下

Dubo://service-host/com.xxx.Txxserviceversion=1.0.0。

根據拓展點的Adaptiver體制根據URL的dubo://協義頭鑒別，立即啟用DuboProtocolexport()方式，打開服務端口號。

b.向認證中心公布服務項目:

與以前的差別:必須將服務項目的IP和端口號一起曝露在認證中心。

ServiceConfig剖析的url文件格式以下

registry://registry-host/com.alibaba.dubo.registry.registryserviceexport=URL.encode(dubo://service-host/com.xxx.txxserviceversion=1.0.0)

根據拓展點的Adaptive體制，根據URL的registry://協義頭頂部鑒別，啟用RegistryProtocol的export方式，將export主要參數中的服務提供者URL申請注冊為認證中心，再度傳送給Protocol拓展點version=1.0.0。

服務項目曝出和消費的詳盡步驟。

1.服務供應商表明服務項目的詳盡全過程。

服務供應商曝露服務項目的關鍵全過程:

ServiceConfig類得到對外開放服務項目的具體類ref(比如HelloWorldImpl)，根據ProxyFactory類getInvoker方法應用ref轉化成AbstractProxyInvoker的事例。

到這個流程，實際的服務項目就完成了Invoker的變換。下面是Invoker變換到Exporter的全過程。

Dubo解決服務項目曝露的關鍵是Invoker變換到Exporter的全過程(如圖的鮮紅色一部分)，以Dubbo和RMI二種非常典型協義的完成開展表明。

Dubbo的完成:

Dubbo協義的Invoker變化為Exporter產生在Dubboprotocol類的export方式，主要是開啟socket監聽服務項目，接納顧客的各種各樣要求，通訊關鍵點由Dubo自身完成。

RMI的完成:

RMI協義的Invoker變成了RmiProtocol類export方式

根據Spring或Dubbo或JDK完成RMI服務項目，通訊關鍵點由JDK基本完成，節約了許多勞動量。

2.服務項目顧客消費服務項目的詳盡全過程。

dubbo原理和機制：應用可通過高性能的 RPC 實現服務的輸出和輸入功能，可以和Spring框架無縫集成。

服務項目消費的關鍵全過程:

ReferenceConfig類的init方式啟用Protocol的refer方式轉化成Invoker案例(如圖中的鮮紅色一部分)是服務項目消費的重要。

下面，將Invoker變換為手機客戶端需要的插口(如HelloWorld)。

以上就是動力節點小編介紹的"Dubbo的原理和機制"，希望對大家有幫助，想了解更多可查看Dubbo教程。動力節點在線學習教程，針對沒有任何Java基礎的讀者學習,讓你從入門到精通,主要介紹了一些Java基礎的核心知識，讓同學們更好更方便的學習和了解Java編程，感興趣的同學可以關注一下。