简介

结构化数据的序列化是通过网络传输信息或存储数据的关键步骤，因为这是一个非常占用CPU的任务。 实际上，在许多通信方案中，瓶颈都是数据序列化和反序列化。

开发序列化需要考虑跨平台跨语言，因为现在的系统都是在分布式系统上进行数据交换。

在Web服务和REST中使用的是基于冗长序列化格式（例如XML或JSON），它在性能上暴露出非常巨大的问题，因此人们迫切需要一种性能高的序列化方式。 因为大公司有着分布式系统和云计算，因此他们更需要一种快速二进制格式和轻量级远程过程调用（RPC）框架。 于是我们比较看到了Apache Thrift，Protobuf，Fast的诞生。

Protobuf是Google开发的一种替代方案，旨在比XML更快更小。 协议缓冲区是Google几乎所有机器间通信中使用的自定义RPC引擎的基础。

Apache Thrift是一个在Facebook公司广泛使用的RPC框架，旨在提供“可扩展的跨语言服务开发”。

eProsima Fast Buffers是另一个序列化替代产品，它是一种针对性能进行优化的开源序列化引擎，它基于CDR（通用数据表示）（OMG（对象管理组）的标准序列化格式）。

这三个序列化方案根据数据结构定义生成序列化和反序列化代码。 开发人员在文件中使用接口定义语言（IDL）定义其数据结构，然后工具将解析该文件以生成序列化和反序列化代码。

我们还将考虑eProsima动态快速缓冲区的eProsima快速缓冲区的一种变体。 在这种情况下，不需要IDL，eProsima提供一个API可以在运行时描述您的数据类型，从而动态生成（反）序列化支持。

性能比较

我们的目标是使用不同大小的简单和复杂结构来衡量对这些方案进行数据结构序列化和反序列化的总时间，以获取完整的性能报告。

我们将使用两种不同的数据结构：

简单结构：长整数字段。 复杂结构：涵盖受支持数据类型的字段。

为了获得准确的测量结果，我们执行了一百万次序列化和反序列化操作，测量了测试的总时间，以便稍后获得一个完整周期的时间。

结论：eProsima快速缓冲区在支持静态序列化的情况下更好，而在动态情况下Protubuf和eProsima相对更好一些。

总结

在所有情况下，eProsima快速缓冲区都是最快的序列化机制。因为它使用了CDR的优化实现。

这种序列化格式在DDS（一种用于非常紧急的实时应用程序的中间件）中使用。

与本文分析的其余技术相比，Apache Thrift TBinaryProtocol确实很慢。节俭格式会添加一个数字来标识每个字段，以便允许可选字段和必填字段，并键入扩展性。看来在性能方面的价格确实很高。

Google Protocol Buffers速度很快，但不如eProsima Fast Buffers快，并且类似于eProsima Dynamic Fast Buffers。

eProsima使用可变大小的整数（varint）对整数进行编码：用于编码整数的字节取决于该值。对于包含一些整数的结构，这会导致较小的编码大小，从而影响性能。

考虑到序列化，eProsima Dynamic Fast Buffers具有非常好的性能，并且反序列化逻辑不是预先编译的，而是在运行时生成的。该框架根据数据结构定义动态创建“（反）序列化字节码”，并解释该字节码。

与传统代码生成相比，解释此字节码的过程仅增加了大约20-30％的性能开销。当您在编译时不知道数据的结构（用户定义的结构，数据可视化应用程序...），或者只是不想维护外部IDL文件时，可以使用动态序列化。