RPC框架dubbo架構原理及使用說明
1、Dubbo是什麼
官方定義html
DUBBO是一個分佈式服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，是阿里巴巴SOA服務化治理方案的核心框架，天天爲2,000+個服務提供3,000,000,000+次訪問量支持，並被普遍應用於阿里巴巴集團的各成員站點。前端
詳細理解，就是java
Dubbo是阿里巴巴公司開源的一個高性能優秀的服務框架，使得應用可經過高性能的 RPC 實現服務的輸出和輸入功能，能夠和spring框架無縫集成。是一個分佈式服務框架，以及SOA治理方案。其功能主要包括：高性能NIO通信及多協議集成，服務動態尋址與路由，軟負載均衡與容錯，依賴分析與降級等。 git
這裏有幾個專業名詞：1.RPC，2.分佈式，3.SOA，若是這幾個名詞有不懂的，可能理解起來就有點吃力，要回去作功課了。github
通俗理解，就是在分佈式系統中的一種RPC技術，經過Dubbo能夠實現系統或應用之間的通訊，實現應用間的解耦合（或者最大限度地鬆耦合）等。算法
2、Dubbo的由來
1.背景
隨着互聯網的發展，網站應用的規模不斷擴大，常規的垂直應用架構已沒法應對，分佈式服務架構以及流動計算架構勢在必行，亟需一個治理系統確保架構有條不紊的演進。spring
單一應用架構數據庫
當網站流量很小時，只需一個應用，將全部功能都部署在一塊兒，以減小部署節點和成本。緩存
此時，用於簡化增刪改查工做量的 數據訪問框架(ORM) 是關鍵。安全
垂直應用架構
當訪問量逐漸增大，單一應用增長機器帶來的加速度愈來愈小，將應用拆成互不相干的幾個應用，以提高效率。
此時，用於加速前端頁面開發的 Web框架(MVC) 是關鍵。
分佈式服務架構
當垂直應用愈來愈多，應用之間交互不可避免，將核心業務抽取出來，做爲獨立的服務，逐漸造成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。
此時，用於提升業務複用及整合的 分佈式服務框架(RPC) 是關鍵。
流動計算架構
當服務愈來愈多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增長一個調度中心基於訪問壓力實時管理集羣容量，提升集羣利用率。
此時，用於提升機器利用率的 資源調度和治理中心(SOA) 是關鍵。
2.需求
在大規模服務化以前，應用可能只是經過RMI或Hessian等工具，簡單的暴露和引用遠程服務，經過配置服務的URL地址進行調用，經過F5等硬件進行負載均衡。
(1) 當服務愈來愈多時，服務URL配置管理變得很是困難，F5硬件負載均衡器的單點壓力也愈來愈大。
此時須要一個服務註冊中心，動態的註冊和發現服務，使服務的位置透明。
並經過在消費方獲取服務提供方地址列表，實現軟負載均衡和Failover，下降對F5硬件負載均衡器的依賴，也能減小部分紅本。
(2) 當進一步發展，服務間依賴關係變得錯蹤複雜，甚至分不清哪一個應用要在哪一個應用以前啓動，架構師都不能完整的描述應用的架構關係。
這時，須要自動畫出應用間的依賴關係圖，以幫助架構師理清理關係。
(3) 接着，服務的調用量愈來愈大，服務的容量問題就暴露出來，這個服務須要多少機器支撐？何時該加機器？
爲了解決這些問題，第一步，要將服務如今天天的調用量，響應時間，都統計出來，做爲容量規劃的參考指標。
其次，要能夠動態調整權重，在線上，將某臺機器的權重一直加大，並在加大的過程當中記錄響應時間的變化，直到響應時間到達閥值，記錄此時的訪問量，再以此訪問量乘以機器數反推總容量。
以上是Dubbo最基本的幾個需求，更多服務治理問題參見：
http://code.alibabatech.com/blog/experience_1402/service-governance-process.html
3.架構設計圖
節點角色說明：
Provider: 暴露服務的服務提供方。
Consumer: 調用遠程服務的服務消費方。
Registry: 服務註冊與發現的註冊中心。
Monitor: 統計服務的調用次調和調用時間的監控中心。
Container: 服務運行容器。
調用關係說明：
0. 服務容器負責啓動，加載，運行服務提供者。
1. 服務提供者在啓動時，向註冊中心註冊本身提供的服務。
2. 服務消費者在啓動時，向註冊中心訂閱本身所需的服務。
3. 註冊中心返回服務提供者地址列表給消費者，若是有變動，註冊中心將基於長鏈接推送變動數據給消費者。
4. 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，若是調用失敗，再選另外一臺調用。
5. 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。
4.Dubbo的整體架構
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實際上不算一層，而是一個獨立的節點，只是爲了全局概覽，用層的方式畫在一塊兒。
5.設計的優點
(1) 連通性：
註冊中心負責服務地址的註冊與查找，至關於目錄服務，服務提供者和消費者只在啓動時與註冊中心交互，註冊中心不轉發請求，壓力較小
監控中心負責統計各服務調用次數，調用時間等，統計先在內存彙總後每分鐘一次發送到監控中心服務器，並以報表展現
服務提供者向註冊中心註冊其提供的服務，並彙報調用時間到監控中心，此時間不包含網絡開銷
服務消費者向註冊中心獲取服務提供者地址列表，並根據負載算法直接調用提供者，同時彙報調用時間到監控中心，此時間包含網絡開銷
註冊中心，服務提供者，服務消費者三者之間均爲長鏈接，監控中心除外
註冊中心經過長鏈接感知服務提供者的存在，服務提供者宕機，註冊中心將當即推送事件通知消費者
註冊中心和監控中心所有宕機，不影響已運行的提供者和消費者，消費者在本地緩存了提供者列表
註冊中心和監控中心都是可選的，服務消費者能夠直連服務提供者
(2) 健狀性：
監控中心宕掉不影響使用，只是丟失部分採樣數據
數據庫宕掉後，註冊中心仍能經過緩存提供服務列表查詢，但不能註冊新服務
註冊中心對等集羣，任意一臺宕掉後，將自動切換到另外一臺
註冊中心所有宕掉後，服務提供者和服務消費者仍能經過本地緩存通信
服務提供者無狀態，任意一臺宕掉後，不影響使用
服務提供者所有宕掉後，服務消費者應用將沒法使用，並沒有限次重連等待服務提供者恢復
(3) 伸縮性：
註冊中心爲對等集羣，可動態增長機器部署實例，全部客戶端將自動發現新的註冊中心
服務提供者無狀態，可動態增長機器部署實例，註冊中心將推送新的服務提供者信息給消費者
(4) 升級性：
當服務集羣規模進一步擴大，帶動IT治理結構進一步升級，須要實現動態部署，進行流動計算，現有分佈式服務架構不會帶來阻力：
3、如何使用Dubbo
因爲Dubbo無縫的集成了spring，因此咱們使用起來仍是很方便的，
本地服務：(Spring配置)
local.xml
<bean id=「xxxService」 class=「com.xxx.XxxServiceImpl」 /> <bean id=「xxxAction」 class=「com.xxx.XxxAction」> <property name=「xxxService」 ref=「xxxService」 /> </bean>
遠程服務：(Spring配置)
在本地服務的基礎上，只需作簡單配置，便可完成遠程化：
將上面的local.xml配置拆分紅兩份，將服務定義部分放在服務提供方remote-provider.xml，將服務引用部分放在服務消費方remote-consumer.xml。
並在提供方增長暴露服務配置<dubbo:service>，在消費方增長引用服務配置<dubbo:reference>。
以下：
服務提供者：remote-provider.xml
<bean id=「xxxService」 class=「com.xxx.XxxServiceImpl」 /> <!-- 和本地服務同樣實現遠程服務 --> <dubbo:service interface=「com.xxx.XxxService」 ref=「xxxService」 /> <!-- 增長暴露遠程服務配置 -->
服務消費者：remote-consumer.xml
<dubbo:reference id=「xxxService」 interface=「com.xxx.XxxService」 /> <!-- 增長引用遠程服務配置 --> <bean id=「xxxAction」 class=「com.xxx.XxxAction」> <!-- 和本地服務同樣使用遠程服務 --> <property name=「xxxService」 ref=「xxxService」 /> </bean>
Dubbo採用全Spring配置方式，透明化接入應用，對應用沒有任何API侵入，只需用Spring加載Dubbo的配置便可，Dubbo基於Spring的Schema擴展進行加載。
1.示例
服務提供者
定義服務接口: (該接口需單獨打包，在服務提供方和消費方共享)
package com.alibaba.dubbo.demo;
public interface DemoService {
String sayHello(String name);
}
在服務提供方實現接口：(對服務消費方隱藏實現)
package com.alibaba.dubbo.demo.provider;
import com.alibaba.dubbo.demo.DemoService;
public class DemoServiceImpl implements DemoService {
public String sayHello(String name) {
return "Hello " + name;
}
}
用Spring配置聲明暴露服務：provider.xml
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo="http://code.alibabatech.com/schema/dubbo" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xsd"> <!-- 提供方應用信息，用於計算依賴關係 --> <dubbo:application name="hello-world-app" /> <!-- 使用multicast廣播註冊中心暴露服務地址 --> <dubbo:registry address="multicast://224.5.6.7:1234" /> <!-- 用dubbo協議在端口暴露服務 --> <dubbo:protocol name="dubbo" port="20880" /> <!-- 聲明須要暴露的服務接口 --> <dubbo:service interface="com.alibaba.dubbo.demo.DemoService" ref="demoService" /> <!-- 和本地bean同樣實現服務 --> <bean id="demoService" class="com.alibaba.dubbo.demo.provider.DemoServiceImpl" /> </beans>
加載Spring配置：
import org.springframework.context.support.ClassPathXmlApplicationContext;
public class Provider {
public static void main(String[] args) throws Exception {
ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(new String[] {"http://10.20.160.198/wiki/display/dubbo/provider.xml"});
context.start();
System.in.read(); // 按任意鍵退出
}
}
服務消費者
經過Spring配置引用遠程服務：consumer.xml
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo="http://code.alibabatech.com/schema/dubbo" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xsd"> <!-- 消費方應用名，用於計算依賴關係，不是匹配條件，不要與提供方同樣 --> <dubbo:application name="consumer-of-helloworld-app" /> <!-- 使用multicast廣播註冊中心暴露發現服務地址 --> <dubbo:registry address="multicast://224.5.6.7:1234" /> <!-- 生成遠程服務代理，能夠和本地bean同樣使用demoService --> <dubbo:reference id="demoService" interface="com.alibaba.dubbo.demo.DemoService" /> </beans>
加載Spring配置，並調用遠程服務：(也可使用IoC注入)
import org.springframework.context.support.ClassPathXmlApplicationContext;
import com.alibaba.dubbo.demo.DemoService;
public class Consumer {
public static void main(String[] args) throws Exception {
ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(new String[] {"http://10.20.160.198/wiki/display/dubbo/consumer.xml"});
context.start();
DemoService demoService = (DemoService)context.getBean("demoService"); // 獲取遠程服務代理
String hello = demoService.sayHello("world"); // 執行遠程方法
System.out.println( hello ); // 顯示調用結果
}
}
2.其餘廣播方式
示例中使用的是multicast廣播暴露和發現服務的，固然還有其餘的方式，如今使用最多的是ZooKeeper
若是使用ZooKeeper則配置修改成：
<dubbo:registry address="multicast://224.5.6.7:1234" /> 替換爲 <dubbo:registry protocol="zookeeper" address="192.168.17.129:2181,192.168.17.129:2182,192.168.17.129:2183" /> 或者 <dubbo:registry address="zookeeper://192.168.17.129:2181?backup=192.168.17.129:2182,192.168.17.129:2183" />
服務提供者和服務消費者作相同的修改
3.說明
以上是Dubbo的XML配置，Dubbo還支持屬性配置，註解配置，API配置，下面介紹下API配置，另外兩種配置方式，感興趣的朋友能夠去Dubbo官網去看下：Dubbo
若是不想使用Spring配置，而但願經過API的方式進行調用（官方不推薦）則
(1) 服務提供者：
import com.alibaba.dubbo.rpc.config.ApplicationConfig;
import com.alibaba.dubbo.rpc.config.RegistryConfig;
import com.alibaba.dubbo.rpc.config.ProviderConfig;
import com.alibaba.dubbo.rpc.config.ServiceConfig;
import com.xxx.XxxService;
import com.xxx.XxxServiceImpl;
// 服務實現
XxxService xxxService = new XxxServiceImpl();
// 當前應用配置
ApplicationConfig application = new ApplicationConfig();
application.setName("xxx");
// 鏈接註冊中心配置
RegistryConfig registry = new RegistryConfig();
registry.setAddress("10.20.130.230:9090");
registry.setUsername("aaa");
registry.setPassword("bbb");
// 服務提供者協議配置
ProtocolConfig protocol = new ProtocolConfig();
protocol.setName("dubbo");
protocol.setPort();
protocol.setThreads();
// 注意：ServiceConfig爲重對象，內部封裝了與註冊中心的鏈接，以及開啓服務端口
// 服務提供者暴露服務配置
ServiceConfig<XxxService> service = new ServiceConfig<XxxService>(); // 此實例很重，封裝了與註冊中心的鏈接，請自行緩存，不然可能形成內存和鏈接泄漏
service.setApplication(application);
service.setRegistry(registry); // 多個註冊中心能夠用setRegistries()
service.setProtocol(protocol); // 多個協議能夠用setProtocols()
service.setInterface(XxxService.class);
service.setRef(xxxService);
service.setVersion("1.0.0");
// 暴露及註冊服務
service.export();
(2) 服務消費者：
import com.alibaba.dubbo.rpc.config.ApplicationConfig;
import com.alibaba.dubbo.rpc.config.RegistryConfig;
import com.alibaba.dubbo.rpc.config.ConsumerConfig;
import com.alibaba.dubbo.rpc.config.ReferenceConfig;
import com.xxx.XxxService;
// 當前應用配置
ApplicationConfig application = new ApplicationConfig();
application.setName("yyy");
// 鏈接註冊中心配置
RegistryConfig registry = new RegistryConfig();
registry.setAddress("10.20.130.230:9090");
registry.setUsername("aaa");
registry.setPassword("bbb");
// 注意：ReferenceConfig爲重對象，內部封裝了與註冊中心的鏈接，以及與服務提供方的鏈接
// 引用遠程服務
ReferenceConfig<XxxService> reference = new ReferenceConfig<XxxService>(); // 此實例很重，封裝了與註冊中心的鏈接以及與提供者的鏈接，請自行緩存，不然可能形成內存和鏈接泄漏
reference.setApplication(application);
reference.setRegistry(registry); // 多個註冊中心能夠用setRegistries()
reference.setInterface(XxxService.class);
reference.setVersion("1.0.0");
// 和本地bean同樣使用xxxService
XxxService xxxService = reference.get(); // 注意：此代理對象內部封裝了全部通信細節，對象較重，請緩存複用
4、Dubbo的一些相關疑問
1.Dubbo適用於哪些場景？
當網站變大後，不可避免的須要拆分應用進行服務化，以提升開發效率，調優性能，節省關鍵競爭資源等。
當服務愈來愈多時，服務的URL地址信息就會爆炸式增加，配置管理變得很是困難，F5硬件負載均衡器的單點壓力也愈來愈大。
當進一步發展，服務間依賴關係變得錯蹤複雜，甚至分不清哪一個應用要在哪一個應用以前啓動，架構師都不能完整的描述應用的架構關係。
接着，服務的調用量愈來愈大，服務的容量問題就暴露出來，這個服務須要多少機器支撐？何時該加機器？等等……
在遇到這些問題時，均可以用Dubbo來解決。
可參見：Dubbo的背景及需求
2.Dubbo的需求和依賴狀況？
Dubbo運行JDK1.5之上，缺省依賴javassist、netty、spring等包，但不是必須依賴，經過配置Dubbo可不依賴任何三方庫運行。
可參見：用戶指南 - 依賴
3.Dubbo的性能如何？
Dubbo經過長鏈接減小握手，經過NIO及線程池在單鏈接上併發拼包處理消息，經過二進制流壓縮數據，比常規HTTP等短鏈接協議更快。在阿里巴巴內部，天天支撐2000多個服務，30多億訪問量，最大單機支撐天天近1億訪問量。
可參見：Dubbo性能測試報告
4.和淘寶HSF相比，Dubbo的特色是什麼？
Dubbo比HSF的部署方式更輕量，HSF要求使用指定的JBoss等容器，還須要在JBoss等容器中加入sar包擴展，對用戶運行環境的侵入性大，若是你要運行在Weblogic或Websphere等其它容器上，須要自行擴展容器以兼容HSF的ClassLoader加載，而Dubbo沒有任何要求，可運行在任何Java環境中。
Dubbo比HSF的擴展性更好，很方便二次開發，一個框架不可能覆蓋全部需求，Dubbo始終保持平等對待第三方理念，即全部功能，均可以在不修改Dubbo原生代碼的狀況下，在外圍擴展，包括Dubbo本身內置的功能，也和第三方同樣，是經過擴展的方式實現的，而HSF若是你要加功能或替換某部分實現是很困難的，好比支付寶和淘寶用的就是不一樣的HSF分支，由於加功能時改了核心代碼，不得不拷一個分支單獨發展，HSF現階段就算開源出來，也很難複用，除非對架構重寫。
HSF依賴比較多內部系統，好比配置中心，通知中心，監控中心，單點登陸等等，若是要開源還須要作不少剝離工做，而Dubbo爲每一個系統的集成都留出了擴展點，並已梳理幹清全部依賴，同時爲開源社區提供了替代方案，用戶能夠直接使用。
Dubbo比HSF的功能更多，除了ClassLoader隔離，Dubbo基本上是HSF的超集，Dubbo也支持更多協議，更多註冊中心的集成，以適應更多的網站架構。
5.Dubbo在安全機制方面是如何解決的？
Dubbo主要針對內部服務，對外的服務，阿里有開放平臺來處理安全和流控，因此Dubbo在安全方面實現的功能較少，基本上只防君子不防小人，只防止誤調用。
Dubbo經過Token令牌防止用戶繞過註冊中心直連，而後在註冊中心上管理受權。Dubbo還提供服務黑白名單，來控制服務所容許的調用方。
可參見：Dubbo的令牌驗證
原文連接：http://www.cnblogs.com/study-everyday/p/6742350.html
- 1. Dubbo(一) RPC框架架構理解
- 2. RPC框架的實現原理，及RPC架構組件詳解
- 3. Spark原理框架說明
- 4. Zookeeper+Dubbo 搭建RPC框架架構原理詳述
- 5. RPC框架Dubbo學習 --- Dubbo架構與實戰（架構篇）
- 6. RPC框架（二） - Dubbo
- 7. dubbo架構及原理
- 8. dubbo框架原理
- 9. RPC框架與Dubbo完整使用
- 10. WebX框架使用說明
- 更多相關文章...
- • Docker 架構 - Docker教程
- • PHP EOF(heredoc) 使用說明 - PHP教程
- • Java Agent入門實戰（三）-JVM Attach原理與使用
- • ☆技術問答集錦（13）Java Instrument原理
-
每一个你不满意的现在，都有一个你没有努力的曾经。