深入理解RPC框架的序列化方案
1 為什么需要序列化?
網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)須是二進(jìn)制數(shù)據(jù),但調(diào)用方請(qǐng)求的出入?yún)?shù)都是對(duì)象:
- ? 對(duì)象不能直接在網(wǎng)絡(luò)傳輸,需提前轉(zhuǎn)成可傳輸?shù)亩M(jìn)制,且要求可逆,即“序列化”將對(duì)象轉(zhuǎn)換成二進(jìn)制數(shù)據(jù)
- ? 這時(shí),服務(wù)提供方就能正確從二進(jìn)制數(shù)據(jù)中分割出不同請(qǐng)求,同時(shí)根據(jù)請(qǐng)求類型和序列化類型,把二進(jìn)制的消息體逆向還原成請(qǐng)求對(duì)象,即“反序列化”將二進(jìn)制轉(zhuǎn)換為對(duì)象
序列化與反序列化
RPC框架為何需要序列化?
回想RPC通信流程:
RPC通信流程圖
2 序列化方式
2.1 JDK原生序列化
案例:
- ? 序列化具體由ObjectOutputStream完成
- ? 反序列化的具體實(shí)現(xiàn)是由ObjectInputStream完成
JDK序列化過程:
ObjectOutputStream序列化過程圖
序列化過程就是在讀取對(duì)象數(shù)據(jù)的時(shí)候,不斷加入一些特殊分隔符,這些特殊分隔符用于在反序列化過程中截?cái)嘤谩?/p>
- ? 頭部數(shù)據(jù),聲明序列化協(xié)議、序列化版本,用于高低版本向后兼容
- ? 對(duì)象數(shù)據(jù)主要包括類名、簽名、屬性名、屬性類型及屬性值,當(dāng)然還有開頭結(jié)尾等數(shù)據(jù),除了屬性值屬于真正的對(duì)象值,其他都是為了反序列化用的元數(shù)據(jù)
- ? 存在對(duì)象引用、繼承的情況下,就是遞歸遍歷“寫對(duì)象”邏輯
將對(duì)象的類型、屬性類型、屬性值按固定格式寫到二進(jìn)制字節(jié)流中來完成序列化,再按固定格式讀出對(duì)象的類型、屬性類型、屬性值,通過這些信息重建一個(gè)新的對(duì)象,完成反序列化。
2.2 JSON
典型KV方式,沒有數(shù)據(jù)類型,是一種文本型序列化框架。
- ? JSON進(jìn)行序列化的額外空間開銷較大
- ? JSON沒有類型,但像Java這種強(qiáng)類型語言,需通過反射統(tǒng)一解決,性能不太好
所以如果RPC框架選用JSON序列化,服務(wù)提供者與服務(wù)調(diào)用者之間傳輸?shù)臄?shù)據(jù)量要相對(duì)較小。
2.3 Hessian
動(dòng)態(tài)類型、二進(jìn)制、緊湊的,并且可跨語言移植的一種序列化框架。比JDK、JSON更加緊湊,性能上要比JDK、JSON序列化高效很多,而且生成的字節(jié)數(shù)更小。
使用代碼示例如下:
相對(duì)于JDK、JSON,由于Hessian更加高效,生成的字節(jié)數(shù)更小,有非常好的兼容性和穩(wěn)定性,所以Hessian更加適合作為RPC框架遠(yuǎn)程通信的序列化協(xié)議。
但Hessian本身也有問題,官方版本對(duì)Java里面一些常見對(duì)象的類型不支持,比如:
- Linked系列,LinkedHashMap、LinkedHashSet等,但是可以通過擴(kuò)展CollectionDeserializer類修復(fù)
- Locale類,可以通過擴(kuò)展ContextSerializerFactory類修復(fù)
- Byte/Short反序列化的時(shí)候變成Integer
2.4 Protobuf
Protobuf 是 Google 公司內(nèi)部的混合語言數(shù)據(jù)標(biāo)準(zhǔn),是一種輕便、高效的結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)格式,可以用于結(jié)構(gòu)化數(shù)據(jù)序列化,支持Java、Python、C++、Go等語言。Protobuf使用的時(shí)候需要定義IDL(Interface description language),然后使用不同語言的IDL編譯器,生成序列化工具類,它的優(yōu)點(diǎn)是:
- 序列化后體積相比 JSON、Hessian小很多;
- IDL能清晰地描述語義,所以足以幫助并保證應(yīng)用程序之間的類型不會(huì)丟失,無需類似 XML 解析器;
- 序列化反序列化速度很快,不需要通過反射獲取類型;
- 消息格式升級(jí)和兼容性不錯(cuò),可以做到向后兼容。
使用代碼示例如下:
Protobuf 非常高效,但是對(duì)于具有反射和動(dòng)態(tài)能力的語言來說,這樣用起來很費(fèi)勁,這一點(diǎn)就不如Hessian,比如用Java的話,這個(gè)預(yù)編譯過程不是必須的,可以考慮使用Protostuff。
Protostuff不需要依賴IDL文件,可以直接對(duì)Java領(lǐng)域?qū)ο筮M(jìn)行反/序列化操作,在效率上跟Protobuf差不多,生成的二進(jìn)制格式和Protobuf是完全相同的,可以說是一個(gè)Java版本的Protobuf序列化框架。但在使用過程中,我遇到過一些不支持的情況,也同步給你:
- ? 不支持null;
- ? ProtoStuff不支持單純的Map、List集合對(duì)象,需要包在對(duì)象里面。
3 RPC序列化選型
3.1 性能和效率
3.2 空間開銷
即序列化之后的二進(jìn)制數(shù)據(jù)的體積大小。序列化后的字節(jié)數(shù)據(jù)體積越小,網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量就越小,傳輸數(shù)據(jù)的速度也就越快,由于RPC是遠(yuǎn)程調(diào)用,那么網(wǎng)絡(luò)傳輸?shù)乃俣葘⒅苯雨P(guān)系到請(qǐng)求響應(yīng)的耗時(shí)。
3.3 通用性和兼容性
某類型為集合類的入?yún)⒎?wù)調(diào)用者不能解析了,服務(wù)提供方將入?yún)㈩惣右粋€(gè)屬性之后服務(wù)調(diào)用方不能正常調(diào)用,升級(jí)了RPC版本后發(fā)起調(diào)用時(shí)報(bào)序列化異常…
通用性和兼容性的優(yōu)先級(jí)考慮很高,直接關(guān)系到服務(wù)調(diào)用穩(wěn)定性和可用率??粗剡@種序列化協(xié)議在版本升級(jí)后的兼容性,是否支持更多的對(duì)象類型,是否跨平臺(tái)、跨語言,是否有很多人已用過并踩過很多坑,其次考慮性能、效率和空間開銷。
3.4 安全性
JDK原生序列化存在漏洞。如果序列化存在安全漏洞,線上服務(wù)可能被入侵:
首選Hessian與Protobuf,性能、時(shí)間開銷、空間開銷、通用性、兼容性和安全性上,都滿足要求:
- ? Hessian使用更方便,在對(duì)象的兼容性上更好
- ? Protobuf則更加高效,更通用
4 FAQ
4.1 對(duì)象構(gòu)造得太復(fù)雜
屬性很多,并且存在多層的嵌套,比如A對(duì)象關(guān)聯(lián)B對(duì)象,B對(duì)象又聚合C對(duì)象,C對(duì)象又關(guān)聯(lián)聚合很多其他對(duì)象,對(duì)象依賴關(guān)系過于復(fù)雜。
序列化框架在序列化與反序列化對(duì)象時(shí),對(duì)象越復(fù)雜就越浪費(fèi)性能,消耗CPU,這會(huì)嚴(yán)重影響RPC框架整體的性能。
4.2 對(duì)象太龐大
RPC請(qǐng)求經(jīng)常超時(shí),排查后發(fā)現(xiàn)他們的入?yún)?duì)象非常得大,比如為一個(gè)大List或者大Map,序列化之后字節(jié)長(zhǎng)度達(dá)到了上兆字節(jié)。這種情況同樣會(huì)嚴(yán)重地浪費(fèi)性能、CPU,并且序列化一個(gè)如此大的對(duì)象是很耗費(fèi)時(shí)間的,這肯定會(huì)直接影響到請(qǐng)求耗時(shí)。
4.3 使用序列化框架不支持的類作為入?yún)㈩?/h3>
如Hessian天然不支持LinkHashMap、LinkedHashSet等,而且大多數(shù)情況下最好不要使用第三方集合類,如Guava中的集合類,很多開源的序列化框架都是優(yōu)先支持編程語言原生的對(duì)象。因此如果入?yún)⑹羌项?,?yīng)盡量選用原生的、最為常用的集合類,如HashMap、ArrayList。
4.4 對(duì)象有復(fù)雜繼承關(guān)系
序列化對(duì)象時(shí)會(huì)將對(duì)象屬性一一序列化,當(dāng)有繼承關(guān)系時(shí),會(huì)不停尋找父類,遍歷屬性。就像問題1,對(duì)象關(guān)系越復(fù)雜,越浪費(fèi)性能。
在RPC框架的使用過程中,盡量構(gòu)建簡(jiǎn)單的對(duì)象作為入?yún)⒑头祷刂祵?duì)象,避免上述問題。
5 總結(jié)
使用RPC框架的過程中,我們構(gòu)造入?yún)?、返回值?duì)象,主要記住以下幾點(diǎn):
- 1. 對(duì)象要盡量簡(jiǎn)單,沒有太多的依賴關(guān)系,屬性不要太多,盡量高內(nèi)聚;
- 2. 入?yún)?duì)象與返回值對(duì)象體積不要太大,更不要傳太大的集合;
- 3. 盡量使用簡(jiǎn)單的、常用的、開發(fā)語言原生的對(duì)象,尤其是集合類;
- 4. 對(duì)象不要有復(fù)雜的繼承關(guān)系,最好不要有父子類的情況。
實(shí)際上,雖然RPC框架可以讓我們發(fā)起遠(yuǎn)程調(diào)用就像調(diào)用本地一樣,但在RPC框架的傳輸過程中,入?yún)⑴c返回值的根本作用就是用來傳遞信息的,為了提高RPC調(diào)用整體的性能和穩(wěn)定性,我們的入?yún)⑴c返回值對(duì)象要構(gòu)造得盡量簡(jiǎn)單。
6 FAQ
RPC框架在序列化框架的選型上,你認(rèn)為還需要考慮哪些因素?你還知道哪些優(yōu)秀的序列化框架,它們又是否適合在RPC調(diào)用中使用?
序列化一般用在協(xié)議里面的payload里。
Redis使用的RESP,在做序列化時(shí)也是會(huì)增加很多冗余的字符,但它勝在實(shí)現(xiàn)簡(jiǎn)單、可讀性強(qiáng)易于理解。
JSON和XML使用字符串表示所有的數(shù)據(jù),對(duì)于非字符數(shù)據(jù)來說,字面量表達(dá)會(huì)占用很多額外的存儲(chǔ)空間,并且會(huì)嚴(yán)重受到數(shù)值大小和精度的影響。一個(gè)32位浮點(diǎn)數(shù) 1234.5678 在內(nèi)存中占用 4 bytes 空間,如果存儲(chǔ)為 utf8 ,則需要占用 9 bytes空間,在JS這樣使用utf16表達(dá)字符串的環(huán)境中,需要占用 18 bytes空間。使用正則表達(dá)式進(jìn)行數(shù)據(jù)解析,在面對(duì)非字符數(shù)據(jù)時(shí)顯得十分低效,不僅要耗費(fèi)大量的運(yùn)算解析數(shù)據(jù)結(jié)構(gòu),還要將字面量轉(zhuǎn)換成對(duì)應(yīng)的數(shù)據(jù)類型。
在面對(duì)海量數(shù)據(jù)時(shí),這種格式本身就能夠成為整個(gè)系統(tǒng)的IO與計(jì)算瓶頸,甚至直接overflow。
常見的序列化協(xié)議有:xml json protobuf jdk等 xml和json可讀性好,序列化后空間大,性能差,而且json序列化后無類型,需要反射獲取對(duì)象類型。而protobuf則是可讀性差點(diǎn),序列化后占用空間小,性能好,不需要反序列化獲取屬性類型等優(yōu)點(diǎn)。對(duì)性能要求高的原則protobuf比較好點(diǎn)
為什么JSON的額外開銷大呢?是因?yàn)榇嬖诖罅康膿Q行嗎
最明顯的就是你說的數(shù)據(jù)包大,因?yàn)樽址鄬?duì)二進(jìn)制更占空間。
json需要內(nèi)存去解析能理解,但為什么json序列化還需要磁盤開銷啊。json序列化的二進(jìn)制數(shù)據(jù)在體量比其他序列化方法小一些吧,可以減少帶寬和流量?
說的如果json數(shù)據(jù)存儲(chǔ)在磁盤上,json字節(jié)數(shù)相對(duì)其他數(shù)據(jù)都偏大。