Thrift、Avro、Protocolbuffers - 他们都死了吗？答案

【问题标题】：Thrift, Avro, Protocolbuffers - Are they all dead?Thrift、Avro、Protocolbuffers - 他们都死了吗？
【发布时间】：2017-04-19 11:52:33
【问题描述】：

从事一个宠物项目（cassandra、spark、hadoop、kafka）我需要一个数据序列化框架。查看常见的三个框架——即 Thrift、Avro 和 Protocolbuffers——我注意到它们中的大多数似乎是死气沉沉的，一年最多只有 2 个次要版本。

这给我留下了两个假设：

它们与这样的框架一样完整，只要不需要新功能，它们就处于维护模式
没有理由存在这样的框架 - 我不清楚为什么。如果是这样，有哪些替代方案？

如果有人可以对我的假设给出提示，欢迎提供任何意见。

【问题讨论】：

您希望您的序列化格式快速且频繁地更改吗？

标签： hadoop serialization protocol-buffers thrift avro

【解决方案1】：

Protocol Buffers 是一个非常成熟的框架，大约 15 年前在 Google 首次推出。它当然没有死：谷歌内部几乎所有的服务都使用它。但是经过这么多的使用，此时可能没有太多需要改变的地方。事实上，他们今年发布了一个主要版本 (3.0)，但该版本的主要内容是删除功能而不是添加功能。

Protobuf 的相关 RPC 系统 gRPC 相对较新，最近有更多的活动。（不过，它是基于 Google 内部经过 12 年发展的 RPC 系统。）

我对 Thrift 或 Avro 了解不多，但它们也已经存在了一段时间。

【讨论】：

【解决方案2】：

Thrift 相比 Protobuf 的优势在于 Thrift 提供了完整的 RPC 和序列化框架。 Plus Thrift 支持大约 20 多种目标语言，而且这个数字还在增长。我们即将包含 .NET 核心，并且在不久的将来会有 Rust 支持。

过去几个月没有多少 Thrift 版本这一事实肯定是需要解决的问题，我们完全意识到这一点。另一方面，代码库的整体稳定性非常好，所以可以做一个 Github 分叉，也可以自己从当前的 master 中切出一个分支——当然是使用通常的质量措施。

Avro 和 Thrift 的主要区别在于 Thrift 是静态类型的，而 Avro 使用更动态的方法。在大多数情况下，静态方法可以很好地满足需求，在这种情况下，Thrift 可以让您受益于生成代码的更好性能。如果不是这样，Avro 可能更合适。

另外值得一提的是，除了 Thrift、Protobuf 和 Avro 之外，市场上还有更多的解决方案，例如 Capt'n'proto 或 BOLT。

【讨论】：

“Thrift 提供了一个完整的 RPC 和序列化框架。” -- Protobuf 也是如此：grpc.io
但这是一个附加组件，而不是核心 protobuf。使用 Thrift，您可以获得 OOTB。
我不同意。 gRPC 和 Protobuf 是一起设计和构建的。它们是适当模块化和可分离的——这样你就可以在不需要时避免 RPC 系统的膨胀——这是一个特性，而不是一个错误。
是的，我很清楚 Protobuf 是在 2008 年开源的，因为我是那个项目的领导者，谢谢。 Protobuf 于 2001 年首次构思，RPC 系统于 2004 年首次构思。不幸的是，当我开源 Protobuf 时，我没有资源为公开发布准备 RPC 实现，所以直到后来才真正发生。然而事实证明它们是一起开发的。
@JensG 你能解释一下“Avro 和 Thrift 之间的主要区别在于 Thrift 是静态类型的”段落是什么意思吗？这是 Thrift 的描述语言：thrift.apache.org/docs/idl 你是说这与 Avro 模式中表达的内容有根本的不同吗？ Avro 使用类型信息来实现比 Thrift 更高效的数据编码。 “未标记的数据：由于在读取数据时存在模式，因此需要用数据编码的类型信息要少得多，从而导致更小的序列化大小。”

【解决方案3】：

关于节俭：据我所知，它是活生生的。我们将它用于序列化和我工作的内部 API，它可以正常工作。

已通过 Twitter 的 Finagle 等项目添加了诸如连接多路复用和更用户友好的客户端等缺失的内容。

虽然我会将我们对它的使用描述为半密集型（即，我们不首先考虑性能：它应该易于使用且没有错误），但我们到目前为止没有遇到任何问题。

所以，关于节俭，我想说它属于你的第一类。[*]

Protocolbuffers 是 thrift 序列化部分的替代方案，但它不提供 RPC 工具箱 thrift 提供的功能。

我不知道有任何其他项目将 RPC 和序列化融合到如此简单易用和完整的单个包中。

_{[*]不管怎样，一旦你开始使用它并看到所有的好处，就很难
把它放在你的第二类:)}

【讨论】：

【解决方案4】：

它们在很多地方都非常有用，所以我会说你的第一个假设。我不知道您对发布时间表的期望是什么，但对于这样规模和成熟度的库来说，它们对我来说似乎很正常。哎呀，Avro 1.8.0 于 2016 年初问世，大多数东西仍然使用 Avro 1.7.7（例如 Spark、Hadoop）。 https://avro.apache.org/releases.html

【讨论】：

Avro 是否允许您对现有类进行序列化/反序列化？ “入门”只有两个场景：1. 模型类是从模式生成的，2. 没有代码生成，但唯一的类 ser/des 是 GenericRecord。我的场景没有涵盖：数百个现有的类使用 JDK 序列化但想要更快的东西。看起来 Arvo 想要从头开始重新生成我所有的类，这将不起作用，因为它们不是贫血的 - 即完全 OO 模型。我还阅读了一篇文章，其中有人在继承类方面遇到问题 - Java 框架出现此类问题似乎很奇怪。