常州天宁建设局网站怎么做网站省钱

当前位置： 首页 > news >正文

常州天宁建设局网站,怎么做网站省钱,网站前台和后台,帮人家做网站优秀博文#xff1a;IT-BLOG-CN 序列化#xff1a;把对象转换为字节序列存储于磁盘或者进行网络传输的过程称为对象的序列化。 反序列化#xff1a;把磁盘或网络节点上的字节序列恢复到对象的过程称为对象的反序列化。 一、序列化对象 【1】必须实现序列化接口Serializabl… 优秀博文IT-BLOG-CN 序列化把对象转换为字节序列存储于磁盘或者进行网络传输的过程称为对象的序列化。 反序列化把磁盘或网络节点上的字节序列恢复到对象的过程称为对象的反序列化。 一、序列化对象 【1】必须实现序列化接口SerializableJava.io.Serializable接口。 【2】serialVersionUID序列化的版本号凡是实现Serializable接口的类都有一个静态的表示序列化版本标识符的变量。 Add default serial version ID生成的代码为private static final long serialVersionUID 1L;  Add generated serial version ID生成的代码为private static final long serialVersionUID -5248069984631225347L; 定义了serialVersionUID之后就可以对序列化后的对象进行修改此时不会产生新的serialVersionUID导致还原时出错。 【3】serialVersionUID的取值 此值是通过Java运行时环境根据类的内部细节自动生成的。如果类的源代码进行了修改再重新编译新生成的类文件的serialVersionUID的值也会发生变化。不同的编译器也可能会导致不同的serialVersionUID。为了提高serialVersionUID的独立性和确定性建议在一个序列化类中显示的定义serialVersionUID为它赋予明确的值。 package com.java;import java.io.Serializable; import java.util.ArrayList; import java.util.List;/*** 序列化对象* author -zhengzx-/ public class Player implements Serializable{//private static final long serialVersionUID -5248069984631225347L;public Player(long playerId, int age, String name) {this.playerId playerId;this.age age;this.name name;}private long playerId;private int age;private String name;private ListInteger skills new ArrayList();public long getPlayerId() {return playerId;}public void setPlayerId(long playerId) {this.playerId playerId;}public int getAge() {return age;}public void setAge(int age) {this.age age;}public String getName() {return name;}public void setName(String name) {this.name name;}public ListInteger getSkills() {return skills;}public void setSkills(ListInteger skills) {this.skills skills;} }二、序列化与反序列化实例 【1】对象序列化代码如下具体细节注释说明Java中通过对象流ObjectOutputStream进行序列化。 【2】反序列化为对象具体细节注释说明Java中通过对象流ObjectInputStream进行反序列化。 package com.java;import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.IOException; import java.io.ObjectInputStream; import java.io.ObjectOutputStream; import java.util.Arrays;/* Description:序列化与反序列化* author zhengzx/ public class JavaSerialize {public static void main(String[] args) throws Exception {Player player new Player(10001, 21, teacher);player.getSkills().add(10001);//序列化byte[] bytes toBytes(player);//反序列化toPlay(bytes);}/** Title: toBytes* Description:序列化对象* author zhengzx* throws Exception/public static byte[] toBytes(Object out) throws Exception {//用于序列化后存储对象ByteArrayOutputStream byteArrayOutputStream null;//java序列化APIObjectOutputStream objectOutputStream null;try {byteArrayOutputStream new ByteArrayOutputStream();objectOutputStream new ObjectOutputStream(byteArrayOutputStream);//将out对象进行序列化objectOutputStream.writeObject(out);//测试验证输入获取字节数组byte[] bs byteArrayOutputStream.toByteArray();//将数组转化为字符串输入System.out.println(Arrays.toString(bs));return bs;} catch (IOException e) {e.printStackTrace();}finally {//关闭最外层的流内部流会自动关闭objectOutputStream.close();}return null;}/** Title: toPlay Description:反序列化对象* author zhengzx* throws Exception*/public static void toPlay(byte[] bs) throws Exception {//创建存放二进制数据的APIByteArrayInputStream byteArrayInputStream null;//创建反序列化对象ObjectInputStream objectInputStream null;try {byteArrayInputStream new ByteArrayInputStream(bs);objectInputStream new ObjectInputStream(byteArrayInputStream);//校验测试Player player (Player) objectInputStream.readObject();System.out.println(player.toString());} catch (IOException e) {e.printStackTrace();}finally {objectInputStream.close();}} }测试结果展示 [-84, -19, 0, 5, 115, 114, 0, 15, 99, 111, 109, 46, 106, 97, 46, 80, 108, 97, 121, 101, 114] Player [playerId10001, age21, nameteacher, skills[10001]]三、高级部分 序列化和反序列化几乎是工程师们每天都要面对的事情但是要精确掌握这两个概念并不容易一方面它们往往作为框架的一部分出现而湮没在框架之中另一方面它们会以其他更容易理解的概念出现例如加密、持久化。然而序列化和反序列化的选型却是系统设计或重构一个重要的环节在分布式、大数据量系统设计里面更为显著。恰当的序列化协议不仅可以提高系统的通用性、强健性、安全性、优化系统性能而且会让系统更加易于调试、便于扩展。本文从多个角度去分析和讲解“序列化和反序列化”并对比了当前流行的几种序列化协议期望对读者做序列化选型有所帮助。 1、定义以及相关概念 互联网的产生带来了机器间通讯的需求而互联通讯的双方需要采用约定的协议序列化和反序列化属于通讯协议的一部分。通讯协议往往采用分层模型不同模型每层的功能定义以及颗粒度不同例如TCP/IP协议是一个四层协议而OSI模型却是七层协议模型。在OSI七层协议模型中展现层Presentation Layer的主要功能是把应用层的对象转换成一段连续的二进制串或者反过来把二进制串转换成应用层的对象这两个功能就是序列化和反序列化。一般而言TCP/IP协议的应用层对应与OSI七层协议模型的应用层展示层和会话层所以序列化协议属于TCP/IP协议应用层的一部分。本文对序列化协议的讲解主要基于OSI七层协议模型。 数据结构、对象与二进制串 不同的计算机语言中数据结构对象以及二进制串的表示方式并不相同。 数据结构和对象 对于类似Java这种完全面向对象的语言工程师所操作的一切都是对象Object来自于类的实例化。在Java语言中最接近数据结构的概念就是POJOPlain 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。 2、序列化协议特性 每种序列化协议都有优点和缺点它们在设计之初有自己独特的应用场景。在系统设计的过程中需要考虑序列化需求的方方面面综合对比各种序列化协议的特性最终给出一个折衷的方案。 【1】通用性 通用性有两个层面的意义 第一、技术层面序列化协议是否支持跨平台、跨语言。如果不支持在技术层面上的通用性就大大降低了。 第二、流行程度序列化和反序列化需要多方参与很少人使用的协议往往意味着昂贵的学习成本另一方面流行度低的协议往往缺乏稳定而成熟的跨语言、跨平台的公共包。 【2】强健性/鲁棒性 以下两个方面的原因会导致协议不够强健 第一、成熟度不够一个协议从制定到实施到最后成熟往往是一个漫长的阶段。协议的强健性依赖于大量而全面的测试对于致力于提供高质量服务的系统采用处于测试阶段的序列化协议会带来很高的风险。 第二、语言/平台的不公平性。为了支持跨语言、跨平台的功能序列化协议的制定者需要做大量的工作但是当所支持的语言或者平台之间存在难以调和的特性的时候协议制定者需要做一个艰难的决定–支持更多人使用的语言/平台亦或支持更多的语言/平台而放弃某个特性。当协议的制定者决定为某种语言或平台提供更多支持的时候对于使用者而言协议的强健性就被牺牲了。 【3】可调试性/可读性 序列化和反序列化的数据正确性和业务正确性的调试往往需要很长的时间良好的调试机制会大大提高开发效率。序列化后的二进制串往往不具备人眼可读性为了验证序列化结果的正确性写入方不得同时撰写反序列化程序或提供一个查询平台这比较费时另一方面如果读取方未能成功实现反序列化这将给问题查找带来了很大的挑战难以定位是由于自身的反序列化程序的bug所导致还是由于写入方序列化后的错误数据所导致。对于跨公司间的调试由于以下原因问题会显得更严重 第一、支持不到位跨公司调试在问题出现后可能得不到及时的支持这大大延长了调试周期。 第二、访问限制调试阶段的查询平台未必对外公开这增加了读取方的验证难度。 如果序列化后的数据人眼可读这将大大提高调试效率XML和JSON就具有人眼可读的优点。 【4】性能 性能包括两个方面时间复杂度和空间复杂度 第一、空间开销Verbosity 序列化需要在原有的数据上加上描述字段以为反序列化解析之用。如果序列化过程引入的额外开销过高可能会导致过大的网络磁盘等各方面的压力。对于海量分布式存储系统数据量往往以TB为单位巨大的的额外空间开销意味着高昂的成本。 第二、时间开销Complexity复杂的序列化协议会导致较长的解析时间这可能会使得序列化和反序列化阶段成为整个系统的瓶颈。 【5】可扩展性/兼容性 移动互联时代业务系统需求的更新周期变得更快新的需求不断涌现而老的系统还是需要继续维护。如果序列化协议具有良好的可扩展性支持自动增加新的业务字段而不影响老的服务这将大大提供系统的灵活度。 【6】安全性/访问限制 在序列化选型的过程中安全性的考虑往往发生在跨局域网访问的场景。当通讯发生在公司之间或者跨机房的时候出于安全的考虑对于跨局域网的访问往往被限制为基于HTTP/HTTPS的80和443端口。如果使用的序列化协议没有兼容而成熟的HTTP传输层框架支持可能会导致以下三种结果之一第一、因为访问限制而降低服务可用性。 第二、被迫重新实现安全协议而导致实施成本大大提高。 第三、开放更多的防火墙端口和协议访问而牺牲安全性。 3、序列化和反序列化的组件 典型的序列化和反序列化过程往往需要如下组件 【1】IDLInterface description language文件 参与通讯的各方需要对通讯的内容需要做相关的约定Specifications。为了建立一个与语言和平台无关的约定这个约定需要采用与具体开发语言、平台无关的语言来进行描述。这种语言被称为接口描述语言IDL采用 IDL撰写的协议约定称之为IDL文件。 【2】IDL Compiler IDL文件中约定的内容为了在各语言和平台可见需要有一个编译器将IDL文件转换成各语言对应的动态库。 【3】Stub/Skeleton Lib 负责序列化和反序列化的工作代码。Stub是一段部署在分布式系统客户端的代码一方面接收应用层的参数并对其序列化后通过底层协议栈发送到服务端另一方面接收服务端序列化后的结果数据反序列化后交给客户端应用层Skeleton部署在服务端其功能与Stub相反从传输层接收序列化参数反序列化后交给服务端应用层并将应用层的执行结果序列化后最终传送给客户端Stub。 【4】Client/Server 指的是应用层程序代码他们面对的是IDL所生存的特定语言的class或struct。 【5】底层协议栈和互联网 序列化之后的数据通过底层的传输层、网络层、链路层以及物理层协议转换成数字信号在互联网中传递。 序列化组件与数据库访问组件的对比 数据库访问对于很多工程师来说相对熟悉所用到的组件也相对容易理解。下表类比了序列化过程中用到的部分组件和数据库访问组件的对应关系以便于大家更好的把握序列化相关组件的概念。 序列化组件数据库组件说明IDLDDL用于建表或者模型的语言DL fileDB Schema表创建文件或模型文件Stub/Skeleton libO/R mapping将class和Table或者数据模型进行映射 4、几种常见的序列化和反序列化协议 这里主要介绍和对比几种当下比较流行的序列化协议包括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 ListAddress address; }XMLSOAP XML是一种常用的序列化和反序列化协议具有跨机器跨语言等优点。 XML历史悠久其1.0版本早在1998年就形成标准并被广泛使用至今。XML的最初产生目标是对互联网文档Document进行标记所以它的设计理念中就包含了对于人和机器都具备可读性。 但是当这种标记文档的设计被用来序列化对象的时候就显得冗长而复杂Verbose and Complex。XML本质上是一种描述语言并且具有自我描述Self-describing的属性所以XML自身就被用于XML序列化的IDL。标准的XML描述格式有两种DTDDocument Type Definition和XSDXML Schema Definition。作为一种人眼可读Human-readable的描述语言XML被广泛使用在配置文件中例如O/R mapping、Spring Bean Configuration File等。 SOAPSimple Object Access protocol是一种被广泛应用的基于XML为序列化和反序列化协议的结构化消息传递协议。SOAP在互联网影响如此大以至于我们给基于SOAP的解决方案一个特定的名称Web service。SOAP虽然可以支持多种传输层协议不过SOAP最常见的使用方式还是XMLHTTP。SOAP协议的主要接口描述语言IDL是WSDLWeb Service Description Language。SOAP具有安全、可扩展、跨语言、跨平台并支持多种传输层协议。如果不考虑跨平台和跨语言的需求XML的在某些语言里面具有非常简单易用的序列化使用方法无需IDL文件和第三方编译器 例如JavaXStream。 SOAP是一种采用XML进行序列化和反序列化的协议它的IDL是WSDL. 而WSDL的描述文件是XSD而XSD自身是一种XML文件。 这里产生了一种有趣的在数学上称之为“递归”的问题这种现象往往发生在一些具有自我属性Self-description的事物上。 IDL文件举例采用WSDL描述上述用户基本信息的例子如下 xsd:complexType nameAddressxsd:attribute namecity typexsd:string /xsd:attribute namepostcode typexsd:string /xsd:attribute namestreet typexsd:string / /xsd:complexType xsd:complexType nameUserInfoxsd:sequencexsd:element nameaddress typetns:Address/xsd:element nameaddress1 typetns:Address//xsd:sequencexsd:attribute nameuserid typexsd:int /xsd:attribute namename typexsd:string / /xsd:complexType典型应用场景和非应用场景 SOAP协议具有广泛的群众基础基于HTTP的传输协议使得其在穿越防火墙时具有良好安全特性XML所具有的人眼可读Human-readable特性使得其具有出众的可调试性互联网带宽的日益剧增也大大弥补了其空间开销大Verbose的缺点。对于在公司之间传输数据量相对小或者实时性要求相对低例如秒级别的服务是一个好的选择。 由于XML的额外空间开销大序列化之后的数据量剧增对于数据量巨大序列持久化应用常景这意味着巨大的内存和磁盘开销不太适合XML。另外XML的序列化和反序列化的空间和时间开销都比较大对于对性能要求在 ms级别的服务不推荐使用。WSDL虽然具备了描述对象的能力SOAP的S代表的也是simple但是SOAP的使用绝对不简单。对于习惯于面向对象编程的用户WSDL文件不直观。 JSONJavascript Object Notation JSON起源于弱类型语言Javascript它的产生来自于一种称之为Associative array的概念其本质是就是采用Attributevalue的方式来描述对象。实际上在Javascript和PHP等弱类型语言中类的描述方式就是Associative array。JSON的如下优点使得它快速成为最广泛使用的序列化协议之一 【1】这种Associative array格式非常符合工程师对对象的理解。 【2】它保持了XML的人眼可读Human-readable的优点。 【3】相对于XML而言序列化后的数据更加简洁。 来自于的以下链接的研究表明XML所产生序列化之后文件的大小接近JSON的两倍。 【4】它具备Javascript的先天性支持所以被广泛应用于Web browser的应用常景中是Ajax的事实标准协议。 【5】与XML相比其协议比较简单解析速度比较快。 【6】松散的Associative array使得其具有良好的可扩展性和兼容性。 IDL悖论JSON实在是太简单了或者说太像各种语言里面的类了所以采用JSON进行序列化不需要IDL。这实在是太神奇了存在一种天然的序列化协议自身就实现了跨语言和跨平台。然而事实没有那么神奇之所以产生这种假象来自于两个原因 【1】Associative array在弱类型语言里面就是类的概念在 PHP和 Javascript里面 Associative array就是其 class的实际实现方式所以在这些弱类型语言里面JSON得到了非常良好的支持。 【2】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的典型应用场景是JSONHTTP适合跨防火墙访问。 总的来说采用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 listAddress 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 city1;optional string postcode2;optional string street3; } message UserInfo {required string userid1;required string name2;repeated Address address3; }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;arrayAddress address [];} }essess所对应的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 : { } }5、Benchmark以及选型建议 解析性能 序列化之空间开销 从上图可得出如下结论 【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】当对性能和简洁性有极高要求的场景ProtobufThriftAvro之间具有一定的竞争关系。 【5】对于T级别的数据的持久化应用场景Protobuf和Avro是首要选择。如果持久化后的数据存储在Hadoop子项目里Avro会是更好的选择。 【6】由于Avro的设计理念偏向于动态类型语言对于动态语言为主的应用场景Avro是更好的选择。 【7】对于持久层非Hadoop项目以静态类型语言为主的应用场景Protobuf会更符合静态类型语言工程师的开发习惯。 【8】如果需要提供一个完整的RPC解决方案Thrift是一个好的选择。 【9】如果序列化之后需要支持不同的传输层协议或者需要跨防火墙访问的高性能场景Protobuf可以优先考虑。