Dubbo的序列化協(xié)議擴展及其RPC協(xié)議Thrift的優(yōu)化

翟成彤，董海峰

（西安石油大學(xué) 計算機學(xué)院，西安710065）

1 概述

Dubbo是一個專注于提供高性能和透明RPC遠程服務(wù)調(diào)用的解決方案，同時也是阿里巴巴內(nèi)部SOA服務(wù)治理的核心框架，每天為2000+服務(wù)提供超過30億次調(diào)用并且常常廣泛見于移動互聯(lián)網(wǎng)+的應(yīng)用中［1］。

隨著技術(shù)日新月異的發(fā)展，出現(xiàn)了許多在序列化和跨平臺服務(wù)調(diào)用方面優(yōu)秀的新技術(shù)。如果能夠把這些優(yōu)秀的技術(shù)整合到Dubbo架構(gòu)中，那么就可以提升Dubbo的序列化性能和跨平臺調(diào)用的能力。

在遠程調(diào)用方面，使用更高效的序列化協(xié)議Protostuff編碼和解碼，以提高傳輸數(shù)據(jù)的性能和減少系統(tǒng)調(diào)用響應(yīng)的時間。此外，在互聯(lián)網(wǎng)公司可能會使用不同的語言去開發(fā)軟件，同時為了提高代碼的復(fù)用性和異構(gòu)系統(tǒng)之間的互相調(diào)用，開源社區(qū)團隊基于Dubbo擴展了REST協(xié)議，用來在異構(gòu)系統(tǒng)之間進行通訊。但是，該類模式卻是通過（HTTP+JSON／XML）文本的方式傳輸數(shù)據(jù)，性能并不是很好［2］。如果使用跨語言的Thrift二進制協(xié)議，可以極大地提高在異構(gòu)系統(tǒng)之間調(diào)用的性能。

2 背景

2.1 Protostuff and Hessian2 對比

Dubbo默認的序列化協(xié)議Hessian2相比基于Protobuf的 Protostuff協(xié)議更慢［3］，因此，Protostuff協(xié)議可以被添加到Dubbo的默認RPC序列化協(xié)議棧中，用來更加高效地提升Dubbo RPC傳輸性能。

2.2 Dubbo中的Thrift協(xié)議和原生的Thrift協(xié)議比較

Dubbo協(xié)議棧默認有一種Thrift協(xié)議的實現(xiàn)，但卻不是原生的Thrift協(xié)議，因為有一個協(xié)議頭被添加到了Thrift協(xié)議，破壞了原生Thrift協(xié)議，使得解析協(xié)議比原生協(xié)議更為繁復(fù)與耗時。如果實踐中需要考慮用到跨語言通信，最好的方式是使用原生的Thrift協(xié)議，因其具有更好的跨平臺特性。故而，本文擬嘗試去重構(gòu)Dubbo RPC協(xié)議棧中的Thrift協(xié)議以便支持原生的Thrift協(xié)議，給框架帶來更高的性能和跨平臺特性。

2.3 Dubbo系統(tǒng)調(diào)用基本模型

Dubbo系統(tǒng)間調(diào)用如圖1所示。由圖1可知，該模型設(shè)計中的重點功能闡釋詳見如下。

（1）服務(wù)提供者在啟動時，即在注冊中心注冊。

（2）服務(wù)消費者啟動，則向注冊中心訂閱服務(wù)。

（3）注冊中心為消費者返回服務(wù)提供者列表，如果提供者發(fā)生了改變，注冊中心就會基于長連接再將改變的數(shù)據(jù)推送到消費者。

（4）服務(wù)消費者從提供者列表中，使用負載均衡算法選擇一個提供者加以調(diào)用，如果調(diào)用失敗，然后選擇另外一個。

圖1 Dubbo系統(tǒng)間調(diào)用Fig.1 Dubbo call between systems

3 擴展設(shè)計與實現(xiàn)

Dubbo使用微內(nèi)核和插件化的結(jié)構(gòu)，這樣的設(shè)計表現(xiàn)出擴展性強的特點。Dubbo的可擴展性原則是基于 JDK 的 SPI（service provider interface）［4］，SPI是通過自定義＠SPI注解和擴展點加載類ExtensionLoader來實現(xiàn)的。

ExtensionLoader通過解析指定目錄／METAINF／services／下的接口擴展文件加載被標(biāo)記為＠SPI接口的實現(xiàn)類。

因此，有2個步驟來擴展注釋＠SPI注解的接口。分別是：實現(xiàn)接口；在工程目錄／META-INF／services／path下，創(chuàng)建一個文件名為接口全路徑名的文本文件。

首先，在github上下載dubbox源代碼，然后在本地idea編輯器打開由maven構(gòu)建的工程結(jié)構(gòu)。本節(jié)主要研究了dubbo-common模塊和dubbo-rpc模塊的基礎(chǔ)。在所有擴展被實現(xiàn)后，整個dubbox項目編譯為dubbo.jar包。對此可做探討分述如下。

3.1 擴展protostuff序列化協(xié)議

3.1.1 Protosutff協(xié)議實現(xiàn)擴展

研究可知，在dubbo-common模塊中進行擴展包支持的序列化，就需要建立一個包來擴展protostuff協(xié)議，在這個包中需要實現(xiàn)Dubbo架構(gòu)的3個核心接口的序列化，即：com.alibaba.dubbo.serialize.Serialization；com.alibaba.dubbo.common.serialize.ObjectInput； com.alibaba.dubbo.common.serialize.ObjectOutput； 擴展序列化協(xié)議名稱定義為 protostuff，并支持 protostuff1.0.8。 在這個包中，設(shè)有5個類，也就是：ProtostuffObjectInput、ProtostuffObjectOutput、 ProtostuffSerialization、 Serialization Util、ProtostuffFactory。 其中 ProtostuffObjectInput實現(xiàn)ObjectInput接口，處理輸入流的反序列化；ProtostuffObjectOutput實現(xiàn) ObjectOuput接口，處理輸出流的序列化；ProtostuffSerialization實現(xiàn)Serialization接口，定義序列化名稱、序列化編號，并且實現(xiàn)序列化和反序列化函數(shù)。而SerializationUtil，ProtostuffFactory這2個類則是設(shè)計調(diào)用 protostuff 1.0.8.jar來處理函數(shù)的序列化和反序列化。 接口和實現(xiàn)類的關(guān)系如圖2所示。序列化數(shù)據(jù)的實現(xiàn)過程如圖3所示。反序列化數(shù)據(jù)實現(xiàn)過程如圖4所示。

在此基礎(chǔ)上，項目的根目錄／resours／METAINF／dubbo／com.alibaba.dubbo.common.serialize.Serialization就需要添加一行，內(nèi)容表述如下：fileprotostuff＝ com.alibaba.dubbo.common.serialize.support.protostuff.ProtostuffSerialization

當(dāng)獲取到序列化接口的實現(xiàn)時，通過SPI機制，可以加載擴展的實現(xiàn)類。

圖2 序列化接口和實現(xiàn)類關(guān)系Fig.2 Serialize interfaces and relationships of implementation class

圖3 輸出流數(shù)據(jù)序列化類的實現(xiàn)Fig.3 The implementation of output stream data serialization class

圖4 輸入流反序列化類的實現(xiàn)Fig.4 The implementation of input stream deserialization class

3.1.2 Protostuff配置和使用

Dubbo在傳輸層實現(xiàn)數(shù)據(jù)的序列化和反序列化，也就是編碼和解碼。根據(jù)Dubbo的數(shù)據(jù)包結(jié)構(gòu)特征，可以知道，當(dāng)數(shù)據(jù)流到達傳輸層時可以讀取在服務(wù)提供者的目錄下xml形式的protostuff序列化協(xié)議配置，例如：＜dubbo：protocol name＝”dubbo” Serialization＝”protostuff” ／＞， 然 后 就 會 加 載 序 列 化 實 現(xiàn)ProtostuffSerialization。當(dāng)使用 ProtostuffSerialization序列化和反序列化數(shù)據(jù)時，服務(wù)提供者將會對數(shù)據(jù)進行編碼和解碼。

服務(wù)提供者編碼數(shù)據(jù)并提供給消費者的核心處理過程如圖5所示。服務(wù)的提供者從服務(wù)消費者接收到請求數(shù)據(jù)并解碼的過程如圖6所示。

圖5 數(shù)據(jù)編碼過程Fig.5 Data encoding process

圖6 數(shù)據(jù)解碼過程Fig.6 Data decoding process

3.2 RPC的Thrift協(xié)議擴展

3.2.1 優(yōu)化 Thrift協(xié)議的實現(xiàn)

研究中，需要在dubbox項目目錄下創(chuàng)建名字為dubbo-rpc-thriftx的模塊，這個名字為了和以前dubbo-rpc-thrift作區(qū)分同時可以被兼容，符合設(shè)計模式開閉原則［5］。 這里使用原生 thrift0.10.0.jar作為支持，在此基礎(chǔ)上原生協(xié)議可以使用，命名為thriftX。在新近啟用的模塊目錄下創(chuàng)建新的目錄com ／alibaba ／dubbo ／rpc ／protocol／thriftx，用來存儲協(xié)議擴展類的實現(xiàn)，其中之一需要實現(xiàn)RPC通訊協(xié)議的核心—com.alibaba.dubbo.rpc.Protocol。 在這個 thriftx包中還需要實現(xiàn) thriftXprotocol和ThriftUtils這2個類。其中，ThriftUtils是用來生產(chǎn)網(wǎng)絡(luò)通訊所需對象的工程，thriftXprotocol是Protocol接口的實現(xiàn)，可用于暴露遠程服務(wù)和引用遠程服務(wù)，具體的設(shè)計細節(jié)是ThriftUtils工具類調(diào)用thrift1.10.jar包中的方法實現(xiàn)。

研究可得，通過實現(xiàn)thriftXprotocol類發(fā)布服務(wù)的過程，如圖7所示。通過實現(xiàn)thriftXprotocol類引用服務(wù)的過程，如圖8所示。

圖7 ThriftX協(xié)議暴露服務(wù)過程Fig.7 ThritfX protocol exposure service process

圖8 ThriftX協(xié)議引用服務(wù)的過程 Fig.8 ThriftX protocol referencing service process

接下來， 在 src／main／resources／META-INF／dubbo／internal／com.alibaba.dubbo.rpc.Protocol路徑下文本文件中加入 ThriftX ＝ com.alibaba.dubbo.rpc.protocol.thriftx.ThriftXProtocol。 當(dāng)獲得 RPC 通信協(xié)議接口的實現(xiàn)時，可以通過SPI機制將其加載到擴展實現(xiàn)類中。

3.2.2 ThriftX 協(xié)議的配置和使用

首先，定義一個service.thrift文件，再編譯生成接口文件。然后拷貝文件到服務(wù)提供和服務(wù)消費者工程。

在服務(wù)提供者中，接口的方法需要被實現(xiàn)并且接口需要被暴露，服務(wù)暴露的過程可分述如下。

（1）在服務(wù)啟動時，spring容器根據(jù)配置的xml文件［6］， 可將 ＜dubbo：servier protocol＝ ” thriftX”interface ＝ ” com.alibaba.dubbo.demo.DemoService＄Iface” ／＞， 解析到 ServiceConfig， 而后通過ServiceConfig獲取到格式如下格式的 URL：Registry：／／registry-addr／com.alibaba.dubbo.registry.RegistryService？ Export＝ URL.encode（ ” thriftX：／／service-addr／com.alibaba.dubbo.demo.DemoService＄ Iface？ Version＝1.0.0”）。

（2）通過 URL 中的”registry：／／”約定協(xié)議頭的識別，則將會調(diào)用RegistryProtocol類中的export（）方法，接著將讀取URL中的參數(shù)注冊到注冊中心。服務(wù)提供者的 URL 格式如：”thriftX：／／serviceaddr／com.alibaba.dubbo.demo.DemoService ＄ Iface？Version ＝ 1.0.0”。 通過調(diào)用 URL 中的”thrift：／／”協(xié)議頭，會調(diào)用export（）方法打開服務(wù)端口。thriftX暴露服務(wù)的過程如圖7所示。

進一步研究可知，客戶端服務(wù)調(diào)用過程可以分為2步，對此可闡述如下。

（1）客戶端服務(wù)使用dubbo的方式調(diào)用XML文件中定義的服務(wù)引用的接口，服務(wù)引用過程的研究內(nèi)容如下。

① 在XML配置文件中配置＜dubbo：reference id＝”DemoService” interface＝ ”com.alibaba.dubbo.demo.DemoService ＄Iface”／＞ ，根據(jù) Spring 約束，XML標(biāo)簽會被ReferenceConfig對象解析過后，通過此對象獲取url。

② 通過 URL”registry：／／”協(xié)議頭識別，服務(wù)將會調(diào)用RegistryProtocol類中的refer（）方法，使得后續(xù)通過配置的參數(shù)查詢提供者url，例如：thriftX：／／service-addr／com.alibaba.dubbo.demo.DemoService＄ Iface？ Version ＝ 1.0.0.。 在 解 析 thrifx：／／時，thriftXProtocol中的doRefer（）方法會被調(diào)用，如圖8所示。

（2）客戶端可能是一種沒有使用dubbo的狀態(tài)，更甚至不是由Java語言編寫的，這就需要根據(jù)特定的語言接口文件的需要，客戶端使用不同定義的接口thrift文件。通過接口文件可以得到一個Client對象，客戶端對象包含stub的所有接口函數(shù)，而用戶代碼可以通過Client對象來調(diào)用thrift文件的接口函數(shù)，事實上，Client調(diào)用的是接口函數(shù)的本地stub接口。接口函數(shù)的stub將調(diào)用請求發(fā)送到服務(wù)提供者，同時服務(wù)提供者根據(jù)調(diào)用的函數(shù)名和函數(shù)參數(shù)調(diào)用實際的實現(xiàn)函數(shù)來進行特定的操作。Thrift服務(wù)提供者在指令處理流程后，會將相應(yīng)函數(shù)的返回值發(fā)送到調(diào)用客戶端對象。Thrift的客戶端對象將函數(shù)的返回值傳遞給用戶的調(diào)用函數(shù)以完成調(diào)用過程。

4 性能測試

4.1 測試環(huán)境

本文測試在同一臺機器部署了zookeeper，也就是服務(wù)提供者和服務(wù)消費者的筆記本電腦上。這臺機器的配置是，Thinkpad-E450，memory 4 G，CPU intel i5 win7 操作系統(tǒng)和 jdk1.7.0_07。

4.2 測試數(shù)據(jù)（單線程）

（1）定義包含通用數(shù)據(jù)類型的Stu對象，例如：

public class Stu implements Serializable｛

public String name；

public Integer age；

public double account；

public Date birth；

public Boolean high；

public long height；

／／get set method

｝

（2）測試數(shù)據(jù)類型

簡單的對象Stu

復(fù)雜對象（list＜stu＞包含100個stu對象）

1 K字符串

10 K字符串

1 M字符串（代表較大數(shù)據(jù)）

（3）測試設(shè)計。在測試不同協(xié)議的性能時，研究中并未考慮服務(wù)器處理特定服務(wù)的耗時操作，因此用于測試的服務(wù)提供者處理邏輯旨在返回客戶端請求的數(shù)據(jù)。另外，單個請求的響應(yīng)時間相對較小，不容易衡量。因此，這個測試使用循環(huán)調(diào)用相同的接口，然后得到平均的響應(yīng)時間。

4.3 測試結(jié)果及結(jié)果分析

Dubbo不同的通信協(xié)議和序列化方案相結(jié)合的結(jié)果見表1。而對應(yīng)于表1中使用測試方案的數(shù)字參見表2。表2中的結(jié)果是測試不同數(shù)據(jù)類型。所有測試結(jié)果時間單位為ms。

表1可以被切分成2部分。第一部分是前五個數(shù)字 a、b、c、d、e。 通信協(xié)議是 dubbo，但是序列化是不同的方案，與表2中的測試結(jié)果相比，可以從5種不同的序列化中分析得出利弊。另一部分是后面的3個字符f，g，h被設(shè)計為跨平臺通信，通過3種協(xié)議比較表2中的測試結(jié)果，由此可以推得結(jié)論，在跨平臺通信協(xié)議中是最好的。

表1 傳輸協(xié)議和序列化模式Tab.1 Transport protocol and serialization mode

在本文中，平均響應(yīng)時間是大于線上時間的［7］。不同的測試環(huán)境會導(dǎo)致測試結(jié)果出現(xiàn)一定的偏差，但在相同的環(huán)境中，根據(jù)測試結(jié)果的相對數(shù)據(jù)變化得出相應(yīng)的結(jié)論。

通過比較表 2中的 5組數(shù)據(jù) a、b、c、d、e。 與測試結(jié)果中的默認序列化協(xié)議hessian2相比，Dubbox擴展序列化協(xié)議kyro和fst的性能未見顯著提高。本次研究擴展的protostuff有突出的性能表現(xiàn)，針對此點，重點做了一些測試，結(jié)果都相差無幾，其運行機理原因還需要重新分析。比較表2中的f，g，h可知，f，g明顯具有更大的響應(yīng)耗時。f組使用的是HTTP+JSON的REST協(xié)議，過程中運用了文本序列化和應(yīng)用層HTTP作為傳輸協(xié)議。理論上講，f組性能是最差的，和測試結(jié)果一致。g組是Dubbo內(nèi)置的Thrift協(xié)議，雖然修改了原生的Thrift協(xié)議，但其結(jié)果性能表現(xiàn)卻并不理想。通過這3組測試結(jié)果，可以看到擴展的ThriftX在跨平臺通信和平均響應(yīng)時間方面更好，并且同時也顯示了Thrift原始生態(tài)協(xié)議的優(yōu)勢。

表2 不同類型數(shù)據(jù)測試結(jié)果Tab.2 Different types of data test results

5 結(jié)束語

在本文中，dubbo默認協(xié)議的分布式體系結(jié)構(gòu)是可擴展的，添加了一個新的序列化協(xié)議。測試并考查了新的序列化協(xié)議protostuff及其原始序列化協(xié)議的運行性能。通過測試結(jié)果，將protostuff與其它序列化協(xié)議進行比較分析可知，其在小數(shù)據(jù)傳輸方面具有一定的優(yōu)勢。另外，對于跨平臺通信優(yōu)化擴展的ThriftX協(xié)議，通過與dubbox的REST協(xié)議和dubbo原始Thrift協(xié)議的比較，ThriftX性能具有明顯的優(yōu)勢。

但是，本次研究也仍然存在一定不足，測試結(jié)果在平均響應(yīng)時間上一般來說偏大，究其原因可能在于測試環(huán)境，未來也需要有針對地加以改進解決。而考慮到本次測試中硬件資源有限，并未能真正涉足有關(guān)多線程測試的研究。而且除了擴展協(xié)議的穩(wěn)定性外，在其它方面也還需要進行后續(xù)設(shè)計上的優(yōu)化與完善。