译者： idea
文档格式化通讯
将第一类切换为二进制字符串，方便快捷在互联网中展开第一类的统计数据传输。在互联网通讯中，相同的计算机系统展开互相通讯主要就的形式是将报文从两台机器统计数据传输给除此之外两台计算机系统，常用的统计数据传输协定主要就包括了TCP,UDP,HTTP等，互联网io的形式主要就主要就包括有了aio，bio，nio四种形式。
当应用流程将须要允诺的统计数据PCB好了后就须要展开切换为十进制文档格式再切换为流展开统计数据传输，当服务器端转交到流后再将统计数据导出为十进制文档格式的文本，再依照签订合同好的协定展开处置导出。最常用的情景是rpc远距初始化的这时候，对回退和参数值这时候的处置。
上边他们来逐一如是说呵呵现在较为常用的三款文档格式化控制技术架构。
jdk文档格式化
jdk另一方面便暗含文档格式化的机能，Java文档格式化API容许他们将两个第一类切换为流，并透过互联网推送，或将其取走文档或统计资料库以期今后采用，反文档格式化则是将第一类流切换为前述流程中采用的Java第一类的操作过程。
先来看一看前述的标识符事例
具体来说他们建立两个此基础的试验Person类
假如这类特定表头不期望被文档格式化该怎样处置？
这里头假如有适当的特性不期望被文档格式化操作方式不然，能采用transientURL展开润色，比如期望tel特性不期望被文档格式化，能换成这样：
private transient String tel;这样不然，该第一类在反文档格式化出来结果后，适当的特性就会为null值。
为什么要定义serialVersionUID？
文档格式化操作方式时，系统会把当前类声明的serialVersionUID写入到文档格式化文档中，用于反文档格式化时系统会去检测文档中的serialVersionUID，判断它是否与当前类的serialVersionUID一致，假如一致就说明文档格式化类的版本与当前类版本是一样的，能反文档格式化成功，否则失败。
假如没有定义serialVersionUID时
当实现当前类没有显式地定义两个serialVersionUID变量这时候，Java文档格式化机制会根据编译的Class自动生成两个serialVersionUID作文档格式化版本较为用，这种情况下，假如类信息展开修改，会导致反文档格式化时serialVersionUID与原先值无法match，反文档格式化失败。
透过jdk提升的文档格式化对其展开适当的文档格式化和反文档格式化的标识符事例
jdk文档格式化的缺点
1、无法跨语言
这一缺点几乎是致命伤害，对于跨进程的服务初始化，通常都须要考虑到相同语言的互相初始化这时候的兼容性，而这一点对于jdk文档格式化操作方式来说却无法做到。这是因为jdk文档格式化操作方式时是采用了java语言内部的私有协定，在对其他语言展开反文档格式化的这时候会有严重的阻碍。
2、文档格式化后的码流过大
jdk展开文档格式化编码后产生的二进制字符串过大，占用的存储内存空间也较高，这就导致了适当的流在互联网统计数据传输的这时候带宽占用较高，性能相较为为低下的情况。
Hessian文档格式化架构
Hessian是一款支持多种语言展开文档格式化操作方式的架构控制技术，同时在展开文档格式化后产生的码流也较小，处置统计数据的性能方面远超于java内置的jdk文档格式化形式。
相关的标识符事例：
Hessian的源码里头，核心主要就还是com.caucho.hessian.io里头的标识符，AbstractSerializer是Hessian里头的核心文档格式化类，当他们仔细查看源码的这时候就会发现hessian提供了许多种文档格式化和反序列化的类展开相同类型统计数据的处置。（我采用的是hessian4.0，因此适当的类会多很多）
在SerializerFactory里头有getSerializer和getDefaultSerializer的函数，专门用于提取这些文档格式化和反文档格式化的工具类，这样能避免在采用该工具类的这时候又要重新实例化，这些工具类都会被存储到相同的ConcurrentHashMap里头去。
ps：对于hessian3.0这时候的Serializer/Derializer实现机能没有考虑到对于异常信息展开文档格式化处置，因此假如遇到适当问题的朋友能考虑将hessian的版本提升到3.1.5以上。
Kryo文档格式化控制技术
Kryo是一种非常成熟的文档格式化实现，已经在Twitter、Groupon、 Yahoo以及多个著名开源项目（如Hive、Storm）中广泛的采用，它的性能在各个方面都比hessian2要优秀些，因此dubbo后期也开始渐渐引入了采用Kryo展开文档格式化的形式。
对于kryo的采用，他们来看一看适当标识符：
具体来说他们引入适当的依赖：
<dependency> <groupId>com.esotericsoftware</groupId> <artifactId>kryo-shaded</artifactId> <version>3.0.3</version> </dependency>然后是此基础的文档格式化和反文档格式化标识符操作方式了
ps：这里他们须要注意，Kryo不支持没有无参构造函数的第一类展开反文档格式化，因此假如某个第一类期望采用Kryo来展开文档格式化操作方式不然，须要有适当的无参构造函数才能。
由于Kryo不是线程安全，因此当他们期望采用Kryo构建的工具类这时候，须要在实例化的这时候注意线程安全的问题。标识符事例：
XStream实现第一类的文档格式化
在采用XStream展开文档格式化控制技术的实现操作过程中，类中的字符串组成了 XML 中的元素文本，而且该第一类还不须要实现 Serializable 接口。XStream不关心被文档格式化/反文档格式化的类表头的可见性，该第一类也不须要有getter/setter方法和默认的构造函数。
引入的依赖：
<dependency> <groupId>com.thoughtworks.xstream</groupId> <artifactId>xstream</artifactId> <version>1.4.9</version> </dependency>透过采用XStream来对第一类展开文档格式化和反文档格式化操作方式：
google的Protobuf
google protobuf是两个灵活的、高效的用于文档格式化统计数据的协定。相较为XML和JSON文档格式，protobuf更小、更快、更便捷。google protobuf是跨语言的，并且自带了两个编译器(protoc)，只须要用它展开编译，能编译成Java、python、C++、C#、Go等标识符，然后就能直接采用，不须要再写其他标识符，自带有导出的标识符。
protobuf相对于kryo来说具有更加高效的性能和灵活性，能够在前述采用中，当第一类文档格式化后新增了表头，在反文档格式化出来的这时候依旧能正常采用。（这一点kryo无法支持）
相同文档格式化架构的总结
目前已有的文档格式化架构还有很多在文中没有提到，日后假若在开发中遇到的这时候能适当的展开归纳总结，对照各种相同的文档格式化架构之间的特点。
