作者：沈理

文檔版權(quán)：?Apache 2.0許可證 署名-禁止演繹

完善中……

TODO 生成可點(diǎn)擊的目錄

目錄

• 序列化漫談
• 啟用Kryo和FST
• 注冊被序列化類
• 無參構(gòu)造函數(shù)和Serializable接口
• 序列化性能分析與測試
  • 測試環(huán)境
  • 測試腳本
  • Dubbo RPC中不同序列化生成字節(jié)大小比較
  • Dubbo RPC中不同序列化響應(yīng)時間和吞吐量對比
• 未來

序列化漫談

dubbo RPC是dubbo體系中最核心的一種高性能、高吞吐量的遠(yuǎn)程調(diào)用方式，我喜歡稱之為多路復(fù)用的TCP長連接調(diào)用，簡單的說：

• 長連接：避免了每次調(diào)用新建TCP連接，提高了調(diào)用的響應(yīng)速度
• 多路復(fù)用：單個TCP連接可交替?zhèn)鬏敹鄠€請求和響應(yīng)的消息，降低了連接的等待閑置時間，從而減少了同樣并發(fā)數(shù)下的網(wǎng)絡(luò)連接數(shù)，提高了系統(tǒng)吞吐量。

dubbo RPC主要用于兩個dubbo系統(tǒng)之間作遠(yuǎn)程調(diào)用，特別適合高并發(fā)、小數(shù)據(jù)的互聯(lián)網(wǎng)場景。

而序列化對于遠(yuǎn)程調(diào)用的響應(yīng)速度、吞吐量、網(wǎng)絡(luò)帶寬消耗等同樣也起著至關(guān)重要的作用，是我們提升分布式系統(tǒng)性能的最關(guān)鍵因素之一。

在dubbo RPC中，同時支持多種序列化方式，例如：

dubbo序列化：阿里尚未開發(fā)成熟的高效java序列化實(shí)現(xiàn)，阿里不建議在生產(chǎn)環(huán)境使用它

hessian2序列化：hessian是一種跨語言的高效二進(jìn)制序列化方式。但這里實(shí)際不是原生的hessian2序列化，而是阿里修改過的hessian lite，它是dubbo RPC默認(rèn)啟用的序列化方式

json序列化：目前有兩種實(shí)現(xiàn)，一種是采用的阿里的fastjson庫，另一種是采用dubbo中自己實(shí)現(xiàn)的簡單json庫，但其實(shí)現(xiàn)都不是特別成熟，而且json這種文本序列化性能一般不如上面兩種二進(jìn)制序列化。

java序列化：主要是采用JDK自帶的Java序列化實(shí)現(xiàn)，性能很不理想。

在通常情況下，這四種主要序列化方式的性能從上到下依次遞減。對于dubbo RPC這種追求高性能的遠(yuǎn)程調(diào)用方式來說，實(shí)際上只有1、2兩種高效序列化方式比較般配，而第1個dubbo序列化由于還不成熟，所以實(shí)際只剩下2可用，所以dubbo RPC默認(rèn)采用hessian2序列化。

但hessian是一個比較老的序列化實(shí)現(xiàn)了，而且它是跨語言的，所以不是單獨(dú)針對java進(jìn)行優(yōu)化的。而dubbo RPC實(shí)際上完全是一種Java to Java的遠(yuǎn)程調(diào)用，其實(shí)沒有必要采用跨語言的序列化方式（當(dāng)然肯定也不排斥跨語言的序列化）。

最近幾年，各種新的高效序列化方式層出不窮，不斷刷新序列化性能的上限，最典型的包括：

• 專門針對Java語言的：Kryo，FST等等
• 跨語言的：Protostuff，ProtoBuf，Thrift，Avro，MsgPack等等

這些序列化方式的性能多數(shù)都顯著優(yōu)于hessian2（甚至包括尚未成熟的dubbo序列化）。

有鑒于此，我們?yōu)閐ubbo引入Kryo和FST這兩種高效Java序列化實(shí)現(xiàn)，來逐步取代hessian2。

其中，Kryo是一種非常成熟的序列化實(shí)現(xiàn)，已經(jīng)在Twitter、Groupon、Yahoo以及多個著名開源項(xiàng)目（如Hive、Storm）中廣泛的使用。而FST是一種較新的序列化實(shí)現(xiàn)，目前還缺乏足夠多的成熟使用案例，但我認(rèn)為它還是非常有前途的。

在面向生產(chǎn)環(huán)境的應(yīng)用中，我建議目前更優(yōu)先選擇Kryo。

啟用Kryo和FST

使用Kryo和FST非常簡單，只需要在dubbo RPC的XML配置中添加一個屬性即可：

<dubbo:protocol name="dubbo" serialization="kryo"/> <dubbo:protocol name="dubbo" serialization="fst"/>

注冊被序列化類

要讓Kryo和FST完全發(fā)揮出高性能，最好將那些需要被序列化的類注冊到dubbo系統(tǒng)中，例如，我們可以實(shí)現(xiàn)如下回調(diào)接口：

public class SerializationOptimizerImpl implements SerializationOptimizer {public Collection<Class> getSerializableClasses() {List<Class> classes = new LinkedList<Class>();classes.add(BidRequest.class);classes.add(BidResponse.class);classes.add(Device.class);classes.add(Geo.class);classes.add(Impression.class);classes.add(SeatBid.class);return classes;} }

然后在XML配置中添加：

<dubbo:protocol name="dubbo" serialization="kryo" optimizer="com.alibaba.dubbo.demo.SerializationOptimizerImpl"/>

在注冊這些類后，序列化的性能可能被大大提升，特別針對小數(shù)量的嵌套對象的時候。

當(dāng)然，在對一個類做序列化的時候，可能還級聯(lián)引用到很多類，比如Java集合類。針對這種情況，我們已經(jīng)自動將JDK中的常用類進(jìn)行了注冊，所以你不需要重復(fù)注冊它們（當(dāng)然你重復(fù)注冊了也沒有任何影響），包括：

GregorianCalendar InvocationHandler BigDecimal BigInteger Pattern BitSet URI UUID HashMap ArrayList LinkedList HashSet TreeSet Hashtable Date Calendar ConcurrentHashMap SimpleDateFormat Vector BitSet StringBuffer StringBuilder Object Object[] String[] byte[] char[] int[] float[] double[]

由于注冊被序列化的類僅僅是出于性能優(yōu)化的目的，所以即使你忘記注冊某些類也沒有關(guān)系。事實(shí)上，即使不注冊任何類，Kryo和FST的性能依然普遍優(yōu)于hessian和dubbo序列化。

當(dāng)然，有人可能會問為什么不用配置文件來注冊這些類？這是因?yàn)橐缘念愅鶖?shù)量較多，導(dǎo)致配置文件冗長；而且在沒有好的IDE支持的情況下，配置文件的編寫和重構(gòu)都比java類麻煩得多；最后，這些注冊的類一般是不需要在項(xiàng)目編譯打包后還需要做動態(tài)修改的。

另外，有人也會覺得手工注冊被序列化的類是一種相對繁瑣的工作，是不是可以用annotation來標(biāo)注，然后系統(tǒng)來自動發(fā)現(xiàn)并注冊。但這里annotation的局限是，它只能用來標(biāo)注你可以修改的類，而很多序列化中引用的類很可能是你沒法做修改的（比如第三方庫或者JDK系統(tǒng)類或者其他項(xiàng)目的類）。另外，添加annotation畢竟稍微的“污染”了一下代碼，使應(yīng)用代碼對框架增加了一點(diǎn)點(diǎn)的依賴性。

除了annotation，我們還可以考慮用其它方式來自動注冊被序列化的類，例如掃描類路徑，自動發(fā)現(xiàn)實(shí)現(xiàn)Serializable接口（甚至包括Externalizable）的類并將它們注冊。當(dāng)然，我們知道類路徑上能找到Serializable類可能是非常多的，所以也可以考慮用package前綴之類來一定程度限定掃描范圍。

當(dāng)然，在自動注冊機(jī)制中，特別需要考慮如何保證服務(wù)提供端和消費(fèi)端都以同樣的順序（或者ID）來注冊類，避免錯位，畢竟兩端可被發(fā)現(xiàn)然后注冊的類的數(shù)量可能都是不一樣的。

無參構(gòu)造函數(shù)和Serializable接口

如果被序列化的類中不包含無參的構(gòu)造函數(shù)，則在Kryo的序列化中，性能將會大打折扣，因?yàn)榇藭r我們在底層將用Java的序列化來透明的取代Kryo序列化。所以，盡可能為每一個被序列化的類添加無參構(gòu)造函數(shù)是一種最佳實(shí)踐（當(dāng)然一個java類如果不自定義構(gòu)造函數(shù)，默認(rèn)就有無參構(gòu)造函數(shù)）。

另外，Kryo和FST本來都不需要被序列化都類實(shí)現(xiàn)Serializable接口，但我們還是建議每個被序列化類都去實(shí)現(xiàn)它，因?yàn)檫@樣可以保持和Java序列化以及dubbo序列化的兼容性，另外也使我們未來采用上述某些自動注冊機(jī)制帶來可能。

序列化性能分析與測試

本文我們主要討論的是序列化，但在做性能分析和測試的時候我們并不單獨(dú)處理每種序列化方式，而是把它們放到dubbo RPC中加以對比，因?yàn)檫@樣更有現(xiàn)實(shí)意義。

測試環(huán)境

粗略如下：

• 兩臺獨(dú)立服務(wù)器
• 4核Intel(R) Xeon(R) CPU E5-2603 0 @ 1.80GHz
• 8G內(nèi)存
• 虛擬機(jī)之間網(wǎng)絡(luò)通過百兆交換機(jī)
• CentOS 5
• JDK 7
• Tomcat 7
• JVM參數(shù)-server -Xms1g -Xmx1g -XX:PermSize=64M -XX:+UseConcMarkSweepGC

當(dāng)然這個測試環(huán)境較有局限，故當(dāng)前測試結(jié)果未必有非常權(quán)威的代表性。

測試腳本

和dubbo自身的基準(zhǔn)測試保持接近：

10個并發(fā)客戶端持續(xù)不斷發(fā)出請求：

• 傳入嵌套復(fù)雜對象（但單個數(shù)據(jù)量很小），不做任何處理，原樣返回
• 傳入50K字符串，不做任何處理，原樣返回（TODO：結(jié)果尚未列出）

進(jìn)行5分鐘性能測試。（引用dubbo自身測試的考慮：“主要考察序列化和網(wǎng)絡(luò)IO的性能，因此服務(wù)端無任何業(yè)務(wù)邏輯。取10并發(fā)是考慮到http協(xié)議在高并發(fā)下對CPU的使用率較高可能會先打到瓶頸。”）

Dubbo RPC中不同序列化生成字節(jié)大小比較

序列化生成字節(jié)碼的大小是一個比較有確定性的指標(biāo)，它決定了遠(yuǎn)程調(diào)用的網(wǎng)絡(luò)傳輸時間和帶寬占用。

針對復(fù)雜對象的結(jié)果如下（數(shù)值越小越好）：

序列化實(shí)現(xiàn)請求字節(jié)數(shù)響應(yīng)字節(jié)數(shù)

Kryo	272	90
FST	288	96
Dubbo Serialization	430	186
Hessian	546	329
FastJson	461	218
Json	657	409
Java Serialization	963	630

Dubbo RPC中不同序列化響應(yīng)時間和吞吐量對比

遠(yuǎn)程調(diào)用方式平均響應(yīng)時間平均TPS（每秒事務(wù)數(shù)）

REST: Jetty + JSON	7.806	1280
REST: Jetty + JSON + GZIP	TODO	TODO
REST: Jetty + XML	TODO	TODO
REST: Jetty + XML + GZIP	TODO	TODO
REST: Tomcat + JSON	2.082	4796
REST: Netty + JSON	2.182	4576
Dubbo: FST	1.211	8244
Dubbo: kyro	1.182	8444
Dubbo: dubbo serialization	1.43	6982
Dubbo: hessian2	1.49	6701
Dubbo: fastjson	1.572	6352

測試總結(jié)

就目前結(jié)果而言，我們可以看到不管從生成字節(jié)的大小，還是平均響應(yīng)時間和平均TPS，Kryo和FST相比Dubbo RPC中原有的序列化方式都有非常顯著的改進(jìn)。

未來

未來，當(dāng)Kryo或者FST在dubbo中當(dāng)應(yīng)用足夠成熟之后，我們很可能會將dubbo RPC的默認(rèn)序列化從hessian2改為它們中間的某一個。

總結(jié)

以上是生活随笔為你收集整理的在Dubbo中使用高效的Java序列化（Kryo和FST）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。