简介

提到grpc就不得不提pb协议，protocol buffer是一个语言无关，平台无关，可扩展的结构化数据序列化方案, 用于协议通讯, 数据存储和其他更多用途。
gRPC的一个重要基石就是 Protocol Buffer 3, 这个版本(被称为proto3)是原有Protocol Buffer 2(被称为proto2)的升级版本，删除了一部分特性，优化了对移动设备的支持，另外增加了对android和ios的支持，使得gRPC可以顺利的在移动设备上使用。

本内容主要来自官方文档 Protocol Buffers | Google Developers
后续用pb表示protocol buffers
本文主要使用C++和go进行介绍

概述

本文描述了如何使用pb语言来构建协议缓冲数据（即protocol + buffers)，包括文件语法以及如何从文件生成对应代码的数据访问类。主要是针对Proto3版本的协议，参阅Proto3语言指南。
这是一个参考指南 - 更新的文档请参阅教程。
关于3版本的协议和2版本的不再赘述，我们直接开始。

protocol buffers是什么?

Protocol buffer 是一个灵活,高效,自动化的结构化数据序列化机制 - 比如xml, 但是更小, 更快并且更简单。一旦定义好数据如何构造, 就可以使用特殊的生成的源代码来轻易的读写你的结构化数据到和从不同的数据流，用不同的语言。你甚至可以更新你的数据结构而不打破已部署的使用"旧有"格式编译的程序。

How do they work?

通过在.proto文件中定义protocol buffer消息类型来指定要序列化的信息如何组织。每个protocol buffer消息是一个小的消息逻辑记录，包含一序列的"名字-值"对。下面是一个非常基本的例子，.proto文件定义了一个消息，包含一个人的消息：

message Person {
  required string name = 1;
  required int32 id = 2;
  optional string email = 3;

  enum PhoneType {
    MOBILE = 0;
    HOME = 1;
    WORK = 2;
  }

  message PhoneNumber {
    required string number = 1;
    optional PhoneType type = 2 [default = HOME];
  }

  repeated PhoneNumber phone = 4;
}

如上述，消息格式很简单 - 每个消息类型有一个或者多个唯一的编号的字段，而每个字段有一个名字和值类型，这里的值类型可以是数字（整型或者浮点），布尔，字符串，原始字节（raw bytes），或者甚至（如上面的例子）是其他protocol buffer消息，容许分层次的构建数据。可以指定可选字段，必填字段和重复字段。

一旦定义了消息，可以在.proto文件上运行对应应用语言的protcol buffer的编译器来生成数据访问类。这些类为每个字段(类似name()或者set_name())提供简单的访问器，还有用于序列化/解析整个结构到/从原始字节的方法 - 因此，例如，如果你选择的语言是c++，在上面的例子上运行编译器将会生成名为Person的类。然后可以用这个类在应用中获取，序列化，并获取 Person protocol buffer消息。可能随后编写一些类似这样的代码：

Person person;
person.set_name("John Doe");
person.set_id(1234);
person.set_email("jdoe@example.com");
fstream output("myfile", ios::out | ios::binary);
person.SerializeToOstream(&output);

然后，稍后，可以这样读回消息：

fstream input("myfile", ios::in | ios::binary);
Person person;
person.ParseFromIstream(&input);
cout << "Name: " << person.name() << endl;
cout << "E-mail: " << person.email() << endl;

可以添加新的字段到消息格式中，而不破坏向后兼容；老的二进制在解析时简单的忽略新的字段。因此，如果有一个使用protocol buffer作为数据格式的通讯协议，可以扩展协议而不必担心打破已有代码。

为什么不使用xml?

相比xml, Protocol buffer在序列化结构化数据方面有很多优势:

更简单
小3 到 10 倍
快 20 到 100 倍
更清晰
生成数据访问类, 更容易编程使用

例如，假设想要用 name 和 email 来构建一个 Person。在XML中，需要这样做：

<person>
    <name>John Doe</name>
    <email>jdoe@example.com</email>
</person>

而对应的protocol buffer消息(使用protocol buffer 文本格式):

# protocol buffer的文本展示
# 这 *不是* 实际使用的二进制格式。
person {
  name: "John Doe"
  email: "jdoe@example.com"
}

当这个消息被编码为protocol buffer 二进制格式(上面的文本格式仅仅是在调试和编辑时方便人阅读的表示方式)，它将可能是长28个字节并花费100-200纳秒来解析。XML版本至少需要69个字节，如果删除空白字符，并将话费5000 - 10000 纳秒来解析。

另外，操作protocol buffer也更简单：

cout << "Name: " << person.name() << endl;
cout << "E-mail: " << person.email() << endl;

而使用XML，将不得不做类似的事情：

cout << "Name: "
   << person.getElementsByTagName("name")->item(0)->innerText()
   << endl;
cout << "E-mail: "
   << person.getElementsByTagName("email")->item(0)->innerText()
   << endl;

当然，Protocol buffer 也不总是比XML更合适 - 例如，Protocol buffer 不适合建模基于文本的标志(如HTML)文档，因为无法轻易的使用文本交替结构。此外，XML是human-readable 和 human-editable的。Protocol buffer，至少他们原生的格式不是。XML也是某种程度上的自描述。Protocol buffer只有当有消息定义(.proto文件)时才有意义。