今天來介紹一下“PRotocol Buffers ”（以下簡稱protobuf）這個玩意兒。本來俺在構思“生產者/消費者模式 ”系列的下一個帖子：關于生產者和消費者之間的數據傳輸格式。由于里面扯到了protobuf，想想干脆單獨開一個帖子算了。 　　★protobuf是啥玩意兒？ 　　為了照顧從沒聽說過的同學，照例先來掃盲一把。 　　首先，protobuf是一個開源 項 目（官方站點在“這里 ”），而且是后臺很硬的開源項目。網上現有的大部分（至少80%）開源項目，要么是某人單干、要么是幾個閑雜人等合伙搞。而protobuf則不然，它是 鼎鼎大名的Google公司開發出來，并且在Google內部久經考驗的一個東東。由此可見，它的作者絕非一般閑雜人等可比。 　　那這個聽起來牛X的東東到底有啥用處捏？簡單地說，這個東東干的事兒其實和xml 差不多，也就是把某種數據結構的信息，以某種格式保存起來。主要用于數據存儲、傳輸協議格式等場合。有同學可能心理犯嘀咕了：放著好好的XML不用，干嘛重新發明輪子?。?！先別急，后面俺自然會有說道。 　　話說到了去年（大約是08年7月），Google突然大發慈悲，把這個好東西貢獻給了開源社區。這下，像俺這種喜歡撿現成的家伙可就有福啦！貌似喜歡 撿現成的家伙還蠻多滴，再加上 Google的號召力，開源后不到一年，protobuf的人氣就已經很旺了。所以俺為了與時俱進，就單獨開個帖子來忽悠一把。 　　★protobuf有啥特色？ 　　掃盲完了之后，就該聊一下技術 方面的話題了。由于這玩意兒發布的時間較短（未滿周歲），所以俺接觸的時間也不長。今天在此是先學現賣，列位看官多多包涵 :-) 　　◇性能好/效率高 　　現在，俺就來說說Google公司為啥放著好端端的XML不用，非要另起爐灶，重新造輪子。一個根本的原因是XML性能不夠好。 　　先說時間開銷：XML格式化（序列化）的開銷倒還好；但是XML解析（反序列化）的開銷就不敢恭維啦。俺之前經常碰到一些時間性能很敏感的場合，由于不堪忍受XML解析的速度，棄之如敝履。 　　再來看空間開銷：熟悉XML語法的同學應該知道，XML格式為了有較好的可讀性，引入了一些冗余的文本信息。所以空間開銷也不是太好（不過這點缺點，俺不常碰到）。 　　由于Google公司賴以吹噓的就是它的海量數據和海量處理能力。對于幾十萬、上百萬機器的集群，動不動就是PB級的數據量，哪怕性能稍微提高 0.1% 也是相當可觀滴。所以Google自然無法容忍XML在性能上的明顯缺點。再加上Google從來就不缺造輪子的牛人，所以protobuf也就應運而生 了。 　　Google對于性能的偏執，那可是出了名的。所以，俺對于Google搞出來protobuf是非常滴放心，性能上不敢說是最好，但肯定不會太差。 　　◇代碼 生成機制 　　除了性能好，代碼生成機制是主要吸引俺的地方。為了說明這個代碼生成機制，俺舉個例子。 　　比如有個電子商務的系統（假設用C++實現），其中的模塊A需要發送大量的訂單信息給模塊B，通訊的方式使用socket。 假設訂單包括如下屬性： －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ 　　時間：time（用整數表示） 　　客戶id：userid（用整數表示） 　　交易金額：price（用浮點數表示） 　　交易的描述：desc（用字符串表示） －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ 　　如果使用protobuf實現，首先要寫一個proto文件（不妨叫Order.proto），在該文件中添加一個名為”Order”的message結構，用來描述通訊協議中的結構化數據。該文件的內容大致如下：

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ message Order { required int32 time = 1; required int32 userid = 2; required float price = 3; optional string desc = 4; } －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

　　然后，使用protobuf內置的編譯器編譯 該proto。由于本例子的模塊是C++，你可以通過protobuf編譯器的命令行參數（看“這里 ”），讓它生成C++語言的“訂單包裝類”。（一般來說，一個message結構會生成一個包裝類） 　　然后你使用類似下面的代碼來序列化/解析該訂單包裝類：

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ // 發送方 Order order; order.set_time(XXXX); order.set_userid(123); order.set_price(100.0f); order.set_desc(“a test order”); string sOrder; order.SerailzeToString(&sOrder); // 然后調用某種socket的通訊庫把序列化之后的字符串發送出去 // …… －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ // 接收方 string sOrder; // 先通過網絡通訊庫接收到數據，存放到某字符串sOrder // …… Order order; if(order.ParseFromString(sOrder)) // 解析該字符串 { cout << “userid:” << order.userid() << endl << “desc:” << order.desc() << endl; } else { cerr << “parse error!” << endl; } －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

　　有了這種代碼生成機制，開發人員再也不用吭哧吭哧地編寫那些協議解析的代碼了（干這種活是典型的吃力不討好）。 　　萬一將來需求發生變更，要求給訂單再增加一個“狀態”的屬性，那只需要在Order.proto文件中增加一行代碼。對于發送方（模塊A），只要增加一行設置狀態的代碼；對于接收方（模塊B）只要增加一行讀取狀態的代碼。哇塞，簡直太輕松了！ 　　另外，如果通訊雙方使用不同的編程語言來實現，使用這種機制可以有效確保兩邊的模塊對于協議的處理是一致的。 　　順便跑題一下。 　　從某種意義上講，可以把proto文件看成是描述通訊協議的規格說明書（或者叫接口規范）。這種伎倆其實老早就有了，搞過微軟的COM編程或者接觸過CORBA的同學，應該都能從中看到IDL（詳細解釋看“這里 ”）的影子。它們的思想是相通滴。 　　◇支持“向后兼容”和“向前兼容” 　　還是拿剛才的例子來說事兒。為了敘述方便，俺把增加了“狀態”屬性的訂單協議成為“新版本”；之前的叫“老版本”。 　　所謂的“向后兼容”（backward compatible），就是說，當模塊B升級了之后，它能夠正確識別模塊A發出的老版本的協議。由于老版本沒有“狀態”這個屬性，在擴充協議時，可以考 慮把“狀態”屬性設置成非必填 的，或者給“狀態”屬性設置一個缺省值（如何設置缺省值，參見“這里 ”）。 　　所謂的“向前兼容”（forward compatible），就是說，當模塊A升級了之后，模塊B能夠正常識別模塊A發出的新版本的協議。這時候，新增加的“狀態”屬性會被忽略。 　　“向后兼容”和“向前兼容”有啥用捏？俺舉個例子：當你維護一個很龐大的分布式系統時，由于你無法同時 升級所有 模塊，為了保證在升級過程中，整個系統能夠盡可能不受影響，就需要盡量保證通訊協議的“向后兼容”或“向前兼容”。 　　◇支持多種編程語言 　　俺開博以來點評 的幾個開源項目（比如“Sqlite ”、“cURL ”），都是支持很多種 編程語言滴，這次的protobuf也不例外。在Google官方發布的源代碼中包含了C++、java 、Python三種語言（正好也是俺最常用的三種，真爽）。如果你平時用的就是這三種語言之一，那就好辦了。 　　假如你想把protobuf用于其它語言，咋辦捏？由于Google一呼百應的號召力，開源社區對protobuf響應踴躍，近期冒出很多其它編程語言的版本（比如ActionScript、C#、Lisp、Erlang、Perl、php 、Ruby等），有些語言還同時搞出了多個開源的項目。具體細節可以參見“這里 ”。 　　不過俺有義務提醒一下在座的各位同學。如果你考慮把protobuf用于上述這些語言，一定認真評估對應的開源庫。因為這些開源庫不是Google官方提供的、而且出來的時間還不長。所以，它們的質量、性能等方面可能還有欠缺。 　　★protobuf有啥缺陷？ 　　前幾天剛剛在“光環效應 ”的帖子里強調了“要同時評估優點和缺點”。所以俺最后再來批判一下這玩意兒的缺點。 　　◇應用 不夠廣 　　由于protobuf剛公布沒多久，相比XML而言，protobuf還屬于初出茅廬。因此，在知名度、應用廣度等方面都遠不如XML。由于這個原因，假如你設計的系統需要提供若干對外的接口給第三方系統調用，俺奉勸你暫時不要考慮protobuf格式。 　　◇二進制格式導致可讀性差 　　為了提高性能，protobuf采用了二進制格式進行編碼。這直接導致了可讀性差的問題（嚴格地說，是沒有可讀性）。雖然protobuf提供了TextFormat這個工具類（文檔在“這里 ”），但終究無法徹底解決此問題。 　　可讀性差的危害，俺再來舉個例子。比如通訊雙方如果出現問題，極易導致扯皮（都不承認自己有問題，都說是對方的錯）。俺對付扯皮的一個簡單方法 就是直接抓包并dump成log，能比較容易地看出錯誤在哪一方。但是protobuf的二進制格式，導致你抓包并直接dump出來的log難以看懂。 　　◇缺乏自描述 　　一般來說，XML是自描述的，而protobuf格式則不是。給你一段二進制格式的協議內容，如果不配合相應的proto文件，那簡直就像天書一般。 　　由于“缺乏自描述”，再加上“二進制格式導致可讀性差”。所以在配置文件方面，protobuf是肯定無法取代XML的地位滴。 　　★為什么俺會用上protobuf？ 　　俺自從前段時間接觸了protobuf之后，就著手把俺負責的產品中的部分 數據傳輸協議替換成protobuf?？赡苡型瑢W會問，和protobuf類似的東東也有不少，為啥獨獨相中protobuf捏？由于今天寫的篇幅已經蠻 長了，俺賣個關子，把這個話題留到“生產者/消費者模式[5]：如何選擇傳輸協議及格式？”。俺會在后續的這個帖子里對比各種五花八門的協議格式，并談談 俺的淺見。