以往在跨不同程式語言的系統之間，會使用 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
沒有留言:
張貼留言