标签:多协议 工作模式 多语言 like example 验证 复杂 一站式 png
主流序列化协议优缺点和网站推荐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/cxh3905?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
标签:多协议 工作模式 多语言 like example 验证 复杂 一站式 png
原文地址:http://blog.51cto.com/13952501/2173038