Protocol Buffers

　　今天来介绍一下“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（详细解释看“这里”）的影子。它们的思想是相通滴。



　　◇支持“向后兼容”和“向前兼容”

　　还是拿刚才的例子来说事儿。为了叙述方便，俺把增加了“状态”属性的订单协议成为“新版本”；之前的叫“老版本”。

转载自：http://blog.csdn.net/program_think/article/details/4229773

更详细的参考：http://www.cnblogs.com/dkblog/archive/2012/03/27/2419010.html

http://www.cnblogs.com/stephen-liu74/archive/2013/01/04/2842533.html