系统架构札记

什么是高内聚、低耦合？

    起因：模块独立性指每个模块只完成系统要求的独立子功能，并且与其他模块的联系最少且接口简单，两个定性的度量标准――耦合性和内聚性。

    耦合性也称块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量。模块之间联系越紧密，其耦合性就越强，模块的独立性则越差。模块间耦合高低取决于模块间接口的复杂性、调用的方式及传递的信息。

    耦合性分类(低――高):无直接耦合;数据耦合;标记耦合;控制耦合;公共耦合;内容耦合;

1 无直接耦合:

2 数据耦合:指两个模块之间有调用关系，传递的是简单的数据值，相当于高级语言的值传递;

3 标记耦合:指两个模块之间传递的是数据结构，如高级语言中的数组名、记录名、文件名等这些名字即标记，其实传递的是这个数据结构的地址;

4 控制耦合:指一个模块调用另一个模块时，传递的是控制变量（如开关、标志等），被调模块通过该控制变量的值有选择地执行块内某一功能;

5 公共耦合:指通过一个公共数据环境相互作用的那些模块间的耦合。公共耦合的复杂程序随耦合模块的个数增加而增加。

6 内容耦合:这是最高程度的耦合，也是最差的耦合。当一个模块直接使用另一个模块的内部数据，或通过非正常入口而转入另一个模块内部。

 

    内聚性又称块内联系。指模块的功能强度的度量，即一个模块内部各个元素彼此结合的紧密程度的度量。若一个模块内各元素（语名之间、程序段之间）联系的越紧密，则它的内聚性就越高。

    内聚性匪类(低――高):偶然内聚;逻辑内聚;时间内聚;通信内聚;顺序内聚;功能内聚;

1 偶然内聚:指一个模块内的各处理元素之间没有任何联系。

2 逻辑内聚:指模块内执行几个逻辑上相似的功能，通过参数确定该模块完成哪一个功能。

3 时间内聚:把需要同时执行的动作组合在一起形成的模块为时间内聚模块。

4 通信内聚:指模块内所有处理元素都在同一个数据结构上操作（有时称之为信息内聚），或者指各处理使用相同的输入数据或者产生相同的输出数据。

5 顺序内聚:指一个模块中各个处理元素都密切相关于同一功能且必须顺序执行，前一功能元素输出就是下一功能元素的输入。

6 功能内聚:这是最强的内聚，指模块内所有元素共同完成一个功能，缺一不可。与其他模块的耦合是最弱的。

 

    耦合性与内聚性是模块独立性的两个定性标准，将软件系统划分模块时，尽量做到高内聚低耦合，提高模块的独立性，为设计高质量的软件结构奠定基础。

 

    有个例子很容易明白：一个程序有50个函数，这个程序执行得非常好；然而一旦你修改其中一个函数，其他49个函数都需要做修改，这就是高耦合的后果。

一旦你理解了它，你编写概要设计的时候设计类或者模块自然会考虑到“高内聚，低耦合”。

序列化和反序列化

　摘要

　　序列化和反序列化几乎是工程师们每天都要面对的事情，但是要精确掌握这两个概念并不容易：一方面，它们往往作为框架的一部分出现而湮没在框架之中；另一方面，它们会以其他更容易理解的概念出现，例如加密、持久化。然而，序列化和反序列化的选型却是系统设计或重构一个重要的环节，在分布式、大数据量系统设计里面更为显著。恰当的序列化协议不仅可以提高系统的通用性、强健性、安全性、优化系统性能，而且会让系统更加易于调试、便于扩展。本文从多个角度去分析和讲解“序列化和反序列化”，并对比了当前流行的几种序列化协议，期望对读者做序列化选型有所帮助。

　　简介

　　文章作者服务于美团推荐与个性化组，该组致力于为美团用户提供每天billion级别的高质量个性化推荐以及排序服务。从Terabyte级别的用户行为数据，到Gigabyte级别的Deal/Poi数据；从对实时性要求毫秒以内的用户实时地理位置数据，到定期后台job数据，推荐与重排序系统需要多种类型的数据服务。推荐与重排序系统客户包括各种内部服务、美团客户端、美团网站。为了提供高质量的数据服务，为了实现与上下游各系统进行良好的对接，序列化和反序列化的选型往往是我们做系统设计的一个重要考虑因素。

　　本文内容按如下方式组织：

• 第一部分给出了序列化和反序列化的定义，以及其在通讯协议中所处的位置。
• 第二部分从使用者的角度探讨了序列化协议的一些特性。
• 第三部分描述在具体的实施过程中典型的序列化组件，并与数据库组建进行了类比。
• 第四部分分别讲解了目前常见的几种序列化协议的特性，应用场景，并对相关组件进行举例。
• 最后一部分，基于各种协议的特性，以及相关benchmark数据，给出了作者的技术选型建议。

　　一、定义以及相关概念

　　互联网的产生带来了机器间通讯的需求，而互联通讯的双方需要采用约定的协议，序列化和反序列化属于通讯协议的一部分。通讯协议往往采用分层模型，不同模型每层的功能定义以及颗粒度不同，例如：TCP/IP协议是一个四层协议，而OSI模型却是七层协议模型。在OSI七层协议模型中展现层（Presentation Layer）的主要功能是把应用层的对象转换成一段连续的二进制串，或者反过来，把二进制串转换成应用层的对象--这两个功能就是序列化和反序列化。一般而言，TCP/IP协议的应用层对应与OSI七层协议模型的应用层，展示层和会话层，所以序列化协议属于TCP/IP协议应用层的一部分。本文对序列化协议的讲解主要基于OSI七层协议模型。

• 序列化：将数据结构或对象转换成二进制串的过程
• 反序列化：将在序列化过程中所生成的二进制串转换成数据结构或者对象的过程

　　数据结构、对象与二进制串

　　不同的计算机语言中，数据结构，对象以及二进制串的表示方式并不相同。

　　数据结构和对象：对于类似Java这种完全面向对象的语言，工程师所操作的一切都是对象（Object），来自于类的实例化。在Java语言中最接近数据结构的概念，就是POJO（Plain Old Java Object）或者Javabean－－那些只有setter/getter方法的类。而在C++这种半面向对象的语言中，数据结构和struct对应，对象和class对应。

　　二进制串：序列化所生成的二进制串指的是存储在内存中的一块数据。C++语言具有内存操作符，所以二进制串的概念容易理解，例如，C++语言的字符串可以直接被传输层使用，因为其本质上就是以'\0'结尾的存储在内存中的二进制串。在Java语言里面，二进制串的概念容易和String混淆。实际上String是Java的一等公民，是一种特殊对象（Object）。对于跨语言间的通讯，序列化后的数据当然不能是某种语言的特殊数据类型。二进制串在Java里面所指的是byte[]，byte是Java的8中原生数据类型之一（Primitive data types）。

　　二、序列化协议特性

　　每种序列化协议都有优点和缺点，它们在设计之初有自己独特的应用场景。在系统设计的过程中，需要考虑序列化需求的方方面面，综合对比各种序列化协议的特性，最终给出一个折衷的方案。

　　通用性

　　通用性有两个层面的意义：

　　第一、技术层面，序列化协议是否支持跨平台、跨语言。如果不支持，在技术层面上的通用性就大大降低了。

　　第二、流行程度，序列化和反序列化需要多方参与，很少人使用的协议往往意味着昂贵的学习成本；另一方面，流行度低的协议，往往缺乏稳定而成熟的跨语言、跨平台的公共包。

　　强健性/鲁棒性

　　以下两个方面的原因会导致协议不够强健：

　　第一、成熟度不够，一个协议从制定到实施，到最后成熟往往是一个漫长的阶段。协议的强健性依赖于大量而全面的测试，对于致力于提供高质量服务的系统，采用处于测试阶段的序列化协议会带来很高的风险。

　　第二、语言/平台的不公平性。为了支持跨语言、跨平台的功能，序列化协议的制定者需要做大量的工作；但是，当所支持的语言或者平台之间存在难以调和的特性的时候，协议制定者需要做一个艰难的决定--支持更多人使用的语言/平台，亦或支持更多的语言/平台而放弃某个特性。当协议的制定者决定为某种语言或平台提供更多支持的时候，对于使用者而言，协议的强健性就被牺牲了。

　　可调试性/可读性

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

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

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

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

　　性能

　　性能包括两个方面，时间复杂度和空间复杂度：

　　第一、空间开销（Verbosity），序列化需要在原有的数据上加上描述字段，以为反序列化解析之用。如果序列化过程引入的额外开销过高，可能会导致过大的网络，磁盘等各方面的压力。对于海量分布式存储系统，数据量往往以TB为单位，巨大的的额外空间开销意味着高昂的成本。

　　第二、时间开销（Complexity），复杂的序列化协议会导致较长的解析时间，这可能会使得序列化和反序列化阶段成为整个系统的瓶颈。

　　可扩展性/兼容性

　　移动互联时代，业务系统需求的更新周期变得更快，新的需求不断涌现，而老的系统还是需要继续维护。如果序列化协议具有良好的可扩展性，支持自动增加新的业务字段，而不影响老的服务，这将大大提供系统的灵活度。

　　安全性/访问限制

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

　　第一、因为访问限制而降低服务可用性。

　　第二、被迫重新实现安全协议而导致实施成本大大提高。

　　第三、开放更多的防火墙端口和协议访问，而牺牲安全性。

　　三、序列化和反序列化的组件

　　典型的序列化和反序列化过程往往需要如下组件：

• IDL（Interface description language）文件：参与通讯的各方需要对通讯的内容需要做相关的约定（Specifications）。为了建立一个与语言和平台无关的约定，这个约定需要采用与具体开发语言、平台无关的语言来进行描述。这种语言被称为接口描述语言（IDL），采用IDL撰写的协议约定称之为IDL文件。
• IDL Compiler：IDL文件中约定的内容为了在各语言和平台可见，需要有一个编译器，将IDL文件转换成各语言对应的动态库。
• Stub/Skeleton Lib：负责序列化和反序列化的工作代码。Stub是一段部署在分布式系统客户端的代码，一方面接收应用层的参数，并对其序列化后通过底层协议栈发送到服务端，另一方面接收服务端序列化后的结果数据，反序列化后交给客户端应用层；Skeleton部署在服务端，其功能与Stub相反，从传输层接收序列化参数，反序列化后交给服务端应用层，并将应用层的执行结果序列化后最终传送给客户端Stub。
• Client/Server：指的是应用层程序代码，他们面对的是IDL所生存的特定语言的class或struct。
• 底层协议栈和互联网：序列化之后的数据通过底层的传输层、网络层、链路层以及物理层协议转换成数字信号在互联网中传递。

　　序列化组件与数据库访问组件的对比

　　数据库访问对于很多工程师来说相对熟悉，所用到的组件也相对容易理解。下表类比了序列化过程中用到的部分组件和数据库访问组件的对应关系，以便于大家更好的把握序列化相关组件的概念。

序列化组件数据库组件说明

IDLDDL 用于建表或者模型的语言

DL file DB Schema表创建文件或模型文件

Stub/Skeleton lib O/R mapping将class和Table或者数据模型进行映射

　　四、几种常见的序列化和反序列化协议

　　互联网早期的序列化协议主要有COM和CORBA。

　　COM主要用于Windows平台，并没有真正实现跨平台，另外COM的序列化的原理利用了编译器中虚表，使得其学习成本巨大（想一下这个场景，工程师需要是简单的序列化协议，但却要先掌握语言编译器）。由于序列化的数据与编译器紧耦合，扩展属性非常麻烦。

　　CORBA是早期比较好的实现了跨平台，跨语言的序列化协议。COBRA的主要问题是参与方过多带来的版本过多，版本之间兼容性较差，以及使用复杂晦涩。这些政治经济，技术实现以及早期设计不成熟的问题，最终导致COBRA的渐渐消亡。J2SE 1.3之后的版本提供了基于CORBA协议的RMI-IIOP技术，这使得Java开发者可以采用纯粹的Java语言进行CORBA的开发。

　　这里主要介绍和对比几种当下比较流行的序列化协议，包括XML、JSON、Protobuf、Thrift和Avro。

　　一个例子

　　如前所述，序列化和反序列化的出现往往晦涩而隐蔽，与其他概念之间往往相互包容。为了更好了让大家理解序列化和反序列化的相关概念在每种协议里面的具体实现，我们将一个例子穿插在各种序列化协议讲解中。在该例子中，我们希望将一个用户信息在多个系统里面进行传递；在应用层，如果采用Java语言，所面对的类对象如下所示：

class Address

{

    private String city;

    private String postcode;

    private String street;

}

public class UserInfo

{

    private Integer userid;

    private String name;

    private List<Address> address;

}

　　XML&SOAP

　　XML是一种常用的序列化和反序列化协议，具有跨机器，跨语言等优点。 XML历史悠久，其1.0版本早在1998年就形成标准，并被广泛使用至今。XML的最初产生目标是对互联网文档（Document）进行标记，所以它的设计理念中就包含了对于人和机器都具备可读性。但是，当这种标记文档的设计被用来序列化对象的时候，就显得冗长而复杂（Verbose and Complex）。 XML本质上是一种描述语言，并且具有自我描述（Self-describing）的属性，所以XML自身就被用于XML序列化的IDL。标准的XML描述格式有两种：DTD（Document Type Definition）和XSD（XML Schema Definition）。作为一种人眼可读（Human-readable）的描述语言，XML被广泛使用在配置文件中，例如O/R mapping、 Spring Bean Configuration File等。

　　SOAP（Simple Object Access protocol）是一种被广泛应用的，基于XML为序列化和反序列化协议的结构化消息传递协议。SOAP在互联网影响如此大，以至于我们给基于SOAP的解决方案一个特定的名称--Web service。SOAP虽然可以支持多种传输层协议，不过SOAP最常见的使用方式还是XML+HTTP。SOAP协议的主要接口描述语言（IDL）是WSDL（Web Service Description Language）。SOAP具有安全、可扩展、跨语言、跨平台并支持多种传输层协议。如果不考虑跨平台和跨语言的需求，XML的在某些语言里面具有非常简单易用的序列化使用方法，无需IDL文件和第三方编译器，例如Java＋XStream。

　　自我描述与递归

　　SOAP是一种采用XML进行序列化和反序列化的协议，它的IDL是WSDL.而WSDL的描述文件是XSD，而XSD自身是一种XML文件。这里产生了一种有趣的在数学上称之为“递归”的问题，这种现象往往发生在一些具有自我属性（Self-description）的事物上。

　　IDL文件举例

　　采用WSDL描述上述用户基本信息的例子如下：

<xsd:complexType name='Address'>

     <xsd:attribute name='city' type='xsd:string' />

     <xsd:attribute name='postcode' type='xsd:string' />

     <xsd:attribute name='street' type='xsd:string' />

</xsd:complexType>

<xsd:complexType name='UserInfo'>

     <xsd:sequence>

     <xsd:element name='address' type='tns:Address'/>

     <xsd:element name='address1' type='tns:Address'/> 

     </xsd:sequence>

     <xsd:attribute name='userid' type='xsd:int' />

     <xsd:attribute name='name' type='xsd:string' /> 

</xsd:complexType>

　　典型应用场景和非应用场景

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

　　由于XML的额外空间开销大，序列化之后的数据量剧增，对于数据量巨大序列持久化应用常景，这意味着巨大的内存和磁盘开销，不太适合XML。另外，XML的序列化和反序列化的空间和时间开销都比较大，对于对性能要求在ms级别的服务，不推荐使用。WSDL虽然具备了描述对象的能力，SOAP的S代表的也是simple，但是SOAP的使用绝对不简单。对于习惯于面向对象编程的用户，WSDL文件不直观。

　　JSON（Javascript Object Notation）

　　JSON起源于弱类型语言Javascript，它的产生来自于一种称之为"Associative array"的概念，其本质是就是采用"Attribute－value"的方式来描述对象。实际上在Javascript和PHP等弱类型语言中，类的描述方式就是Associative array。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使得其具有良好的可扩展性和兼容性。

　　IDL悖论

　　JSON实在是太简单了，或者说太像各种语言里面的类了，所以采用JSON进行序列化不需要IDL。这实在是太神奇了，存在一种天然的序列化协议，自身就实现了跨语言和跨平台。然而事实没有那么神奇，之所以产生这种假象，来自于两个原因：

　　第一、Associative array在弱类型语言里面就是类的概念，在PHP和Javascript里面Associative array就是其class的实际实现方式，所以在这些弱类型语言里面，JSON得到了非常良好的支持。

　　第二、IDL的目的是撰写IDL文件，而IDL文件被IDL Compiler编译后能够产生一些代码（Stub/Skeleton），而这些代码是真正负责相应的序列化和反序列化工作的组件。但是由于Associative array和一般语言里面的class太像了，他们之间形成了一一对应关系，这就使得我们可以采用一套标准的代码进行相应的转化。对于自身支持Associative array的弱类型语言，语言自身就具备操作JSON序列化后的数据的能力；对于Java这强类型语言，可以采用反射的方式统一解决，例如Google提供的Gson。

　　典型应用场景和非应用场景

　　JSON在很多应用场景中可以替代XML，更简洁并且解析速度更快。典型应用场景包括：

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

　　2、基于Web browser的Ajax请求。

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

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

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

　　IDL文件举例

　　以下是UserInfo序列化之后的一个例子：

{"userid":1,"name":"messi","address":[{"city":"北京","postcode":"1000000","street":"wangjingdonglu"}]}

　　Thrift

　　Thrift是Facebook开源提供的一个高性能，轻量级RPC服务框架，其产生正是为了满足当前大数据量、分布式、跨语言、跨平台数据通讯的需求。但是，Thrift并不仅仅是序列化协议，而是一个RPC框架。相对于JSON和XML而言，Thrift在空间开销和解析性能上有了比较大的提升，对于对性能要求比较高的分布式系统，它是一个优秀的RPC解决方案；但是由于Thrift的序列化被嵌入到Thrift框架里面，Thrift框架本身并没有透出序列化和反序列化接口，这导致其很难和其他传输层协议共同使用（例如HTTP）。

　　典型应用场景和非应用场景

　　对于需求为高性能，分布式的RPC服务，Thrift是一个优秀的解决方案。它支持众多语言和丰富的数据类型，并对于数据字段的增删具有较强的兼容性。所以非常适用于作为公司内部的面向服务构建（SOA）的标准RPC框架。

　　不过Thrift的文档相对比较缺乏，目前使用的群众基础相对较少。另外由于其Server是基于自身的Socket服务，所以在跨防火墙访问时，安全是一个顾虑，所以在公司间进行通讯时需要谨慎。另外Thrift序列化之后的数据是Binary数组，不具有可读性，调试代码时相对困难。最后，由于Thrift的序列化和框架紧耦合，无法支持向持久层直接读写数据，所以不适合做数据持久化序列化协议。

　　IDL文件举例

struct Address

{ 

    1: required string city;

    2: optional string postcode;

    3: optional string street;

} 

struct UserInfo

{ 

    1: required string userid;

    2: required i32 name;

    3: optional list<Address> address;

}

　　Protobuf

　　Protobuf具备了优秀的序列化协议的所需的众多典型特征：

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

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

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

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

　　Protobuf是一个纯粹的展示层协议，可以和各种传输层协议一起使用；Protobuf的文档也非常完善。但是由于Protobuf产生于Google，所以目前其仅仅支持Java、C++、Python三种语言。另外Protobuf支持的数据类型相对较少，不支持常量类型。由于其设计的理念是纯粹的展现层协议（Presentation Layer），目前并没有一个专门支持Protobuf的RPC框架。

　　典型应用场景和非应用场景

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

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

　　IDL文件举例

message Address

{

    required string city=1;

        optional string postcode=2;

        optional string street=3;

}

message UserInfo

{

    required string userid=1;

    required string name=2;

    repeated Address address=3;

}

　　Avro

　　Avro的产生解决了JSON的冗长和没有IDL的问题，Avro属于Apache Hadoop的一个子项目。 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解析性能高并且序列化之后的数据非常简洁，比较适合于高性能的序列化服务。

　　由于Avro目前非JSON格式的IDL处于实验阶段，而JSON格式的IDL对于习惯于静态类型语言的工程师来说不直观。

　　IDL文件举例

protocol Userservice {

  record Address {

   string city;

   string postcode;

   string street;

  }  

  record UserInfo {

   string name;

   int userid;

   array<Address> address = [];

  }

}

　　所对应的JSON Schema格式如下：

{

  "protocol" : "Userservice",

  "namespace" : "org.apache.avro.ipc.specific",

  "version" : "1.0.5",

  "types" : [ {

    "type" : "record",

    "name" : "Address",

    "fields" : [ {

      "name" : "city",

      "type" : "string"

    }, {

      "name" : "postcode",

      "type" : "string"

    }, {

      "name" : "street",

      "type" : "string"

    } ]

  }, {

    "type" : "record",

    "name" : "UserInfo",

    "fields" : [ {

      "name" : "name",

      "type" : "string"

    }, {

      "name" : "userid",

      "type" : "int"

    }, {

      "name" : "address",

      "type" : {

        "type" : "array",

        "items" : "Address"

      },

      "default" : [ ]

    } ]

  } ],

  "messages" : { }

}

　　五、Benchmark以及选型建议

　　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，以及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可以优先考虑。

　　参考文献：

　　http://www.codeproject.com/Articles/604720/JSON-vs-XML-Some-hard-numbers-about-verbosity

　　https://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking

　　http://en.wikipedia.org/wiki/Serialization

　　http://en.wikipedia.org/wiki/Soap

　　http://en.wikipedia.org/wiki/XML

　　http://en.wikipedia.org/wiki/JSON

　　http://avro.apache.org/

　　http://www.oracle.com/technetwork/java/rmi-iiop-139743.html

持久化

持久化是将程序数据在持久状态和瞬时状态间转换的机制。通俗的讲，就是瞬时数据（比如内存中的数据，是不能永久保存的）持久化为持久数据（比如持久化至数据库中，能够长久保存）。

中文名

持久化

外文名

Persistence

方    法

通过逻辑处理接口储存数据

理    解

持久化是针对时间来说的

目录

• 1 定义
• 2 理解
• 3 二个层面
• ▪应用层
• ▪系统层
• 4 特点
• ▪对象
• ▪市场
• ▪序列化
• 5 意义
• ▪兴起原因
• ▪运用
• 6 相关实现
• ▪ Hibernate
• ▪ JPA

定义

编辑

持久化（Persistence），即把数据（如内存中的对象）保存到可永久保存的存储设备中（如磁盘）。持久化的主要应用是将内存中的对象存储在的数据库中，或者存储在磁盘文件中、XML数据文件中等等。

持久化是将程序数据在持久状态和瞬时状态间转换的机制。

JDBC就是一种持久化机制。文件IO也是一种持久化机制。

日常持久化的方法

将鲜肉冷藏，吃的时候再解冻的方法也是。

将水果做成罐头的方法也是。

将人的脏器迅速冷冻，运输，然后解冻给人移植的技术也是。[1] 

理解

编辑

我们这样理解：

在一定周期内保持不变就是持久化,持久化是针对时间来说的。

数据库中的数据就是持久化了的数据,只要你不去删除或修改。

比如在IE浏览器中一次Session会话中Session对象变量也是不变的,是Session容器中持久化。

对象持久化的方式有很多种,根据周期不同有,page,Session,Application。

对象序列化机制对于需要将对象的状态保存到文件中，而后能够通过读入对象状态来重新构造对象，恢复程序状态,

对象序列化的过程是对象持久化的方法之一,把对象保存到文件中。

二个层面

编辑

简单的理解持久化可以在二个层面：应用层和系统层、

应用层

如果关闭(shutdown)你的应用然后重新启动则先前的数据依然存在。

系统层

如果关闭(shutdown)你的系统（电脑）然后重新启动则先前的数据依然存在。

特点

编辑

对象

持久化是一种对象服务，就是把内存中的对象保存到外存中，让以后能够取回。需要实现至少3个接口：

void Save(object o) 把一个对象保存到外存中

Object Load(object oid) 通过对象标识从外存中取回对象

boolExists(object oid)检查外存中是否存在某个对象

为什么需要持久化服务呢？那是由于内存本身的缺陷引起的：

内存掉电后数据会丢失，但有一些对象是无论如何都不能丢失的，比如银行账号，遗憾的是，人们还无法保证内存永不掉电。

内存过于昂贵，与硬盘、磁带、光盘等外存相比，内存的价格要高2~3个数量级，而且维持成本也高，至少需要一直供电吧。所以即使对象不需要永久保存，也会因为内存的容量限制不能一直呆在内存中，需要持久化来缓存到外存。

市场

既然持久化服务在看得到的未来还有市场，我们就来看看如何构建一个好的持久化框架，框架是否真的好在于如何在扩展性、缩放性、重用性上取得良好的平衡：

扩展性，如果一个持久性框架不能支持用户定义的类型，显然不是一个好的框架。

缩放性，保存和取回对象都需要耗费cpu、带宽、时间资源，哪一个消耗太多都不能接受。

重用性是我们建立框架的初衷，就是通过框架能够减少一些编码和测试的工作量。

这几个需求往往是互相冲突的，所以关键是平衡。

序列化

我们先跳开一下，看看另一个类似的有用概念：序列化也是一种对象服务，就是把内存中的对象序列化成流、或者把流反序列化成对象。需要实现2个接口：

voidSerialize(Streamstream,object o)把对象序列化到流中

object Deserialize(Stream stream)把流反序列化成对象

序列化和持久化很相似，有些人甚至混为一谈，其实还是有区别的，序列化是为了解决对象的传输问题，传输可以在线程之间、进程之间、内存外存之间、主机之间进行。我之所以在这里提到序列化，是因为我们可以利用序列化来辅助持久化，可以说凡是可以持久化的对象都可以序列化，因为序列化相对容易一些（也不是很容易），所以主流的软件基础设施，比如.net和java，已经把序列化的框架完成了。

持久化方案可以分为关系数据库方案、文件方案、对象数据库方案、xml数据库方案，现今主流的持久化方案是关系数据库方案，关系数据库方案不仅解决了并发的问题，更重要的是，关系数据库还提供了持久化服务之外的价值：统计分析功能。刚才我说到，凡是可以序列化的对象都可以持久化，极端的说，我们可以只建立一个表Object(OID,Bytes)，但基本上没有人这么做，因为一旦这样，我们就失去了关系数据库额外的统计分析功能。

关系数据库和面向对象之间有一条鸿沟，因为二者模式不匹配，所以就存在一个OR映射问题。

意义

编辑

兴起原因

当持久化兴起的时候，逐渐形成了实体层这个概念了。hibernate[2]  ,jdo,以及博客园的nbear都可谓是大名鼎鼎！有的公司不使用这种ORM框架,他们使用一些自动生成工具生成实体(例如用Codesmith生成)，并生成和该表对应的业务逻辑，于是乎感觉我们的程序好像一下子全都写好了，下一步就轻松了，我们只要扩展业务即可了!莫非这样真是那么方便了？在维护上真的是最便捷吗？其它的持久层解决方案不敢说，但至少我觉得像orm的鼻祖hibernate那种开发机制,在维护还是相当之麻烦呀！一个实体还得对应一个xml文件（虽说这些都可以自动生成）,但是你深入项目的时候去想想，我们的业务真能一切都可以定下来吗？人的思想总是在变的，客户的需求就更难以琢磨了！哪天我们要给数据库加个字段，你想想你必须要走几步改动？首先我们必须重新生成xml和实体，然后我们必须还得在业务逻辑中增加代码，还得在视图层加一个界面(如加一个input输入框等)！讲实话，加一个字段对这种orm框架的改动还是最少的，哪天假如说我们修改了哪个字段的名称、修改了字段类型，你想想，天呐！很难想像，和这个字段关联的程序都得改动!如果名称改了，ok，你可以全部替换它的原先名称，改成你新的名称。那类型改了呢？没办法只能手工一个个改掉所有的赋值的类型吧？视图层、控制层中的验证（js验证,业务验证）、逻辑层、实体层，xml配置等等都必须动。搞啥个hsq，这和sql不差不多了吗（虽然说hsq，抽象了数据库模型）？不过我想没有程序员不懂sql的吧？况且hsq对复杂的语句还是会力不从心的吧！

运用

运用ORM框架势必会运用大量的反射，代价是牺牲性能。当然现今的各种ORM框架都在尝试使用各种方法来减轻这块（LazyLoad，Cache），效果还是很显著的。可是我们牺牲了这么大的性能，而且我是觉得在维护上ORM还是最便捷。

真不知道为啥像hibernate这样的框架还有一个xml配置文件？如果我真ORM的话，我不能把这些数据关系缓存起来，动态取关系不就行了吗？这样我不更灵活了吗？

当然使用ORM也有它的活的活之处，在维护上那种自动生成的方式(petshop模式)比使用ORM框架维护量上更大一些，那种构架如果是每个数据操作对应一个存储过程的改动会更会让人晕头转向的。其构架大致如以下描述：

主要由BLL,MODEL,DAL三层构架方式实现，BLL存放的是相关业务，MODEL是相关的数据库表格实体，DAL业务的SQL语句（或存储过程参数）.为了松散耦合，在BLL层和DAL层中间加入了工厂层(Factory)，其作用是方便DAL层的载体变动(如把Sqlserver改成Mysql),在DAL层有一个setObject数据库字段到实体属性设置,便于数据库表格映射成实体。

程序编写的最大问题就是耦合高，怎么降耦也是开发的一个重中之重。以上述的程序构架来看，如果我改动了数据库中的其中一个表格的某个字段，程序改动的至少就有三层。如果再按照自动生成方式那种看，DAL中的update,insert,select, setObject都需要改动，如果存在存储过程的话，像get,getAll,update,insert都必须改动，想象一下这里改动地方有几处了？而且还需改动Model层，修改量之大可见一斑。当然我们这里可以用自动生成工具生成并替换，可又有谁知道这里面的替换工作量多少?

总之，提倡"高内聚，低耦合"是构架永恒的话题，寻找便捷亦是构架的终级目标。

相关实现

编辑

Hibernate

hibernate为应用程序提供了高效的O/R关系映射和查询服务，为面向对象的领域模型到传统的关系型数据库的映射，提供了一个使用方便的框架。

JPA

JPA（Java Persistense API）是EJB3.0的一部分，为其提供了一套O/R关系映射的API，但不仅限于EJB中使用，它也可以在web应用或者应用程序客户端中被使用，甚至在Java桌面程序中被使用。

1.什么是持久化？

本人找了好多文章都没有找到满意的答案，最后是从孙卫琴写的《精通Hibernate：Java对象持久化技术详解》中，看到如下的解释，感觉还是比较完整的。摘抄如下：

狭义的理解: “持久化”仅仅指把域对象永久保存到数据库中；广义的理解,“持久化”包括和数据库相关的各种操作(持久化就是将有用的数据以某种技术保存起来,将来可以再次取出来应用,数据库技术,将内存数据一文件的形式保存在永久介质中(磁盘等)都是持久化的例子.)。

●     保存：把域对象永久保存到数据库。

●     更新：更新数据库中域对象的状态。

●     删除：从数据库中删除一个域对象。

●     加载：根据特定的OID，把一个域对象从数据库加载到内存。

●     查询：根据特定的查询条件，把符合查询条件的一个或多个域对象从数据库加载内在存中。

2．为什么要持久化？

持久化技术封装了数据访问细节，为大部分业务逻辑提供面向对象的API。

● 通过持久化技术可以减少访问数据库数据次数，增加应用程序执行速度；

● 代码重用性高，能够完成大部分数据库操作；

● 松散耦合，使持久化不依赖于底层数据库和上层业务逻辑实现，更换数据库时只需修改配置文件而不用修改代码。