Google Protocol Buffers

    首先，protobuf是一个开源项目（官方站点在“这里 ”），大家可以看出它的后台有多硬了。那这个东西到底能干什么？简单地说，它和xml、json差不多，也是把某种数据结构的信息，以某种格式保存起来。主要用于 数据存储、传输协议格式等场合。

protobuf有啥特色？

1、性能好/效率高

这也是谷歌放着好好的xml不用，而重新造轮子的原因。在时间开销方面：xml格式化（序列化）的开销还行，但是xml解析（反序列化）就不尽人意了。在空间开销方面：由于xml具有较好的可读性，从而导致有大量的冗余文本（不过这对数据量不大的小企业也没有多大影响，对google就不一样了）。

Google对于性能的偏执，那可是出了名的。所以，俺对于Google搞出来protobuf是非常滴放心，性能上不敢说是最好，但肯定不会太差。

 2、代码生成机制

先来举个例子：

　　比如有个电子商务的系统（假设用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（详细解释看“这里 ”）的影子。它们的思想是相通滴。

　3、支持“向后兼容”和“向前兼容”
　　还是拿刚才的例子来说事儿。为了叙述方便，俺把增加了“状态”属性的订单协议成为“新版本”；之前的叫“老版本”。
　　所谓的“向后兼容”（backward compatible），就是说，当模块B升级了之后，它能够正确识别模块A发出的老版本的协议。由于老版本没有“状态”这个属性，在扩充协议时，可以考 虑把“状态”属性设置成非必填 的，或者给“状态”属性设置一个缺省值（如何设置缺省值，参见“这里 ”）。
　　所谓的“向前兼容”（forward compatible），就是说，当模块A升级了之后，模块B能够正常识别模块A发出的新版本的协议。这时候，新增加的“状态”属性会被忽略。
　　“向后兼容”和“向前兼容”有啥用捏？俺举个例子：当你维护一个很庞大的分布式系统时，由于你无法同时 升级所有 模块，为了保证在升级过程中，整个系统能够尽可能不受影响，就需要尽量保证通讯协议的“向后兼容”或“向前兼容”。

　　4、支持多种编程语言
　　不过俺有义务提醒一下在座的各位同学。如果你考虑把protobuf用于除c++/java/python之外的这些语言，一定认真评估对应的开源库。因为这些开源库不是Google官方提供的、而且出来的时间还不长。所以，它们的质量、性能等方面可能还有欠缺。

protobuf有啥缺陷？ 
　　1、应用不够广
　　由于protobuf刚公布没多久，相比XML而言，protobuf还属于初出茅庐。因此，在知名度、应用广度等方面都远不如XML。由于这个原因，假如你设计的系统需要提供若干对外的接口给第三方系统调用，俺奉劝你暂时不要考虑protobuf格式。
　2、二进制格式导致可读性差
　　为了提高性能，protobuf采用了二进制格式进行编码。这直接导致了可读性差的问题（严格地说，是没有可读性）。虽然protobuf提供了TextFormat这个工具类（文档在“这里 ”），但终究无法彻底解决此问题。
　　可读性差的危害，俺再来举个例子。比如通讯双方如果出现问题，极易导致扯皮（都不承认自己有问题，都说是对方的错）。俺对付扯皮的一个简单方法就是直 接抓包并dump成log，能比较容易地看出错误在哪一方。但是protobuf的二进制格式，导致你抓包并直接dump出来的log难以看懂。
　3、缺乏自描述
　　一般来说，XML是自描述的，而protobuf格式则不是。给你一段二进制格式的协议内容，如果不配合相应的proto文件，那简直就像天书一般。
　　由于“缺乏自描述”，再加上“二进制格式导致可读性差”。所以在配置文件方面，protobuf是肯定无法取代XML的地位滴。

 

评论

1 楼 RonQi 2012-05-25  

楼主写的很好，支持原创！