一、背景介绍
由于历史原因，使用了兄弟公司的框架，导致之前的通信序列化协议强制用的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上的博文