The post is brought to you by lekhonee v0.7
糖果項目的后端用Java編寫(xiě)，我負責service gateway的開(kāi)發(fā)（暫且叫sergent），服務(wù)以Java接口+Annotation的形式聲明，與Spring集成使用，Java對象被序列化為JSON和XML（通過(guò)jackson和castor）與外部系統交互。專(zhuān)門(mén)的JSON Schema和XML Schema是可選的，系統交互通過(guò)簡(jiǎn)明的文檔和人工確認。
RPC框架是跨進(jìn)程、跨系統交互的重要工具，RPC框架中又包括遠程調用、網(wǎng)絡(luò )傳輸和序列化反序列化等等部分。流行的工具包括Facebook的thrift，Google的Protobuf和原先Hadoop項目下的avro。其中thrift包含遠程調用、反序列化、網(wǎng)絡(luò )等等全部的功能。Protobuf本身是一個(gè)序列化反序列化庫，另有很多第三方RPC實(shí)現，avro目前除了序列化和反序列化的功能，也包含了ipc的HTTP Server和SocketServer等實(shí)現。在序列化的格式方面，Thrift支持JSON和二進(jìn)制協(xié)議，Protobuf本身僅有二進(jìn)制支持，但已經(jīng)存在第三方的其他格式實(shí)現。 avro原生支持二進(jìn)制和JSON格式。
從效率上來(lái)說(shuō)，二進(jìn)制方式的序列化要比文本方式的快。Google Code上（最近遷往了github）有一個(gè)tpc項目（thrift-protobuf-compare），根據這個(gè)項目的最新的比較結果（與原先不同）：
protobuf成為了三者中耗時(shí)最少的框架，之后是thrift和avro，這次avro的耗時(shí)甚至超過(guò)了文本方式的jackson（主要在反序列化上）。
但是二進(jìn)制協(xié)議通常都需要定義Schema，thrift / protobuf / avro三者各自定義了Schema的格式，沒(méi)有類(lèi)似XSD和JsonSchema的統一標準，也就是說(shuō)，當你需要傳輸一個(gè)對象，就要為它編寫(xiě)一個(gè)Schema文件。按照通常的習慣，都是先編寫(xiě)Schema，然后通過(guò)命令行工具或者自動(dòng)構建工具來(lái)生成Java source。對于新系統還好說(shuō)，對舊系統這個(gè)改造就比較麻煩了。另外，二進(jìn)制協(xié)議不便于調試，所以各個(gè)thrift/protobuf/avro先后也都有JSON的實(shí)現，在文本的序列化格式上，JSON對XML的優(yōu)勢是全方位的。
所以綜合起來(lái)，很難說(shuō)有一種完美的解決方案。二進(jìn)制協(xié)議的效率高，但是改造、編寫(xiě)Schema的代價(jià)并不小，還要面對核心Model被綁架到具體框架的風(fēng)險。文本協(xié)議開(kāi)發(fā)簡(jiǎn)便，不需要Schema，直接POJO就可以序列化和反序列化，但是在時(shí)間和空間上都不如二進(jìn)制的方式。
補充
從tpc項目的結果上看，kryo在時(shí)間、空間上都擊敗了所有對手，而且，kryo的API非常簡(jiǎn)潔，不需要Schema文件就可以序列化POJO，聽(tīng)起來(lái)太完美了，看來(lái)以后sergent要借鑒一下的。
This content is published under the Attribution-Noncommercial-Share Alike 3.0 Unported license.
聯(lián)系客服
