最近咱們公司內(nèi)部搞了個技術(shù)交流，討論起了序列化協(xié)議怎么選。我覺得這話題挺有意思的，就順手整理了一下現(xiàn)在主流的序列化協(xié)議的優(yōu)缺點。這樣一來，以后查起來也方便。

JSON

先說說 JSON，這貨讀起來挺舒服，用起來也簡單。擴展性和兼容性都不錯，能在不同語言之間傳來傳去結(jié)構(gòu)化數(shù)據(jù)。

但 JSON 也有缺點，比如體積大，影響性能，尤其是高并發(fā)的時候。還有就是缺乏命名空間，有時候信息會亂成一團。

總結(jié)起來，JSON 是個簡單通用的應(yīng)用協(xié)議，用得挺廣，開發(fā)效率挺高，但性能一般，維護成本也偏高。

Protobuf

接下來是 Protobuf，這貨是個高性能、易擴展的序列化框架。

優(yōu)點很明顯，跨語言，向后兼容，新增字段不影響已有的協(xié)議。代碼自動生成，用起來簡單。二進制消息，效率高，性能好。而且安全性也不錯，只寫字段號，編碼成二進制，破解難度大。

缺點嘛，二進制消息可讀性差，字段冗余，類文件會越來越大，維護成本高。而且 Protobuf 只管序列化和反序列化，RPC 功能得另請高明。

RPC 是啥？就是遠程過程調(diào)用，一個機器（客戶端）調(diào)用另一個機器（服務(wù)器）上的函數(shù)或方法，然后拿到結(jié)果。RPC 會隱藏底層通信細節(jié)，不用你直接處理 Socket 或 Http 通信，用起來就像調(diào)用本地函數(shù)一樣。

總結(jié) Protobuf，上手簡單，高效，兼容性強，但維護成本也高。

Thrift

Thrift 是 Facebook 2007年開發(fā)的跨語言 RPC 框架，支持多語言編譯，提供多種服務(wù)器工作模式。

優(yōu)點是序列化和 RPC 一站式解決，比 Protobuf 方便?？缯Z言，IDL 接口定義語言，自動生成多語言文件。省流量，體積小。包含完整的客戶端/服務(wù)端堆棧，RPC 實現(xiàn)起來快。服務(wù)端有多種工作模式，比如線程池、非阻塞模型。

缺點是不支持雙通道，RPC 方法非線程安全，服務(wù)器容易被掛死，需要串行化。默認不具備動態(tài)特性，開發(fā)環(huán)境和編譯有點麻煩。

總結(jié) Thrift，跨語言，實現(xiàn)簡單，但初次使用有點麻煩，得注意使用問題和場景限制。

MessagePack

MessagePack 是一種高效的二進制序列化格式。

優(yōu)點是跨語言，多語言支持。序列化反序列化效率高，文件體積小，比 JSON 小一倍，還兼容 JSON 數(shù)據(jù)格式。

缺點是缺乏復(fù)雜模型支持，對復(fù)雜數(shù)據(jù)類型（List、Map）支持不夠。序列化沒問題，但反序列化回來就麻煩了，尤其是對 Java 開發(fā)人員來說。維護成本也高，因為 MessagePack 通過值的順序來定位屬性，不同語言中都得維護一樣的模型和屬性順序。還不支持模型嵌套。

總結(jié) MessagePack，性能高，但擴展性差，維護成本高。

哦，對了，在整理的時候我還有點疑問。有人說 MessagePack 的序列化和反序列化效率是 Protobuf 的 4 倍，我個人表示懷疑。后續(xù)的文章可能會對這兩個協(xié)議做個細致的對比。

好了，今天的分享就到這兒，希望對你有幫助。有啥問題咱們再討論！