序列化与反序列化

内容来源：https://tech.meituan.com/2015/02/26/serialization-vs-deserialization.html
以下内容为适用于博主自己的笔记，想要更详细的阅读请跳转以上链接。

一、定义以及相关概念

序列化与反序列化是通信协议的一部分。比较容易理解的例子就是加密和持久化。
在OSI七层模型中表现层的作用是加密或解密，即把应用层的对象转换成一段连续的二进制串，或者反过来，把二进制串转换成应用层的对象–这两个功能就是序列化和反序列化。

• 序列化：将数据结构或对象转换为二进制串的过程
• 反序列化：将二进制串转换为转换为数据结构或对象的过程

二、序列化特性

通用性

• 技术层面：跨语言、跨平台
• 流行程度：流行度低的不稳定、不成熟、使用人数少导致学习成本高

强健性

导致协议不够强健的原因：

• 成熟度不够：采用测试阶段的协议会带来高风险
• 语言/平台的不公平性：支持更多人使用的语言/平台，还是支持更多的语言/平台

可调试性

序列化和反序列化的数据正确性和业务正确性的调试往往需要很长的时间，良好的调试机制会大大提高开发效率。序列化后的二进制串往往不具备人眼可读性，为了验证序列化结果的正确性，写入方不得同时撰写反序列化程序，或提供一个查询平台–这比较费时；另一方面，如果读取方未能成功实现反序列化，这将给问题查找带来了很大的挑战–难以定位是由于自身的反序列化程序的bug所导致还是由于写入方序列化后的错误数据所导致。对于跨公司间的调试，由于以下原因，问题会显得更严重：

第一、支持不到位，跨公司调试在问题出现后可能得不到及时的支持，这大大延长了调试周期。

第二、访问限制，调试阶段的查询平台未必对外公开，这增加了读取方的验证难度。

如果序列化后的数据人眼可读，这将大大提高调试效率， XML和JSON就具有人眼可读的优点。

性能

• 空间复杂度：序列化需要在原有的数据上加上描述字段，以为反序列化解析之用。对于海量分布式存储系统，数据量往往以TB为单位，巨大的的额外空间开销意味着高昂的成本。
• 时间复杂度：复杂的序列化协议会导致较长的解析时间。

可扩展性

具有良好扩展性的序列化协议会大大提高系统的灵活性

安全性

在序列化选型的过程中，安全性的考虑往往发生在跨局域网访问的场景。当通讯发生在公司之间或者跨机房的时候，出于安全的考虑，对于跨局域网的访问往往被限制为基于HTTP/HTTPS的80和443端口。如果使用的序列化协议没有兼容而成熟的HTTP传输层框架支持，可能会导致以下三种结果之一：

第一、因为访问限制而降低服务可用性。 第二、被迫重新实现安全协议而导致实施成本大大提高。 第三、开放更多的防火墙端口和协议访问，而牺牲安全性。

三、常见序列化和反序列化协议

XML

XML是一种常用的序列化和反序列化协议，具有跨机器，跨语言等优点。 由于XML的额外空间开销大，序列化之后的数据量剧增，对于数据量巨大序列持久化应用常景，这意味着巨大的内存和磁盘开销，不太适合XML。

SOAP

SOAP（Simple Object Access protocol） 是一种被广泛应用的，基于XML为序列化和反序列化协议的结构化消息传递协议。基于HTTP的传输协议使得其在穿越防火墙时具有良好安全特性，XML所具有的人眼可读（Human-readable）特性使得其具有出众的可调试性，互联网带宽的日益剧增也大大弥补了其空间开销大（Verbose）的缺点。对于在公司之间传输数据量相对小或者实时性要求相对低（例如秒级别）的服务是一个好的选择。

JSON

1、这种Associative array格式非常符合工程师对对象的理解。

2、它保持了XML的人眼可读（Human-readable）的优点。

3、相对于XML而言，序列化后的数据更加简洁。 来自于的以下链接的研究表明：XML所产生序列化之后文件的大小接近JSON的两倍。http://www.codeproject.com/Articles/604720/JSON-vs-XML-Some-hard-numbers-about-verbosity 。

4、它具备Javascript的先天性支持，所以被广泛应用于Web browser的应用常景中，是Ajax的事实标准协议。

5、与XML相比，其协议比较简单，解析速度比较快。

6、松散的Associative array使得其具有良好的可扩展性和兼容性。

应用场景

1、公司之间传输数据量相对小，实时性要求相对低（例如秒级别）的服务。

2、基于Web browser的Ajax请求。

3、由于JSON具有非常强的前后兼容性，对于接口经常发生变化，并对可调式性要求高的场景，例如Mobile app与服务端的通讯。

4、由于JSON的典型应用场景是JSON＋HTTP，适合跨防火墙访问

总的来说，采用JSON进行序列化的额外空间开销比较大，对于大数据量服务或持久化，这意味着巨大的内存和磁盘开销，这种场景不适合。没有统一可用的IDL降低了对参与方的约束，实际操作中往往只能采用文档方式来进行约定，这可能会给调试带来一些不便，延长开发周期。 由于JSON在一些语言中的序列化和反序列化需要采用反射机制，所以在性能要求为ms级别，不建议使用。

Protobuf

1、标准的IDL和IDL编译器，这使得其对工程师非常友好。

2、序列化数据非常简洁，紧凑，与XML相比，其序列化之后的数据量约为1/3到1/10。

3、解析速度非常快，比对应的XML快约20-100倍。

4、提供了非常友好的动态库，使用非常简介，反序列化只需要一行代码。

应用场景

Protobuf具有广泛的用户基础，空间开销小以及高解析性能是其亮点，非常适合于公司内部的对性能要求高的RPC调用。由于Protobuf提供了标准的IDL以及对应的编译器，其IDL文件是参与各方的非常强的业务约束，另外，Protobuf与传输层无关，采用HTTP具有良好的跨防火墙的访问属性，所以Protobuf也适用于公司间对性能要求比较高的场景。由于其解析性能高，序列化后数据量相对少，非常适合应用层对象的持久化场景。

它的主要问题在于其所支持的语言相对较少，另外由于没有绑定的标准底层传输层协议，在公司间进行传输层协议的调试工作相对麻烦。

四、选型建议

解析性能

序列化之空间开销

从上图可得出如下结论：

1、XML序列化（Xstream）无论在性能和简洁性上比较差。

2、Thrift与Protobuf相比在时空开销方面都有一定的劣势。

3、Protobuf和Avro在两方面表现都非常优越。

选型建议

以上描述的五种序列化和反序列化协议都各自具有相应的特点，适用于不同的场景：

1、对于公司间的系统调用，如果性能要求在100ms以上的服务，基于XML的SOAP协议是一个值得考虑的方案。

2、基于Web browser的Ajax，以及Mobile app与服务端之间的通讯，JSON协议是首选。对于性能要求不太高，或者以动态类型语言为主，或者传输数据载荷很小的运用场景，JSON也是非常不错的选择。

3、对于调试环境比较恶劣的场景，采用JSON或XML能够极大的提高调试效率，降低系统开发成本。

4、当对性能和简洁性有极高要求的场景，Protobuf，Thrift，Avro之间具有一定的竞争关系。

5、对于T级别的数据的持久化应用场景，Protobuf和Avro是首要选择。如果持久化后的数据存储在Hadoop子项目里，Avro会是更好的选择。

6、由于Avro的设计理念偏向于动态类型语言，对于动态语言为主的应用场景，Avro是更好的选择。

7、对于持久层非Hadoop项目，以静态类型语言为主的应用场景，Protobuf会更符合静态类型语言工程师的开发习惯。

8、如果需要提供一个完整的RPC解决方案，Thrift是一个好的选择。

9、如果序列化之后需要支持不同的传输层协议，或者需要跨防火墙访问的高性能场景，Protobuf可以优先考虑。