序列化分理论和实践部分，理论部分描述只序列化是什么、要做什么，不关心实现（由于不考虑详细实现，以是自然不会考虑优缺陷、运用处景）；实践部分描述如何完成序列化操作，工具用什么方法表示，即把序列化从理论天下带进现实天下。序列化理论部分相称于是设计，实践部分相称于实现。
理论
序列化理论包含的三个方面序列化定义；序列化在通信协议中的地位；序列化组件1. 序列化问题是怎么产生的（序列化的定义）
互联网的发展产生了机器之间相互通讯的需求，机器之间相互通讯须要约定通讯协议，通信协议又要考虑数据如何表示、如何传输等问题。序列化便是通信协议里与数据的表示干系的那一部分协议。OSI七层协议模型中的展现层（Presentation Layer）的紧张功能是把工具转换成一段连续的二进制串，或把二进制串转换成工具–这便是序列化和反序列化。
（图片来自网络侵删）以是，序列化和反序列化的定义便是：
序列化： 将数据构造或工具转换成二进制串反序列化：将在序列化过程中所天生的二进制串转换成数据构造或工具注：不一定非要转换成二进制，只假如能传输到通信另一端都可以，例如utf-8字符串。
2. 序列化在通信协议中的地位OSI七层协议模型，序列化位于展示层（Presentation Layer）在TCP/IP协议中，序列化位于运用层。3. 序列化和反序列化的组件完全的序列化协议包含以下组件：
IDL文件（Interface description language）。参与通讯的各方须要对通讯的内容做干系约定。为了与措辞和平台无关，这个约定须要采取与编程措辞、平台无关的措辞来进行描述。这种措辞被称为接口描述措辞（IDL），采取IDL撰写的协议约定称为IDL文件。IDL Compiler：IDL文件中的约定须要一个编译器，将IDL文件转换成各编程措辞的动态库。Stub/Skeleton Lib：卖力序列化和反序列化事情的代码。Stub是一段支配在客户真个代码，一方面吸收运用层的参数，并对其序列化后通过底层协议栈发送到做事端；另一方面吸收做事端序列化后的结果数据，反序列化后交给运用层；Skeleton支配在做事端，其功能与Stub相反，从传输层吸收序列化参数，反序列化后交给做事端运用层，并将运用层的实行结果序列化后终极传送给客户端。序列化组件之间的交互关系：
序列化组件之间的交互
序列化组件的观点与数据库的干系观点类似：
实践
序列化协议的考虑点支持哪些编程措辞，能否跨措辞支持哪些平台，是否跨平台（例如支持哪些硬件架构、操作系统）盛行程度（序列化涉及通信双方，冷门的序列化协议须要的学习本钱很高）健壮性/鲁棒性成熟程度（这个协议是否经历大量全面的测试、真实天下系统的考验，长期稳定运行）是否大略易用调试难度、可读性（序列化和反序列化的数据精确性和业务精确性的调试每每须要很永劫光，良好的调试机制大大提高开拓效率。序列化后的二进制串每每不具备人眼可读性，为了验证序列化结果的精确性，写入方不得不同时撰写反序列化程序，或供应一个查询平台–这比较费时；另一方面，如果读取方未能成功实现反序列化，难以确定是自身反序列化程序bug导致的还是写入方写入了缺点序列化数据导致的。如果序列化后的数据人眼可读，这将大大提高调试效率， 例如XML和JSON就具有人眼可读的优点。）空间性能(Verbosity)，即序列化往后的数据所占用的空间大小。韶光性能（Complexity）。繁芜的序列化协议会导致较长的解析韶光，这可能使得序列化和反序列化成为系统瓶颈。扩展性/兼容性。新增字段是否随意马虎。业务系统需求的更新周期快，新需求不断呈现。如果序列化协议具有良好的可扩展性，支持自动增加新的业务字段，而不影响老的做事，这将大大供应系统的灵巧度。安全性/访问限定。例如阿里的fastjson常常有安全性问题。文档。已知的序列化协议互联网早期序列化协议有COM和CORBA。
COM紧张用于Windows平台，没有实现跨平台。COM序列化利用了编译器中的虚表，使得学习本钱很高。序列化得到的数据与编译器紧耦合，扩展属性非常麻烦。
CORBA比较好的实现了跨平台，跨措辞。COBRA的紧张问题是参与方过多，导致版本过多，版本之间兼容性差，利用繁芜晦涩。早期设计的不成熟问题导致COBRA逐渐消亡。J2SE 1.3之后的版本供应基于CORBA协议的RMI-IIOP技能，可以采取纯Java措辞进行CORBA开拓。
当前比较盛行的序列化协议有 XML、JSON、Protobuf、Hessian、Thrift、Avro。如果你还想理解更多序列化协议，参考 https://en.wikipedia.org/wiki/Comparison_of_data-serialization_formats
XML序列化协议XML是一种措辞，一种描述性的措辞，最初目标是对文档进行编码，而且哀求编码数据既能供人阅读也便于打算机处理。XML在设计的时候就考虑到可读性，它还有跨机器、跨措辞（这里指的是人类措辞）等优点。XML历史悠久，其1.0版本早在1998年就形成标准，并被广泛利用至今，以是XML是足够成熟的。既然XML能把有繁芜构造的文档编码，那么XML也可以用于工具序列化，以是把XML列为一种序列化协议（例如.NET框架和gSOAP框架就采取XML序列化）。但是XML用作序列化协议的时候，它就显得冗长繁芜。
XML具有自我描述性，XML自身就作为IDL。XML中的IDL（即XML描述格式）有两种：DTD（Document Type Definition）和XSD（XML Schema Definition）。XML在某些编程措辞里面具有非常大略易用的序列化API，无需IDL文件和第三方IDL编译器（例如Java XStream）。XML被广泛运用在各种配置文件中，例如O/R mapping、 Spring Bean Configuration File 等。
优点：跨平台、跨措辞、成熟、可读性
缺陷：繁芜冗长（空间繁芜度）
SOAP序列化协议
SOAP（Simple Object Access protocol）是一种广泛运用的，基于XML的构造化通报协议，XML被用于序列化和反序列化。SOAP支持多种传输协议，但是最常用的还是HTTP。SOAP协议的IDL是WSDL（Web Service Description Language）。
如果java运用层工具是：
用WSDL描述上述工具：
SOAP具有安全、可扩展、跨措辞、跨平台、支持多种传输协议，有广泛的群众根本，基于HTTP的传输协议使得SOAP在穿越防火墙时具有良好安全性，XML的人眼可读特性使得其具有出众的可调试性，互联网带宽的发展逐渐填补了其空间开销大的缺陷。对付在公司之间传输少量数据或实时性哀求相对低（例如秒级别），SOAP是一个好的选择。
XML空间开销大，数据量大、须要持久化运用处景不适宜用XML。XML的序列化和反序列化的空间和韶光开销都比较大，对付对性能哀求达到ms级别的做事，不推举XML。WSDL虽然具备工具描述能力，但是SOAP的利用不大略。对付习气于面向工具编程的用户，WSDL文件不直不雅观。
JSON序列化协议威信网站：http://json.com/
JSON起源于JavaScript中的”Associative array”的观点，实质便是采取”Attribute－value”办法描述工具。实际上在Javascript和PHP等弱类型措辞中，类的描述办法便是Associative array。JSON有如下优点，使得它快速成为最广泛利用的序列化协议之一：
1、这种Associative array格式匹配工程师对工具的理解。
2、它也有XML的人眼可读（Human-readable）优点。
3、序列化后的数据简洁。
4、JavaScript先天支持，以是广泛运用于Web browser的运用常景，是Ajax的事实标准协议。
5、与XML比较，其协议比较大略，解析速率比较快。
6、疏松的Associative array使得其具有良好的可扩展性和兼容性。
由于json实在是associative array，与弱类型编程措辞中的class在观点上对应，以是JSON序列化也不须要IDL。缘故原由：IDL的目的是撰写IDL文件，而IDL文件被IDL Compiler编译后产生一些代码（Stub/Skeleton），而这些代码真正卖力相应的序列化和反序列化事情。 但是由于Associative array和一样平常措辞里面的class太相似，他们之间形成了逐一对应关系，这就使得我们可以采取一套标准代码进行相应的转化。对付自身支持Associative array的弱类型措辞，措辞自身就具备操作JSON序列化后的数据的能力；对付Java这强类型措辞，可以用反射办理。
JSON在很多运用处景中可以替代XML，更简洁且解析速率更快。范例运用处景包括：
公司之间传输数据量相对小，实时性哀求相对低（例如秒级别）的做事。基于Web browser的Ajax要求。由于JSON具有非常强的前后兼容性，以是它适用于：接口常常发生变革，对可调式性哀求高的场景，例如Mobile app与做事真个通讯（移动APP为什么要用JSON协议与做事端交互）。JSON的范例运用处景是JSON＋HTTP，适宜跨防火墙访问。总体看，JSON序列化的额外空间开销也比较大（但是比XML小多了），不适宜数据量大或须要持久化的场景。没有统一的IDL降落了对参与方的约束，实际操作中每每只能采取文档办法来进行约定，这可能会给调试带来一些不便，延长开拓周期。由于JSON在一些措辞中的序列化和反序列化须要反射机制，以是性能哀求ms级别的系统不建议利用。
Thrift序列化协议Thrift是Facebook开拓的一个RPC框架，知足了大数据量、分布式、跨措辞、跨平台数据通讯的需求。Thrift内部有一个自定义的序列化协议，即Thrift序列化协议。
优点：相对付JSON和XML，Thrift在空间开销和解析性能上有较大提升，适用于性能哀求高的系统；它支持多种编程措辞，数据类型丰富，对付数据字段的增删有较强的兼容性。
缺陷：thrift序列化被嵌入到thrift框架内部，然而Thrift框架没有对外供应thrift序列化和反序列化的接口，文档匮乏，用起来比较困难。Thrift序列化之后得到的数据是Binary数组，不具有可读性，调试相对困难。Thrift的序列化和框架紧耦合，无法支持向持久层直接读写数据，不适宜用于数据持久化的场景。
Protobuf序列化协议
威信网站：https://developers.google.com/protocol-buffers
Protobuf具备序列化协议的浩瀚精良特色：
供应了标准的IDL和IDL编译器，对工程师非常友好。序列化数据简洁紧凑，其序列化之后的数据量约为XML的1/3到1/10。解析速率非常快，比XML快约20-100倍。供应了友好的动态库，利用非常简洁，反序列化只须要一行代码。Protobuf IDL文件对付各个参与方业务产生了强力的约束Protobuf与传输层无关，采取HTTP，具有良好的跨防火墙访问属性。Protobuf是一个纯展示层协议，可以用于多种传输层协议；Protobuf文档也非常完善。目前仅支持Java、C++、Python三种编程措辞。其余Protobuf支持的数据类型较少，不支持常量。
以是Protobuf适用于跨公司、性能哀求高的RPC调用运用处景。基于相同的缘故原由，Protobuf也适宜用于工具的持久化。
缺陷：支持措辞较少，没有绑定标准传输层协议，跨公司进行传输层协议调试相对麻烦。
Google gPRC框架已采取Protobuf序列化协议，可以参考。
Hessian序列化协议
hessian也是一种常见的序列化协议，常常在RPC框架中利用，例如Dubbo、Pigeon等框架都支持Hessian，乃至常常被RPC框架用作默认序列化方案。
Avro序列化协议Avro是Apache Hadoop的子项目，办理了JSON的冗长和没有IDL的问题。Avro供应两种序列化格式：JSON格式和Binary格式。Binary格式在空间开销和解析性能方面可以和Protobuf媲美，JSON格式方便调试。Avro支持的数据类型非常丰富，包括C++措辞里面的union类型。Avro支持JSON格式的IDL和类似于Thrift和Protobuf的IDL（实验阶段），这两者之间可以互转。Schema可以在传输数据的同时发送，加上JSON的自我描述属性，使得Avro非常适宜动态类型措辞。Avro在做文件持久化的时候，一样平常会和Schema一起存储，以是Avro序列化文件自身具有自我描述属性，以是适宜做Hive、Pig和MapReduce的持久化数据格式。对付不同版本的Schema，在进行RPC调用的时候，做事端和客户端可以在握手阶段对Schema进行相互确认，提高了数据解析的速率。Avro解析性能高且序列化数据简洁，适宜高性能序列化做事。
序列化协议Benchmark
数据 https://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking
解析性能
序列化之空间开销
1、XML序列化（Xstream）无论在性能和简洁性上都比较差。
2、Thrift与Protobuf比较在时空开销方面都有一定劣势。
3、Protobuf和Avro在两方面表现都非常优胜。
序列化协议的选型以上几种序列化协议各自具有特点，适用于不同场景：
1、公司之间系统调用，性能哀求100ms，基于XML的SOAP协议是一个值得考虑的方案。
2、基于Web browser的Ajax，以及移动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可以优先考虑。
参考资料https://en.wikipedia.org/wiki/Serializationhttp://www.codeproject.com/Articles/604720/JSON-vs-XML-Some-hard-numbers-about-verbosityhttps://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarkinghttp://en.wikipedia.org/wiki/Serializationhttp://en.wikipedia.org/wiki/Soaphttp://en.wikipedia.org/wiki/XMLhttp://en.wikipedia.org/wiki/JSONhttp://avro.apache.org/http://www.oracle.com/technetwork/java/rmi-iiop-139743.htmlhttp://json.com/http://hessian.caucho.com/https://dubbo.apache.org/zh/docs/v2.7/user/references/protocol/hessian/https://en.wikipedia.org/wiki/Comparison_of_data-serialization_formatshttps://code.google.com/archive/p/thrift-protobuf-compare/wikis/Benchmarking.wiki
