了解一下ProtoBuf

我们在进行网络通信调用的时候，总是需要将内存的数据块经过序列化，转换成为一种可以通过网络流进行传输的格式。而这种格式在经过了传输之后再经过序列化，能还原成我们预想中的数据结构。

那么我们对于这种用于中间网络传输的数据格式就有一定的要求。首先它可以准确地描述数据内容，在此基础上我们则希望它尽量的小。

最开始流行起来的是XML，可扩展标记语言。由于它可以用来标记数据、定义数据类型，所以用户可以自己定义数据自己的语言，从而让对不同的数据结构化成统一的格式称为了可能。

而另外一个我们熟知的则是JSON（JavaScript Object Notation, JS 对象简谱）。尽管JSON中缺少了XML中的标签属性等描述方式，但是足够简介和清晰的层次结构使得其成为了必XML更受欢迎的数据交换格式。

同一份数据显然JSON的数据量比XML所使用的空间更少。那么空间省略在哪里呢？一方面是json使用更简单的字符来定义数据间的关联关系；另一方面是JSON减少了对数据类型的描述。但是丢少的数据类型再哪里呢？

以Java中的 OpenFeign 举例，JSON中缺少的类型定义被定义道程序中的接口中了。当进行序列化与反序列化时，JSON格式并不记录数据的类型，具体的数据类型在序列化方与反序列化方通过事先约定的接口来进行定义。这样就减少了信息传输过程中的信息量，从而让数据得以压缩。

但是JSON由于没有定义数据类型，所以在传输的过程中实际上就都是文本流，那么这种方法还可以进一步压缩吗？

结合上文的讨论，我们先说结论：方法是有的，并写当前的实现方式是ProtoBuf。但在此之前我们先来了解一下ProtoBuf。

我们可以先看看官方给出的定义与描述：

同样的，ProtoBuf也是一种支持序列化反序列化的方法，并且他具有很多优点：

实际上，ProtoBuf提供了一种通用的数据描述方式，这种定义数据的方式是通用的，就如同JSON或者XML一样。

接下来我们来来回答本节一开始的问题，针对JSON来说，ProtoBuf是如何将体积变得更小的呢？答案很简单，就是为数据序列化反序列化提供更多的先验知识。

本文暂不过度深入ProtoBuf原理，但是可以通过一张图来进行简要说明（）：

ProtoBuf中的数据是按顺序进行排列，而整体的结构为若干个field，每一个field中由 Tag-[Length]-Value 组成。Length是可选的，而是否存在Length是通过Tag的类型来决定的。也就是说如果是指定的类型，比如int64，那我们就可以知道Value的长度，也就不用在依靠Length来对其空间进行描述（redis中的压缩列表也是这个思想）。

那么field应该对应的是什么字段呢？这个则是在序列化与反序列化时在ProtoBuf的服务端与客户端之间进行预先定义的。而因为提前定义了field的类型、排序，所以field本身可以不用对字段名、字段位置进行描述，只需要根据字段类型选用合适的二进制序列化方法，将字段本身的value值进行序列化传输即可。

稍微总结一下：

ProtoBuf通过对传输字段的名称、顺序进行预定义，从而在传输结构中只需要顺序的记录每个字段的类型标签和二进制值。

尽管上文和官方中都是以XML或者JSON来对ProtoBuf进行对比。但是因为ProtoBuf本身就是二进制序列化方式，所以从压缩比上比较感觉有点欺负人。

对应的在Java中二进制常用的序列化器有Kryo和Hessian。但事实上，由于Kryo和Hessian中都需要对Java类名和字段信息进行存储。而ProtoBuf则只有Tag-Length-Value的数据对，且Value更是有针对性的特殊编码，所以空间占用小的很多。

Kryo是专门针对Java进行优化了的。所以在使用的便捷性上来说Kryo则更加方便。但ProtoBuf是跨平台的，且由于进行了字段的顺序定义，所以似的ProtoBuf定义后的接口是可以向前兼容的（只向后追加字段），而这种优势是Kryo所没有的。

ProtoBuf是跨语言的，使用ProtoBuf的第一步是先定一个 proto 文件 ，而由于ProtoBuf 2和3语言版本的不同，其定义格式会有所不同，具体的细节还是得参考官方文档：https://developers.google.cn/protocol-buffers/docs/proto3

对于ProtoBuf 3 的定义文档我们可以按如下方法定义：

其中message关键字是定义的文件名，而 string、int32则是预定的字段类型，repeated则是描述字段为可重复任意多次的字段。

ProtoBuf通过这种形式的文件定义了传输信息的文件结构。

但是之前小节中我们知道了ProtoBuf是通过 Tag-[Length]-Value 组成的数据组来进行信息传输的，那么proto文件中定义的内容如何转换为实际传输的对象呢？

ProtoBuf的做法是，为每一种语言提供一个生成器protoc。通过使用protoc则可以根据.proto文件生成为一组java文件。对应的官方语法演示样例为：

官方的生成参考为：https://developers.google.com/protocol-buffers/docs/reference/java-generated

生成后的java文件将提供对应的实体以及数据的构造方法等文件，从而支持后续的使用。

需要注意的是，ProtoBuf是本质上是序列化方法，具体是通过Spring Cloud 的OpenFeign进行接口调用，还是通过grpc进行接口调用，都是可以的。

本文对ProtoBuff进行了概念的整理，并没有对每个细节都进行深入的梳理，可以当作概念科普来进行阅读。

简单来说， Protocol Buffers 是一种和语言平台都没关的数据交换格式。

关于 Protobuf 在iOS下的使用请看上篇文章 iOS 的 Protocol Buffer 简单使用

Protobuf 序列化后的二进制数据消息非常的紧凑，这得益于 Protobuf 所采用的 Varint

Varint 是一种紧凑的表示数字的方法，它用一个或多个字节来表示一个数字，值越小的数字使用越少的字节数。这能减少用来表示数组的字节数。

比如对于 int32 类型的数字，一般需要4个 byte 来标识。但是采用 Varint，对于很小的 int32 类型的数字，也能用1个 byte 来标识。如果数字很大，也就需要5个 byte 来表示了。但是，一般情况下很少会出现数字都是大数的情况下。

正常情况下，每个 byte 的8个 bit 位都用于存储数据用，而在 Varint 中，每个 byte 的最高位的 bit 有着特殊的含义，如果该位为1，表示后续的 byte 也是该数据的一部分；如果该位为0，则结束。其他的7个 bit 位都用来表示数据。因此小于127的 int32 数字都可以用一个 byte 表示，而大于等于 128 的数字：如128，则会用两个字节表示： 1000 0000 0000 0001 （采用的是小端模式），311则表示： 1011 0111 0000 0010

下图演示了 Protobuf 如果通过2个 byte 解析出 128。Protobuf 字节序采用的是 little-endian(小端模式)

int32 数据类型能表示负数，负数的最高位为1，如果负数也使用这种方式表示会出现一个问题，int32 总是需要5个字节，int64 总是需要10个字节。所以 Protobuf 定义了另外一种类型 sint32, sint64，采用 ZigZag 编码，所有的负数都使用正数表示，计算方式为：

Protobuf 消息是一系列的键值对组成。消息的二进制版本仅使用 field 数字当作 key，不同 field 的属性和类型只能通过消息类型的定义 (即 .proto 文件) 在解码端确定。如果消息中不存在该 field，那么序列化后的 Message Buffer 中也不会有该 field，这些特性都有助于节约消息本身的大小。

Key 用来标识具体的 field，在解包的时候，Protobuf 根据 key 就能知道相应的 Value 对应于消息中的哪一个field，数据类型是哪个类型。

Key 的定义如下：

Key 由两部分组成：第一个部分是 field_number，比如上篇文章定义的消息 FooSimpleMessage 中的 msgId 属性的 field_number 为1；第二部分为 wire_type，表示 Value 的传输类型

表1. Wire Type

在之前的例子中，msgId 采用的数据类型为 int32，因此对应的 wire_type 为0，所以对应的 tag 为

FooSimpleMessage 的 msgContent，field_number 为2，wire_type 为2，所以对应的 tag 为

对应 Length-delimited 的 wire type，后面紧跟着的 Varint 类型表示数据的字节数。所以 msgContent 的 key 后面紧跟着的 0x1a 表示后面的数据长度为10个字节，"A protobuf message content" 的 ASCII 值即为： 0x41 0x20 0x70 0x72 0x6f 0x74 0x6f 0x62 0x75 0x66 0x20 0x6d 0x65 0x73 0x73 0x61 0x67 0x65 0x20 0x63 0x6f 0x6e 0x74 0x65 0x6e 0x74

在 Demo 里面定义的 msg 对象，其序列化后的数据的十六进制表示应该为 0801121a 41207072 6f746f62 7566206d 65737361 67652063 6f6e7465 6e74

运行demo，打印一下结果和猜想的一样:

参考地址： Protocol-buffers Encoding

---