RPC理論以及Dubbo的使用介紹

RPC 的主要功能目標是讓構建分佈式應用更容易，在提供強大的遠程調用能力時不損失本地調用的語義簡潔性。

爲實現該目標，RPC 框架需提供一種透明調用機制讓使用者不必顯式的區分本地調用和遠程調用。

RPC 調用分類

RPC 調用分以下兩種：異步和同步的區分在於是否等待服務端執行完成並返回結果。

1. 同步調用 客戶方等待調用執行完成並返回結果。
2. 異步調用 客戶方調用後不用等待執行結果返回，但依然可以通過回調通知等方式獲取返回結果。 若客戶方不關心調用返回結果，則變成單向異步調用，單向調用不用返回結果。

RPC 結構模式

如下圖所示。

RPC 服務方通過 RpcServer 去導出（export）遠程接口方法，而客戶方通過 RpcClient 去引入（import）遠程接口方法。 客戶方像調用本地方法一樣去調用遠程接口方法，RPC 框架提供接口的代理實現，實際的調用將委託給代理 RpcProxy 。 代理封裝調用信息並將調用轉交給 RpcInvoker 去實際執行。 在客戶端的 RpcInvoker 通過連接器 RpcConnector 去維持與服務端的通道 RpcChannel， 並使用 RpcProtocol 執行協議編碼（encode）並將編碼後的請求消息通過通道發送給服務方。

RPC 服務端接收器 RpcAcceptor 接收客戶端的調用請求，同樣使用 RpcProtocol 執行協議解碼（decode）。 解碼後的調用信息傳遞給 RpcProcessor 去控制處理調用過程，最後再委託調用給 RpcInvoker 去實際執行並返回調用結果。

RPC 組件職責

上面我們進一步拆解了 RPC 實現結構的各個組件組成部分，下面我們詳細說明下每個組件的職責劃分。

1. RpcServer 負責導出（export）遠程接口
2. RpcClient 負責導入（import）遠程接口的代理實現
3. RpcProxy 遠程接口的代理實現
4. RpcInvoker 客戶方實現：負責編碼調用信息和發送調用請求到服務方並等待調用結果返回 服務方實現：負責調用服務端接口的具體實現並返回調用結果
5. RpcProtocol 負責協議編/解碼
6. RpcConnector 負責維持客戶方和服務方的連接通道和發送數據到服務方
7. RpcAcceptor 負責接收客戶方請求並返回請求結果
8. RpcProcessor 負責在服務方控制調用過程，包括管理調用線程池、超時時間等
9. RpcChannel 數據傳輸通道

RPC 實現分析

在進一步拆解了組件並劃分了職責之後，這裏以在 java 平臺實現該 RPC 框架概念模型爲例，詳細分析下實現中需要考慮的因素。

導出遠程接口

導出遠程接口的意思是指只有導出的接口可以供遠程調用，而未導出的接口則不能。 在 java 中導出接口的代碼片段可能如下：

DemoService demo   = new ...; RpcServer   server = new ...; server.export(DemoService.class, demo, options);

我們可以導出整個接口，也可以更細粒度一點只導出接口中的某些方法，如：

// 只導出 DemoService 中籤名爲 hi(String s) 的方法 server.export(DemoService.class, demo, "hi", new Class<?>[] { String.class }, options);

java 中還有一種比較特殊的調用就是多態，也就是一個接口可能有多個實現，那麼遠程調用時到底調用哪個？ 這個本地調用的語義是通過 jvm 提供的引用多態性隱式實現的，那麼對於 RPC 來說跨進程的調用就沒法隱式實現了。 如果前面 DemoService 接口有 2 個實現，那麼在導出接口時就需要特殊標記不同的實現，如：

DemoService demo   = new ...;
DemoService demo2  = new ...;
RpcServer   server = new ...;
server.export(DemoService.class, demo, options);
server.export("demo2", DemoService.class, demo2, options);

上面 demo2 是另一個實現，我們標記爲 demo2 來導出， 那麼遠程調用時也需要傳遞該標記才能調用到正確的實現類，這樣就解決了多態調用的語義。

導入遠程接口與客戶端代理

導入相對於導出遠程接口，客戶端代碼爲了能夠發起調用必須要獲得遠程接口的方法或過程定義。 目前，大部分跨語言平臺 RPC 框架採用根據 IDL 定義通過 code generator 去生成 stub 代碼， 這種方式下實際導入的過程就是通過代碼生成器在編譯期完成的。 我所使用過的一些跨語言平臺 RPC 框架如 CORBAR、WebService、ICE、Thrift 均是此類方式。

代碼生成的方式對跨語言平臺 RPC 框架而言是必然的選擇，而對於同一語言平臺的 RPC 則可以通過共享接口定義來實現。 在 java 中導入接口的代碼片段可能如下：

RpcClient client = new ...; DemoService demo = client.refer(DemoService.class); demo.hi("how are you?");

在 java 中 import 是關鍵字，所以代碼片段中我們用 refer 來表達導入接口的意思。 這裏的導入方式本質也是一種代碼生成技術，只不過是在運行時生成，比靜態編譯期的代碼生成看起來更簡潔些。 java 裏至少提供了兩種技術來提供動態代碼生成，一種是 jdk 動態代理，另外一種是字節碼生成。 動態代理相比字節碼生成使用起來更方便，但動態代理方式在性能上是要遜色於直接的字節碼生成的，而字節碼生成在代碼可讀性上要差很多。 兩者權衡起來，個人認爲犧牲一些性能來獲得代碼可讀性和可維護性顯得更重要。

協議編解碼

客戶端代理在發起調用前需要對調用信息進行編碼，這就要考慮需要編碼些什麼信息並以什麼格式傳輸到服務端才能讓服務端完成調用。 出於效率考慮，編碼的信息越少越好（傳輸數據少），編碼的規則越簡單越好（執行效率高）。 我們先看下需要編碼些什麼信息：

調用編碼

1. 接口方法 包括接口名、方法名
2. 方法參數 包括參數類型、參數值
3. 調用屬性 包括調用屬性信息，例如調用附件隱式參數、調用超時時間等

返回編碼

1. 返回結果 接口方法中定義的返回值
2. 返回碼 異常返回碼
3. 返回異常信息 調用異常信息

除了以上這些必須的調用信息，我們可能還需要一些元信息以方便程序編解碼以及未來可能的擴展。 這樣我們的編碼消息裏面就分成了兩部分，一部分是元信息、另一部分是調用的必要信息。 如果設計一種 RPC 協議消息的話，元信息我們把它放在協議消息頭中，而必要信息放在協議消息體中。 下面給出一種概念上的 RPC 協議消息設計格式：

傳輸服務

協議編碼之後，自然就是需要將編碼後的 RPC 請求消息傳輸到服務方，服務方執行後返回結果消息或確認消息給客戶方。 RPC 的應用場景實質是一種可靠的請求應答消息流，和 HTTP 類似。 因此選擇長連接方式的 TCP 協議會更高效，與 HTTP 不同的是在協議層面我們定義了每個消息的唯一 id，因此可以更容易的複用連接。

既然使用長連接，那麼第一個問題是到底 client 和 server 之間需要多少根連接？ 實際上單連接和多連接在使用上沒有區別，對於數據傳輸量較小的應用類型，單連接基本足夠。 單連接和多連接最大的區別在於，每根連接都有自己私有的發送和接收緩衝區， 因此大數據量傳輸時分散在不同的連接緩衝區會得到更好的吞吐效率。 所以，如果你的數據傳輸量不足以讓單連接的緩衝區一直處於飽和狀態的話，那麼使用多連接並不會產生任何明顯的提升， 反而會增加連接管理的開銷。

連接是由 client 端發起建立並維持。 如果 client 和 server 之間是直連的，那麼連接一般不會中斷（當然物理鏈路故障除外）。 如果 client 和 server 連接經過一些負載中轉設備，有可能連接一段時間不活躍時會被這些中間設備中斷。 爲了保持連接有必要定時爲每個連接發送心跳數據以維持連接不中斷。 心跳消息是 RPC 框架庫使用的內部消息，在前文協議頭結構中也有一個專門的心跳位， 就是用來標記心跳消息的，它對業務應用透明。

執行調用

client stub 所做的事情僅僅是編碼消息並傳輸給服務方，而真正調用過程發生在服務方。 server stub 從前文的結構拆解中我們細分了 RpcProcessor 和 RpcInvoker 兩個組件， 一個負責控制調用過程，一個負責真正調用。 這裏我們還是以 java 中實現這兩個組件爲例來分析下它們到底需要做什麼？

java 中實現代碼的動態接口調用目前一般通過反射調用。 除了原生的 jdk 自帶的反射，一些第三方庫也提供了性能更優的反射調用， 因此 RpcInvoker 就是封裝了反射調用的實現細節。

調用過程的控制需要考慮哪些因素，RpcProcessor 需要提供什麼樣地調用控制服務呢？ 下面提出幾點以啓發思考：

1. 效率提升 每個請求應該儘快被執行，因此我們不能每請求來再創建線程去執行，需要提供線程池服務。
2. 資源隔離 當我們導出多個遠程接口時，如何避免單一接口調用佔據所有線程資源，而引發其他接口執行阻塞。
3. 超時控制 當某個接口執行緩慢，而 client 端已經超時放棄等待後，server 端的線程繼續執行此時顯得毫無意義。

RPC 異常處理

無論 RPC 怎樣努力把遠程調用僞裝的像本地調用，但它們依然有很大的不同點，而且有一些異常情況是在本地調用時絕對不會碰到的。 在說異常處理之前，我們先比較下本地調用和 RPC 調用的一些差異：

1. 本地調用一定會執行，而遠程調用則不一定，調用消息可能因爲網絡原因並未發送到服務方。
2. 本地調用只會拋出接口聲明的異常，而遠程調用還會跑出 RPC 框架運行時的其他異常。
3. 本地調用和遠程調用的性能可能差距很大，這取決於 RPC 固有消耗所佔的比重。

正是這些區別決定了使用 RPC 時需要更多考量。 當調用遠程接口拋出異常時，異常可能是一個業務異常， 也可能是 RPC 框架拋出的運行時異常（如：網絡中斷等）。 業務異常表明服務方已經執行了調用，可能因爲某些原因導致未能正常執行， 而 RPC 運行時異常則有可能服務方根本沒有執行，對調用方而言的異常處理策略自然需要區分。

由於 RPC 固有的消耗相對本地調用高出幾個數量級，本地調用的固有消耗是納秒級，而 RPC 的固有消耗是在毫秒級。 那麼對於過於輕量的計算任務就並不合適導出遠程接口由獨立的進程提供服務， 只有花在計算任務上時間遠遠高於 RPC 的固有消耗才值得導出爲遠程接口提供服務。

***************************************************************************基於 RPC 機制的工具 -- Dubbo *********************************************************************************

Dubbo是什麼

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

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

Dubbo能做什麼

Dubbo功能強大，總結下來，它大致可以做以下幾件事：

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

Dubbo架構圖

這是最重要的，理解Dubbo的架構圖是理解Dubbo的第一步，我從Dubbo官網手冊上截了一下Dubbo架構圖：

在接下來的講解之前，說明一個概念：所謂SOA也好，分佈式服務框架也好，不是服務消費者從中間件（一般都是Zookeeper）上去拿數據，而是服務消費者從中間件上拿到可用的服務生產者的集羣地址，再從集羣地址中選出一個進行直連。

接下來認識一下圖中的結點：

• Provider：暴露服務的服務提供方，或者直白點說就是服務生產者
• Consumer：調用遠程服務的服務消費方，也就是服務消費者
• Registry：服務註冊與發現的註冊中心
• Monitor：統計服務的調用次數和調用時間的監控中心
• Container：服務（生產者）運行容器

圖中已經有了調用步驟了，接着對步驟進行說明：

• 0：服務容器負責啓動、加載、運行服務提供者（生產者）
• 1：服務提供者（生產者）在啓動時，向註冊中心註冊自己提供的服務
• 2：服務消費者在啓動時，向註冊中心訂閱自己所需的服務
• 3：註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中細膩將基於長連接推送變更數據給消費者
• 4：服務消費者從服務生產者地址列表中，基於軟負載均衡算法，選擇一臺提供者（生產者）進行調用，如果調用失敗，再選另一臺調用
• 5：服務消費者和提供者（生產者），在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心

Dubbo用法

Dubbo採用全Spring配置方式，透明化接入應用，對應用沒有任何API侵入（這句話的意思是應用程序不會、不需要手動調用Dubbo的任何類和任何接口），只需用Spring加載Dubbo的配置即可（意思是對Dubbo的使用只需要寫Spring配置文件或註解），Dubbo基於Spring的Schema擴展進行加載。

如果不想使用Spring配置，而希望通過API的方式進行調用，可以自己看一下官方手冊Dubbo API配置，但是，這種做法十分不推薦。

下面簡單說明一下Dubbo的用法，首先要定義服務生產者的接口及其實現，那麼定義一個接口（該接口需要單獨打包，在生產者和消費者之間共享）：

package com.xrq.dubbo.demo;

public interface DemoService
{
    String sayHello(String name);    
}

在服務生產者處實現接口（對服務消費者隱藏接口實現細節）：

package com.xrq.dubbo.demo.provider;

import com.xrq.dubbo.demo.DemoService;

public class DemoServiceImpl implements DemoService
{
    public String sayHello(String name)
    {
        return "Hello " + name;
    }
}

寫一個provider.xml，在服務生產者使用Spring暴露服務：

<?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協議在20880端口暴露服務 -->
    <dubbo:protocol name="dubbo" port="20880" />
 
    <!-- 聲明需要暴露的服務接口 -->
    <dubbo:service interface="com.xrq.dubbo.demo.DemoService" ref="demoService" />
 
    <!-- 和本地bean一樣實現服務 -->
    <bean id="demoService" class="com.xrq.dubbo.demo.provider.DemoServiceImpl" />
 
</beans>

在服務消費者處寫一個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拿到demoService，即可像使用本地接口一樣使用DemoService這個接口裏面的方法：

import org.springframework.context.support.ClassPathXmlApplicationContext;
import com.xrq.dubbo.demo.DemoService;
 
public class Consumer 
{
    public static void main(String[] args) throws Exception    
    {
        ClassPathXmlApplicationContext context = 
            new ClassPathXmlApplicationContext(new String[] {"http://aaa.bbb.ccc:dddd/eee/fff/consumer.xml"});
        context.start();
 
        DemoService demoService = (DemoService)context.getBean("demoService"); // 獲取遠程服務代理
        String hello = demoService.sayHello("world"); // 執行遠程方法
 
        System.out.println(hello); // 顯示調用結果
    }
}

看到整個過程中：

1、沒有任何Dubbo的代碼，使用Dubbo的時候全部都是Spring配置，這就是前面提到的Dubbo對應用沒有任何API侵入

2、不需要考慮底層線程模型、序列化、反序列化、url解析等問題，這些都是Dubbo底層做好的

Dubbo常用標籤

首先說一個優先級的問題，在dubbo中比如timeout、retries、loadbalance等參數可以在多個標籤內同時配置，它們之間的優先級，dubbo手冊上是這麼說的：

OK，下面羅列一些Dubbo常用的，也就是說每個項目的Dubbo的xml文件中基本都會出現的標籤，並以表格形式列舉標籤中常見的可用屬性。

1、<dubbo:service /> 用於服務生產者暴露服務配置

屬    性	類    型	是否必填	缺省值	描    述
interface	class	必填	無	服務接口全路徑
ref	object	必填	無	服務對象實現引用
version	string	可選	0.0.0	服務版本，建議使用兩位數字版本如1.0，通常在接口不兼容時版本號才需要升級
timeout	int	可選	1000	遠程服務調用超時時間（毫秒）
retries	int	可選	2	遠程服務調用重試次數，不包括第一次調用，不需要重試請設爲0
connections	int	可選	100	每個生產者的最大連接數，短連接協議如rmi，表示限制連接數；長連接協議如dubbo表示建立的長連接個數
loadbalance	string	可選	random	負載均衡策略，可選值爲：random（隨機）、roundrobin（輪詢）、leastactive（最少活躍調用）
async	boolean	可選	false	是否缺省異步執行，不可靠的異步，只是忽略返回值，不阻塞執行線程
register	boolean	可選	true	該協議的服務是否註冊到註冊中心

2、<dubbo:reference /> 用於服務消費者引用服務配置

屬    性	類    型	是否必填	缺省值	描    述
id	string	必填	無	服務引用beanId
interface	class	必填	無	服務接口全路徑
version	string	可選	無	服務版本，與服務生產者的版本一致
timeout	long	可選	使用<dubbo:consumer>的timeout	服務方法調用超時時間（毫秒）
retries	int	可選	使用<dubbo:consumer>的retries	遠程服務調用重試次數，不包括第一次調用，不需要重試請設爲0
connections	int	可選	使用<dubbo:consumer>的connections	每個生產者的最大連接數，短連接協議如rmi，表示限制連接數；長連接協議如dubbo表示建立的長連接個數
loadbalance	string	可選	使用<dubbo:consumer>的loadbalance	負載均衡策略，可選值爲：random（隨機）、roundrobin（輪詢）、leastactive（最少活躍調用）
async	boolean	可選	使用<dubbo:consumer>的async	是否缺省異步執行，不可靠的異步，只是忽略返回值，不阻塞執行線程
check	boolean	可選	使用<dubbo:consumer>的check	啓動時檢查服務生產者是否存在，true則報錯，false則忽略
url	string	可選	無	點對點直連服務提供者地址，將繞過註冊中心，比如"dubbo://localhost:20890"，這個比較多的使用在測試中
protocol	string	可選	無	只調用指定協議的服務生產者，其他協議忽略

3、<dubbo:protocol /> 用於服務生產者協議配置（如果需要支持多協議，可以聲明多個此標籤，並在<dubbo:service />通過protocol屬性指定使用的協議）

屬    性	類    型	是否必填	缺省值	描    述
id	string	可選	dubbo	協議beanId，<dubbo service />中的protocol引用此ID，如果不填缺省和name屬性值一樣
name	sring	必填	dubbo	協議名稱
port	int	可選	dubbo->20800,rmi->1099,http->80,hessian->80 如果配置爲-1或未配置，則會分配一個沒有被佔用的端口	服務端口
host	string	可選	自動查找本機ip	爲空則自動查找本機ip，建議不配置讓Dubbo自動獲取本機ip
threadpool	string	可選	fixed	線程池類型，可選fixed/cached
threads	int	可選	100	服務線程池大小（固定大小）
serialization	string	可選	dubbo->hession2,rmi->java,http->json	協議序列化方式，當協議支持多種序列化方式時使用
register	boolean	可選	true	該協議的服務是否註冊到註冊中心

4、<dubbo:registry /> 用於註冊中心配置（如果有多個不同的註冊中心可以聲明多個標籤並且<dubbo:service />或<dubbo:reference />中使用registry屬性指定）

屬    性	類    型	是否必填	缺省值	描    述
id	string	可選	無	註冊中心引用beanId，可在<dubbo:service />或<dubbo:reference />中引用此ID
address	string	必填	無	註冊中心服務地址，如果地址沒有端口缺省爲9090，同一個集羣內的多個地址用逗號分隔，如：ip:port,ip:port，不同的 集羣註冊中心請配置多個<dubbo:registry />標籤
protocol	string	可選	dubbo	註冊中心地址協議，支持dubbo、http、local三種協議，分別表示dubbo地址、http地址和本地註冊中心
port	int	可選	9090	註冊中心缺省端口，當address沒有帶端口時使用此端口作爲缺省值
username	string	可選	無	登陸註冊中心用戶名，如果註冊中心不需要驗證可不填
password	string	可選	無	登陸註冊中心密碼，如果註冊中心不需要驗證可不填
transport	string	可選	netty	網絡傳輸方式，可選mina、netty
timeout	int	可選	5000	註冊中心請求超時時間（毫秒）
file	string	可選	無	使用文件緩存註冊中心地址列表以及服務提供者列表，應用重啓時將基於此文件恢復，注意兩個註冊中心不能使用同一文件存儲
check	boolean	可選	true	註冊中心不存在時，是否報錯
register	boolean	可選	true	是否向此註冊中心註冊服務，如果設爲false，將只訂閱，不註冊
subscribe	boolean	可選	true	是否向此註冊中心訂閱服務，如果設爲false，將只註冊，不訂閱

5、<dubbo:method />用於方法級配置（該標籤爲<dubbo:service/>或<dubbo:reference/>的子標籤，用於控制到方法級）

屬    性	類    型	是否必填	缺省值	描    述
method	string	必填	無	方法名
timeout	int	可選	缺省爲<dubbo:reference/>的timeout	方法調用超時時間（毫秒）
retires	int	可選	缺省爲<dubbo:reference/>的retries	遠程服務調用重試次數，不包括第一次調用，不需要重試請設爲0
loadbalance	string	可選	缺省爲<dubbo:reference/>的loadbalance	負載均衡策略，可選值爲：random（隨機）、roundrobin（輪詢）、leastactive（最少活躍調用）
async	boolean	可選	缺省爲<dubbo:reference/>的async	是否異步執行，不可靠異步，只是忽略返回值，不阻塞執行線程
actives	int	可選	0	每服務消費者最大併發調用限制
executes	int	可選	0	每服務每方法最大使用線程數限制，此屬性只在<dubbo:method/>作爲<dubbo:service/>子標籤時有效

另外，還有<dubbo:provider/>和<dubbo:consumer/>分別表示服務提供者（生產者）和服務消費者的缺省值配置，就不列舉了。

Dubbo協議dubbo://

前面有說到一個Dubbo協議，下面來看一下Dubbo協議。

Dubbo協議Dubbo的缺省協議，使用基於mina1.1.7+hessian3.2.1的tbremoting交互。

• 連接個數：單連接
• 連接方式：長連接
• 傳輸協議：TCP
• 傳輸方式：NIO異步傳輸
• 序列化：Hessian二進制序列化【效率高】
• 適用範圍：傳入傳出參數數據包較小（建議小於100K），消費者比提供者個數多，單一消費者無法壓滿提供者，儘量不要使用dubbo協議傳輸大文件或超大字符串
• 使用場景：常規遠程服務方法調用

從上面的適用範圍總結，dubbo適合小數據量大併發的服務調用，以及消費者機器遠大於生產者機器數的情況，不適合傳輸大數據量的服務比如文件、視頻等，除非請求量很低。

另外，Dubbo手冊還給開發者列出了Dubbo協議使用的約束：

1. 參數及返回值需要實現Serializable接口
2. 參數及返回值自定義實現List、Map、Number、Date、Calendar等接口，只能用JDK自帶的實現，因爲hessian會做特殊處理，自定義實現類中的屬性值都會丟失