用 Protobuf 很久了，但是一直觉得很简单，所以就没有做一个总结，今天想尝试一下 gRPC，顺带就一起总结一下。ProtoBuf 是个老同志了，应该是 2010 的时候发布的，然后被广泛使用，目前在市面上应该和 Facebook 的 thrift 应该是不相上下，无论是性能上，还是用户的支持度上。
What's ProtoBufProtoBuf 是一种数据表达方式，根据 G 家自己的描述，应该叫做数据交换格式，注意这里使用的是 交换 字眼，也就是说着重于在数据的传输上，有别于 TOML 和 XML 较常用于配置（当然 WebService 一套也是用于数据交换）。
在使用 ProtoBuf 之后，很多时候，我都希望能够用它来替换 json 和 XML，因为相比较于这些工具，ProtoBuf 的优势比较明显。例如 json 虽然表达方便，语法清晰，但是，有一个硬伤就是没有 schema，对于 Client-Server 的应用/服务来说，这就意味着双方需要使用其他方式进行沟通 schema，否则将无法正确的交流；相比之下，XML 确实提供了强大的 Schema 支持，但是，可能因为年纪更大的缘故，XML 自身的语法啰嗦，更别说定义它的 Schema 了，一句话概括，那就是非常得不现代。
ProtoBuf 结构ProtoBuf 目前有两个版本，分别是 proto2 和 proto3，虽然 proto3 看上去比 proto2 新，但是，在一些处理上其实被很多人所诟病，例如默认值和未定义的字段的处理上，proto3 不如 proto2；但是 proto3 确实也修正了 proto2 的很多问题和做了精简，所以这里我就直接上 proto3 了，不会差别很大，所以喜欢 proto2 的同学也不用纠结。
proto 的语法有点类似于定义一个类或者说结构体更合适一些，因为它没有方法，只有属性，一个简单的示例为：
第 1 行肯定是需要的，表面一下你用的是哪个版本，这里指明我的语法是 "proto3" 版本的
第 3 行这里就可以理解成定义了一个结构体，名字叫做：SearchRequest
第 4 - 6 行就是定义了结构体的属性了，类型 + 名字，这里后面的 "=1/2/3" 这个先不用关注，保证它不一样就好了
这样我们就定义了一个简单的 ProtoBuf，也就是这么简单，然后我们应该尝试一下如何用程序语言来使用这个结构。我这里使用的编程语言是 Go 语言，但是其实用什么语言都不是问题，因为步骤基本一致。
程序操作 ProtoBuf不同于 json 可以直接被读取解析，ProtoBuf 因为一些元数据，所以在使用之前，我们需要通过工具生成 Model 类，然后再使用，工具安装可以参考官方的文档进行安装，安装完成之后我们直接使用命令生成即可：
$ protoc --go_out=. --python_out=. search.proto这里从参数中可以看到，我生成了两种语言的 Model，分别是 Python 和 Go 的，类似的，如果你需要其他语言的 Model，可以将语言名字替换试试。
命令完成之后，我们可以在当前目录看到一些文件了：
然后我们就可以操作使用代码进行操作了，下面继续：
我这里就通过这个 Model 新建一个对象，然后将它序列化（Line 7），序列化之后看一下序列化结果的类型，然后再反序列化（Line 15）回来，然后再看看反序列化之后结果是否正常（Line 20 - 22）。如果你的代码写得没问题的话，那么对应的结果应该也是一样的：
从上边的 Demo 里边你可能看不出 ProtoBuf 有什么特别好的优势，除了有 Schema 之外，但是，如果你看一下序列化之后的 data 的大小之后，你会发现它才 22 个 uint8，以为这什么，也就是说刚才的数据结构才占用 22 个字节，如果你用 json 和 XML 的话是多少？就拿 json 来说，key 和 value 两部分，value 的大小就算和 ProtoBuf 的 value 一样，那应该要 20 个字节，加上 key 超过 20 个字节，算下来至少的 40 个字节，可以认为这里至少省下了一半的空间。你会说这点小钱看不上，但是，你觉得在企业服务中，数据就这么几个？在大数据的场景下，每天的数据量随随便便几百个 G 甚至几十 T；在网络中，节省一半流量代价的下降将至少减少 2 倍以上，内存同理。
既然 ProtoBuf 能这么省字节，那么它是怎么做到的？不知道你还记得不，前面在定义 Message 的时候我让你先忽略掉的数字：