以往在跨不同程式語言的系統之間,會使用 SOAP(Web Service), XML 或是 JSON,但這幾個方案目前目前大都是用在網頁上。thrift, protobuf, avro 是三種跨語言通信方案,在不同程式語言之間,資料必須要以有效率的方式,序列化後,再進行傳輸,到另一端反序列化。另外 thrift 及 avro 還將傳輸機制內建在函式庫中,可在不同程式語言環境之間,進行 RPC 遠端呼叫。
thrift, protobuf, avro 簡述
Google Protocol Buffers 是一種序列化與結構化數據的一種機制,具有跨平台、解析速度快、序列化數據體積小、擴展性高、使用簡單的特點。
Apache thrift 是由 Facebook 主導開發的一個跨平台、支持多語言的,通過定義 IDL 文件,自動生成 RPC 客戶端與服務端通信代碼的工具,可產生在 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml 這些語言之間互相傳遞資料的使用程式碼。其中一方是 Server,另一端是 client。
Apache Avro 是一個二進制的數據序列化系統。實際上 Avro 除了序列化之外,也提供了 RPC 功能。 Avro 是屬於 Hadoop的一個子項目,由 Hadoop 的 創始人 Doug Cutting 開始開發,用於支援大量數據交換的應用,依賴 Schema 來實現資料結構定義,Schema 是以JSON 對象來表示, Avro 也被作為一種 RPC 框架來使用。客戶端希望同服務器端交互時,就需要交換雙方通信的協議,它類似於模式,需要雙方來定義,在 Avro中被稱為Message。
thrift avro protobuf 的優缺點比較
一般認定,protobuf 因為不包含 RPC 的部分,如果單純要對資料進行傳輸前的序列化或是接收後的反序列化,不管是序列化速度跟資料大小,都是最佳選擇。
如果要在不同的程式語言之間進行 RPC 呼叫,那麼 avro 的性能及效率,會是比 thrift 還好的選擇,但因為 avro 官方支援的程式語言比較少一點,如果以涵蓋的程式語言範圍來看,就要選用 thrift。
thrift
優點
支持非常多的語言 (C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml)
thrift文件生成目標代碼,簡單易用
消息定義文件支持註釋
數據結構與傳輸實作分離,支援多種消息格式
包含完整的客戶端/服務端stack,可快速實現RPC
支援 同步 和 異步 兩種通信方式
缺點
不支援動態特性
avro
優點
binary 消息,性能好/效率高
使用JSON描述模式(schema)
schema 和 資料 統一存儲,消息自描述,不需要生成stub代碼(支持生成IDL)
RPC調用在握手階段交換模式定義
包含完整的客戶端/服務端 stack,可快速實現RPC
支援 同步 和 異步 通信
支援 動態 消息
模式定義允許定義數據的排序(序列化時會遵循這個順序)
提供了基於Jetty內核的服務基於Netty的服務
缺點
只支援 Avro 自己的序列化格式
語言綁定(python, java, C, C++, C#) 不如Thrift豐富
protobuf
優點
binary 消息,性能好/效率高(空間和時間效率都很不錯)
proto 文件生成目標代碼,簡單易用
序列化反序列化直接對應程序中的數據類別,不需要解析後再進行映射(XML,JSON都是這種方式)
支援向前相容(新加字段採用默認值)和向後相容(忽略新加字段),簡化升級
支援多種語言(類似IDL文件)
缺點
官方只支援 C++, JAVA 和 Python 語言
binary 可讀性差
binary 不具有自描述特性
不具備動態特性(可以通過動態定義生成消息類型或者動態編譯支持)
只有序列化和反序列化技術,沒有RPC功能
References
跨語言通信方案比較——thrift、protobuf和avro
三種通用應用層協議protobuf、thrift、avro對比,完爆xml,json,http
Thrift、protocolbuffer、avro這幾種序列化之間的比較
沒有留言:
張貼留言