一、背景介紹
由于歷史原因，使用了兄弟公司的框架，導(dǎo)致之前的通信序列化協(xié)議強(qiáng)制用的JSON。我們項(xiàng)目為一個(gè)web項(xiàng)目，前端as，后端php+java，一開始只有as與php短連接，后來(lái)為了一些邏輯的實(shí)時(shí)消息，加了java來(lái)另作的長(zhǎng)連接。
as與php都是弱類型的語(yǔ)言，用JSON來(lái)序列化，網(wǎng)絡(luò)通信邏輯可以寫的很隨意，這導(dǎo)致我們現(xiàn)在查問題非常棘手。另外JSON也浪費(fèi)了些流量。現(xiàn)在項(xiàng)目在擴(kuò)展手機(jī)前端，對(duì)流量的要求更苛刻。為了新老問題的選擇，我們就要換掉JSON。
二、序列化協(xié)議選擇的考慮
手機(jī)前端使用C++寫的邏輯，我們協(xié)議的要求為跨語(yǔ)言、跨平臺(tái)、體積小、序列化和反序列化快。
可供選擇的協(xié)議有protobuf/thrift/messagepack等。
1. thrift的學(xué)習(xí)成本貌似比protobuf高些，另外先看的protobuf，感覺兩種協(xié)議差不多，就懶的繼續(xù)研究thrift了。
2. protobuf和messagepack的取舍：
兩種皆是開源項(xiàng)目。
（1）protobuf是google主持的，已經(jīng)被google自己和業(yè)內(nèi)大規(guī)模使用了，證明是可靠的；而messagepack貌似出來(lái)的比較晚，還沒被大規(guī)模使用。
（2）語(yǔ)言支持，protobuf官方原生支持C++、Java、python，其他均為第三方擴(kuò)展；messagepack官方支持C++、Java、php，不支持as，但支持js。
（3）protobuf有個(gè)編譯器可以自動(dòng)生成各語(yǔ)言對(duì)應(yīng)版本的協(xié)議類；messagepack在強(qiáng)類型如java和C++里就需要自己寫各個(gè)語(yǔ)言版本的了。
（4）體積方面，messagepack的體積應(yīng)該比protobuf稍大。
（5）速度方面，messagepack官方說(shuō)速度是protobuf的4倍，但是看他的測(cè)試只是一種語(yǔ)言的序列化測(cè)試。
（6）其他，messagepack也支持key-value方式的序列化，號(hào)稱體積小的JSON。這雖很容易移植以前的協(xié)議，為了快速出demo，我也都準(zhǔn)備用messagepack先期試改了，但是猛然發(fā)現(xiàn)每個(gè)語(yǔ)言還是得寫各自的，而且現(xiàn)在涉及到兩種不同前端，一段的修改還需及時(shí)通知另一前端做相應(yīng)修改。這種太難控制了，沒有protobuf的proto文件那種的一致性保證。
三、最終選擇
綜合以上的比較，最后選擇了protobuf來(lái)作為我們項(xiàng)目新的網(wǎng)絡(luò)通信序列化協(xié)議。
ps：2012年9月21日我在CU上的博文