您好,登錄后才能下訂單哦!
1 簡單易用開發成本低
2 跨語言
3 輕量級數據交換
4 非冗長性(對比xml標簽簡單括號閉環)
1 體積大,影響高并發
2 無版本檢查,自己做兼容
3 片段的創建和驗證過程比一般的XML復雜
4 缺乏命名空間導致信息混合
總結:最簡單最通用的應用協議,使用廣泛,開發效率高,性能相對較低,維護成本較高。
Protobuf是一種以有效并可擴展的格式編碼結構化數據的方式。
1 跨語言,可自定義數據結構。
2 字段被編號,新添加的字段不影響老結構。解決了向后兼容問題。
3 自動化生成代碼,簡單易用。
4 二進制消息,效率高,性能高。
5 Netty等框架集成了該協議,提供了編×××提高開發效率。
1 二進制格式,可讀性差(抓包dump后的數據很難看懂)
2 對象冗余,字段很多,生成的類較大,占用空間。
3 默認不具備動態特性(可以通過動態定義生成消息類型或者動態編譯支持)
總結:簡單快速上手,高效兼容性強,維護成本較高。
官網和指南
https://developers.google.com/protocol-buffers/
github
https://github.com/protocolbuffers/protobuf
netty 對 protobuf 協議的解碼與包裝探究
https://www.cnblogs.com/tankaixiong/p/6366043.html
protobuf開發原則和缺陷詳解
https://my.oschina.net/cxh4905?tab=newest&catalogId=387288
1 序列化和RPC支持一站式解決,比pb更方便
2 跨語言,IDL接口定義語言,自動生成多語言文件
3 省流量,體積較小
4 包含完整的客戶端/服務端堆棧,可快速實現RPC
5 為服務端提供了多種工作模式,如線程池模型、非阻塞模型
1 早期版本問題較大,0.7以前有兼容性問題
2 不支持雙通道
3 rpc方法非線程安全,服務器容易被掛死,需要串行化。
4 默認不具備動態特性(可以通過動態定義生成消息類型或者動態編譯支持)
5 開發環境、編譯較麻煩
總結:跨語言、實現簡單,初次使用較麻煩,需要避免使用問題和場景限制。
Thrift: The Missing Guide
https://diwakergupta.github.io/thrift-missing-guide/
和 Thrift 的一場美麗邂逅
https://www.cnblogs.com/cyfonly/p/6059374.html
由淺入深了解Thrift(一)——Thrift介紹與用法
https://blog.csdn.net/houjixin/article/details/42778335
1 跨語言,多語言支持(超多)
2 It’s like JSON.but fast and small.序列化反序列化效率高(比json快一倍),文件體積小,比json小一倍。
3 兼容json數據格式
1.缺乏復雜模型支持。msgpack對復雜的數據類型(List、Map)支持的不夠,序列化沒有問題,但是反序列化回來就很麻煩,尤其是對于java開發人員。
2.維護成本較高。msgpack通過value的順序來定位屬性的,需要在不同的語言中都要維護同樣的模型以及模型中屬性的順序。
3.不支持模型嵌套。msgpack無法支持在模型中包含和嵌套其他自定義的模型(如weibo模型中包含comment的列表)。
總結:高性能但擴展性較差維護成本較高。
官網
https://msgpack.org/
msgpack-java
https://github.com/msgpack/msgpack-java
MessagePack for C#譯文
https://www.cnblogs.com/stulzq/p/8039933.html
原理分析和使用
https://www.jianshu.com/p/8c24bef40e2f
code
https://www.programcreek.com/java-api-examples/?api=org.msgpack.MessagePack
序列化時間對比
序列化大小對比
go語言序列化性能比較
https://github.com/smallnest/gosercomp
各種 Java 的序列化庫的性能比較測試結果
http://developer.51cto.com/art/201506/480273.htm
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。