【Protocol Buffers】Google開源技術-Protocol Buffers介紹

出處:http://program-think.blogspot.com/2009/05/opensource-review-protocol-buffers.html

本帖牆內鏡像:
http://blog.csdn.net/program_think/archive/2009/05/31/4229773.aspx

今天來介紹一下「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。可能有同學會問,和protobuf類似的東東也有不少,為啥獨獨相中protobuf捏?由於今天寫的篇幅已經蠻長了,俺賣個關子,把這個話題留到「生產者/消費者模式[5]:如何選擇傳輸協議及格式?」。俺會在後續的這個帖子裡對比各種五花八門的協議格式,並談談俺的淺見。

俺博客上,和本文相關的帖子(需翻牆)
開源點評:ZeroMQ簡介
開源點評:cURL——優秀的應用層網絡協議庫

版權聲明
本博客所有的原創文章,作者皆保留版權。轉載必須包含本聲明,保持本文完整,並以超鏈接形式註明作者編程隨想和本文原始地址:
http://program-think.blogspot.com/2009/05/opensource-review-protocol-buffers.html

未經允許不得轉載:GoMCU » 【Protocol Buffers】Google開源技術-Protocol Buffers介紹