Protocol Buffers简明教程

随着微服务架构的流行，RPC框架渐渐地成为服务框架的一个重要部分。在很多RPC的设计中，都采用了高性能的编解码技术，Protocol Buffers就属于其中的佼佼者。 Protocol Buffers 是Google开源的一个语言无关、平台无关的通信协议，其小巧、高效和友好的兼容性设计，使其被广泛使用。

官方如是说：

有位网友曾经做过 各种通用序列化协议技术的对比 ，我这里直接拿来给大家感受一下：

序列化响应时间对比

序列化bytes对比

具体的数字

以下示例源码已上传至github： https://github.com/ginobefun/learning_projects/tree/master/learning-protobuf

先添加一个联系人Gino

再添加一个联系人Slightly

最后显示所有联系人信息

字段描述符用于描述字段出现的频率，有以下两个可选值：

protobuf 2.X版本是支持在字段中声明默认值的，但是在3.X版本中去掉了默认值的定义，主要是为了区别用户是否设置了一个和默认值一样的值的情况。对于3.X版本，protobuf采用以下规则处理默认值：

proto具有很好的扩展性，但是也要遵循以下原则：

Protobuf 是经过深思熟虑的消息打包方案，它的默认序列化格式没有包含消息的长度与类型，自然有其道理。哪些情况下不需要在 protobuf 序列化得到的字节流中包含消息的长度和（或）类型？我能想到的答案有：

如果把消息写入文件，一个文件存一个消息，那么序列化结果中不需要包含长度和类型，因为从文件名和文件长度中可以得知消息的类型与长度。

如果把消息写入文件，一个文件存多个消息，那么序列化结果中不需要包含类型，因为文件名就代表了消息的类型。

如果把消息存入数据库（或者 NoSQL），以 VARBINARY 字段保存，那么序列化结果中不需要包含长度和类型，因为从字段名和字段长度中可以得知消息的类型与长度。

如果把消息以 UDP 方式发生给对方，而且对方一个 UDP port 只接收一种消息类型，那么序列化结果中不需要包含长度和类型，因为从 port 和 UDP packet 长度中可以得知消息的类型与长度。

如果把消息以 TCP 短连接方式发给对方，而且对方一个 TCP port 只接收一种消息类型，那么序列化结果中不需要包含长度和类型，因为从 port 和 TCP 字节流长度中可以得知消息的类型与长度。

如果把消息以 TCP 长连接方式发给对方，但是对方一个 TCP port 只接收一种消息类型，那么序列化结果中不需要包含类型，因为 port 代表了消息的类型。

如果采用 RPC 方式通信，那么只需要告诉对方 method name，对方自然能推断出 Request 和 Response 的消息类型，这些可以由 protoc 生成的 RPC stubs 自动搞定。

对于最后一点，比方说 sudoku.proto 定义为：

service SudokuService {

rpc Solve (SudokuRequest) returns (SudokuResponse)

}

那么 RPC method Sudoku.Solve 对应的请求和响应分别是 SudokuRequest 和 SudokuResponse。在发送 RPC 请求的时候，不需要包含 SudokuRequest 的类型，只需要发送 method name Sudoku.Solve，对方自知道应该按照 SudokuRequest 来解析(parse)请求。这个例子来自我的半成品项目 evproto。

对于上述这些情况，如果 protobuf 无条件地把长度和类型放到序列化的字节串中，只会浪费网络带宽和存储。可见 protobuf 默认不发送长度和类型是正确的决定。Protobuf 为消息格式的设计树立了典范，哪些该自己搞定，哪些留给外部系统去解决，这些都考虑得很清楚。

只有在使用 TCP 长连接，且在一个连接上传递不止一种消息的情况下（比方同时发 Heartbeat 和 Request/Response），才需要我前文提到的那种打包方案。（为什么要在一个连接上同时发 Heartbeat 和业务消息？请见陈硕《分布式系统的工程化开发方法》 p.51 心跳协议的设计。）这时候我们需要一个分发器 dispatcher，把不同类型的消息分给各个消息处理函数，这正是本文的主题之一。

---