Sheppard Y

keep thinking keep coding.

网络通信序列化协议的选择

2016-07-03 日更新 
此篇博客已经迁移到新博客,并做行文检查和优化排版:
http://blog.clawz.me/2012/09/21/12-chose-protobuf/

 



一、背景介绍

    由于历史原因,使用了兄弟公司的框架,导致之前的通信序列化协议强制用的JSON。我们项目为一个web项目,前端as,后端php+java,一开始只有as与php短连接,后来为了一些逻辑的实时消息,加了java来另作的长连接。

    as与php都是弱类型的语言,用JSON来序列化,网络通信逻辑可以写的很随意,这导致我们现在查问题非常棘手。另外JSON也浪费了些流量。现在项目在扩展手机前端,对流量的要求更苛刻。为了新老问题的选择,我们就要换掉JSON。

 

二、序列化协议选择的考虑

    手机前端使用C++写的逻辑,我们协议的要求为跨语言、跨平台、体积小、序列化和反序列化快。

    可供选择的协议有protobuf/thrift/messagepack等。

1. thrift的学习成本貌似比protobuf高些,另外先看的protobuf,感觉两种协议差不多,就懒的继续研究thrift了。

2. protobuf和messagepack的取舍:

    两种皆是开源项目。

(1)protobuf是google主持的,已经被google自己和业内大规模使用了,证明是可靠的;而messagepack貌似出来的比较晚,还没被大规模使用。

(2)语言支持,protobuf官方原生支持C++、Java、python,其他均为第三方扩展;messagepack官方支持C++、Java、php,不支持as,但支持js。

(3)protobuf有个编译器可以自动生成各语言对应版本的协议类;messagepack在强类型如java和C++里就需要自己写各个语言版本的了。

(4)体积方面,messagepack的体积应该比protobuf稍大。

(5)速度方面,messagepack官方说速度是protobuf的4倍,但是看他的测试只是一种语言的序列化测试。

(6)其他,messagepack也支持key-value方式的序列化,号称体积小的JSON。这虽很容易移植以前的协议,为了快速出demo,我也都准备用messagepack先期试改了,但是猛然发现每个语言还是得写各自的,而且现在涉及到两种不同前端,一段的修改还需及时通知另一前端做相应修改。这种太难控制了,没有protobuf的proto文件那种的一致性保证。

 

三、最终选择

    综合以上的比较,最后选择了protobuf来作为我们项目新的网络通信序列化协议。

ps:2012年9月21日我在CU上的博文

posted on 2013-04-08 17:56 Sheppard Y 阅读(1305) 评论(0)  编辑 收藏 引用 所属分类: 设计架构


只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理


<2013年4月>
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011

导航

统计

留言簿(1)

随笔分类(77)

随笔档案(58)

me

基友

同行

业界前辈

最新随笔

搜索

积分与排名

最新评论

阅读排行榜