一、背景介紹
由于歷史原因，使用了兄弟公司的框架，導致之前的通信序列化協議強制用的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上的博文