前面系统研究了 Hessian 序列化协议。并以此为契机，顺带实例对比了 Hessian、MessagePack 和 JSON 的序列化。早在 2012 年，Martin Kleppmann 就写了一篇文章 《Schema evolution in Avro, Protocol Buffers and Thrift》，也是基于实例，对比了 Avro、ProtoBuf、Thrift 的差别。现在翻译出来，方便做系列研究。

整个“序列化系列”目录如下：

1. Hessian 2.0 序列化协议（中文版） — Hessian 序列化协议的中文翻译版。根据后面的“协议解释与实战”系列文章，增加了协议内容错误提示。

2. Hessian 协议解释与实战（一）：布尔、日期、浮点数与整数 — 介绍布尔型数据、日期类型、浮点类型数据和整数类型数据等四种类型的数据的处理。

3. Hessian 协议解释与实战（二）：长整型、二进制数据与 Null — 介绍长整数类型数据、二进制数据和 null 等三种类型的数据的处理。

4. Hessian 协议解释与实战（三）：字符串 — 专门介绍了关于字符串的处理。由于字符串需要铺垫的基础知识比较多，处理细节也有繁琐，所以单独成篇来介绍。

5. Hessian 源码分析（Java） — 开始第四篇分析之前，先来介绍一下 Hessian 的源码实现。方便后续展开说明。

6. Hessian 协议解释与实战（四）：数组与集合 — 铺垫了一些关于实例对象的处理，重点介绍关于数组和集合的相关处理。

7. Hessian 协议解释与实战（五）：对象与映射 — 重点介绍关于对象与映射的相关处理。

8. Hessian、Msgpack 和 JSON 实例对比 — 用实例对比 JSON、Hessian 和 MessagePack 的区别。

9. Avro、ProtoBuf、Thrift 的模式演进之路 — 翻译的 Martin Kleppmann 的文章，重点对比了 Avro、ProtoBuf、Thrift 的序列化处理思路。

person 对象的 ProtoBuf 模式可能类似于这样：

当我们使用这个模式对上面的数据进行 编码 时，它使用 33 字节，如下所示

仔细看看二进制表示是如何一个字节一个字节地构造的。person 记录只是其字段的集合。每个字段都以一个字节开始，该字节指示其 Tag Number（标签号，即上面的模式中的数字1、2、3）和字段的 Type（类型）。如果字段的第一个字节表明该字段是字符串，则随后是字符串中的字节数，然后是字符串的 UTF-8 编码。如果第一个字节表示该字段是一个整数，则接下来是该数字的变长编码。没有数组类型，但是 Tag Number 可以出现多次以表示一个多值字段。

这种编码对模式演进的影响：

• optional 可选，required 必需和 repeated 重复字段之间的编码没有差异（除了 Tag Number 标签号出现的次数）。这意味着您可以将字段从可选更改为重复，反之亦然（如果解析器期望一个可选字段，但在一条记录中多次看到相同的标签号，则它将丢弃除最后一个值之外的所有值）。required 必需字段有一个额外的验证检查，因此，如果您更改它，则可能会出现运行时错误（如果消息的发件人认为它是可选的，但是收件人认为这是必需的）。

• 没有值的可选字段或长度为零的重复字段，根本不会出现在编码数据中 - 该 Tag Number 标签号的字段根本不存在。因此，可以安全地从模式中删除这种字段。但是，以后决不能将 Tag Number 标签号用于另一个字段，因为在存储的数据，可能仍然使用该编号标记的已删除字段。

• 只要给出一个新的 Tag Number 标签号，就可以在记录中添加一个字段。如果 ProtoBuf 解析器看到一个没有在其模式中定义的标签号，它就无法知道该字段被称为什么。但它确实大致知道它是什么类型，因为该字段的第一个字节中包含3位类型代码。这意味着，即使解析器无法准确地解释字段，它也可以计算出需要跳过多少字节，以便在记录中找到下一个字段。

• 可以重命名字段，因为二进制序列化中不存在字段名称，但永远无法更改标签号。

这种使用标签号来表示每个字段的方法简单而有效。但是我们马上就会看到，这并不是做事情的唯一方法。

Avro模式可以用两种方式编写，一种是JSON格式：

或者使用领域专属语言：

注意，模式中没有标签号！那么它是如何工作的呢？

这里是以 32 字节 编码 的相同示例数据：

字符串只是一个长度前缀，后跟 UTF-8 字节，但字节流中没有任何信息表明它是字符串。它也可能是一个可变的整数，或者完全是其他东西。解析此二进制数据的唯一方法是将其与模式一起读取，模式将告诉您下一步将使用什么类型。需要拥有与所用数据的编写者完全相同的模式版本。如果使用了错误的模式，解析器将无法读取二进制数据的头部或尾部。

那么 Avro 如何支持模式演进？虽然需要知道写入数据的确切模式(生产者模式)，但它不必与消费者期望的模式(消费者模式)相同。实际上，可以给 Avro 解析器提供两个不同的模式，它使用 解析规则 将数据从生产者模式转换为消费者模式。

这对模式演进产生一些有趣的结果：

• Avro 编码没有指示下一个字段的标识符；它只是按照字段在模式中出现的顺序，对一个又一个字段进行编码。由于解析器无法知道某个字段被跳过，所以在 Avro 中不存在可选字段。取而代之的是，如果想能够忽略一个值，则可以使用联合类型，例如上面的 {null，long}。这被编码为一个字节，告诉解析器使用哪种可能的联合类型，然后是值本身。通过与 null 类型结合（简单地编码为零字节），可以使字段成为可选字段。

• 联合类型很强大，但在更改它们时必须小心。如果要向联合添加类型，首先需要用新模式更新所有消费者，以便它们知道会发生什么。只有当所有的消费者都更新之后，生产者才可以开始将这种新类型放入他们生成的数据记录中。

• 可以按照自己的意愿对记录中的字段进行重新排序。尽管字段按照声明的顺序编码，但解析器通过名称匹配消费者、生产者模式中的字段，这就是为什么 Avro 中不需要标记号的原因。

• 因为字段是按名称匹配的，所以更改字段的名称很棘手。需要首先更新数据的所有消费者，以使用新的字段名，同时保留旧名称作为别名(因为名称匹配使用消费者模式中的别名)。然后，可以更新生产者的模式以使用新的字段名称。

• 可以向记录中添加一个字段，前提是您还为其提供了一个默认值(例如，如果字段的类型是与 null 的联合，则为 null)。默认值是必要的，因此当使用新模式的读取器解析用旧模式写入的记录时(因此缺少字段)，它可以填充默认值。

• 相反，可以从记录中删除一个字段，前提是它以前有一个默认值。(如果可能的话，这是为所有字段提供默认值的一个很好的理由。)这样，当使用旧模式的消费者解析用新模式写入的记录时，它可以回退到默认值。

这给我们留下了一个问题，即知道写入给定记录的确切模式。最佳解决方案取决于使用数据的上下文：

• 在Hadoop中，通常有包含数百万条记录的大文件，所有记录都用相同的模式编码。 对象容器文件可以处理这种情况：它们只在文件的开头包含一次模式，文件的其余部分可以使用该模式进行解码。

• 在 RPC 上下文中，为每个请求和响应发送模式的开销可能太大。但是，如果您的RPC框架使用长连接，则可以在连接开始时协商一次模式，并将开销分摊到许多请求上。

• 如果将记录逐个存储在数据库中，可能会在不同的时间编写不同的模式版本，因此必须用其模式版本对每个记录进行注释。如果存储模式本身的开销太大，可以使用模式的 哈希 或连续的模式版本号。然后，您需要一个 模式注册中心，可以在其中查找给定版本号的确切模式定义。

可以这样看：在 ProtoBuf 中，记录中的每个字段都被标记；而在 Avro 中，整个记录、文件或网络连接都被标记为模式版本。

乍一看，Avro 的方法似乎有更大的复杂性，因为需要付出额外的努力来分发模式。然而，我现在认为 Avro 的方法也具有一些明显的优势：

• 对象容器文件具有很好的自描述功能：嵌入在文件中的生产者模式包含所有字段名称和类型，甚至包括文档字符串(如果模式的作者愿意写一些的话)。这意味着您可以直接将这些文件加载到像 Pig 这样的交互式工具中，而且它不需要任何配置就可以正常工作。

• 因为 Avro 模式是 JSON，可以向其添加自己的元数据，例如描述一个字段的应用级语义。当分发模式时，元数据也会自动分发。

• 在任何情况下，模式注册中心都可能是一件好事，可以作为 文档 并帮助您查找和重用数据。而且，由于没有模式就无法解析 Avro 数据，因此模式注册表保证是最新的。当然，也可以设置一个 ProtoBuf 模式注册表，但是由于它不是操作所必需的，因此它将以尽力而为的方式结束。

Thrift 是一个比 Avro 或 ProtoBuf 更大的项目，因为它不仅是一个数据序列化库，而且是一个完整的 RPC 框架。它也有一些不同的文化：Avro 和 ProtoBuf 标准化了单一的二进制编码，而 Thrift 则 包含 了各种不同的序列化格式（它称之为“协议”）。

实际上，Thrift 有两种不同的 JSON 编码，以及至少三种不同的二进制编码。(然而，其中一种二进制编码，DenseProtocol，仅在 C++ 实现中支持；由于我们对跨语言序列化感兴趣，所以将重点介绍另外两种。)

在 Thrift IDL 中，所有编码共享相同的模式定义：

BinaryProtocol 编码非常简单，但也相当浪费（编码示例记录需要 59 字节）：

CompactProtocol 编码在语义上是等价的，但使用可变长度整数和位压缩将大小减小到 34 字节：

可以看到，Thrift 的模式演进方法与 ProtoBuf 相同：在 IDL 中手动为每个字段分配一个 Tag 标签，并且 Tag 标签和字段类型存储在二进制编码中，这使得解析器可以跳过未知字段。Thrift 定义了一个明确的列表类型，而不是 ProtoBuf 的重复字段方法，但是在其他方面两者非常相似。

但从哲学的角度来看，各个库是非常不同的。Thrift 喜欢一站式服务的风格，它提供了一个完整的集成 RPC 框架和许多选择(具有不同的跨语言支持)；而 ProtoBuf 和 Avro 似乎更遵循“做一件事，并做好它”的风格。