深入理解RPC框架的序列化方案

1 为什么需要序列化？

网络传输的数据须是二进制数据，但调用方请求的出入参数都是对象：

网站建设公司,为您提供网站建设,网站制作,网页设计及定制网站建设服务,专注于成都企业网站建设,高端网页制作,对成都玻璃隔断等多个行业拥有丰富的网站建设经验的网站建设公司。专业网站设计,网站优化推广哪家好,专业seo优化优化,H5建站,响应式网站。

  • • 对象不能直接在网络传输，需提前转成可传输的二进制，且要求可逆，即“序列化”将对象转换成二进制数据
  • • 这时，服务提供方就能正确从二进制数据中分割出不同请求，同时根据请求类型和序列化类型，把二进制的消息体逆向还原成请求对象，即“反序列化”将二进制转换为对象

序列化与反序列化

RPC框架为何需要序列化？

回想RPC通信流程：

RPC通信流程图

2 序列化方式

2.1 JDK原生序列化

案例：

import java.io.*;

public class Student implements Serializable {
    //学号
    private int no;
    //姓名
    private String name;

    public int getNo() {
        return no;
    }

    public void setNo(int no) {
        this.no = no;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    @Override
    public String toString() {
        return "Student{" +
                "no=" + no +
                ", name='" + name + '\'' +
                '}';
    }

    public static void main(String[] args) throws IOException, ClassNotFoundException {
        String home = System.getProperty("user.home");
        String basePath = home + "/Desktop";
        FileOutputStream fos = new FileOutputStream(basePath + "student.dat");
        Student student = new Student();
        student.setNo(100);
        student.setName("TEST_STUDENT");
        ObjectOutputStream oos = new ObjectOutputStream(fos);
        oos.writeObject(student);
        oos.flush();
        oos.close();

        FileInputStream fis = new FileInputStream(basePath + "student.dat");
        ObjectInputStream ois = new ObjectInputStream(fis);
        Student deStudent = (Student) ois.readObject();
        ois.close();

        System.out.println(deStudent);

    }
}
  • • 序列化具体由ObjectOutputStream完成
  • • 反序列化的具体实现是由ObjectInputStream完成

JDK序列化过程：

ObjectOutputStream序列化过程图

序列化过程就是在读取对象数据的时候，不断加入一些特殊分隔符，这些特殊分隔符用于在反序列化过程中截断用。

  • • 头部数据，声明序列化协议、序列化版本，用于高低版本向后兼容
  • • 对象数据主要包括类名、签名、属性名、属性类型及属性值，当然还有开头结尾等数据，除了属性值属于真正的对象值，其他都是为了反序列化用的元数据
  • • 存在对象引用、继承的情况下，就是递归遍历“写对象”逻辑

将对象的类型、属性类型、属性值按固定格式写到二进制字节流中来完成序列化，再按固定格式读出对象的类型、属性类型、属性值，通过这些信息重建一个新的对象，完成反序列化。

2.2 JSON

典型KV方式，没有数据类型，是一种文本型序列化框架。

  • • JSON进行序列化的额外空间开销较大
  • • JSON没有类型，但像Java这种强类型语言，需通过反射统一解决，性能不太好

所以如果RPC框架选用JSON序列化，服务提供者与服务调用者之间传输的数据量要相对较小。

2.3 Hessian

动态类型、二进制、紧凑的，并且可跨语言移植的一种序列化框架。比JDK、JSON更加紧凑，性能上要比JDK、JSON序列化高效很多，而且生成的字节数更小。

使用代码示例如下：

Student student = new Student();
student.setNo(101);
student.setName("HESSIAN");

//把student对象转化为byte数组
ByteArrayOutputStream bos = new ByteArrayOutputStream();
Hessian2Output output = new Hessian2Output(bos);
output.writeObject(student);
output.flushBuffer();
byte[] data = bos.toByteArray();
bos.close();

//把刚才序列化出来的byte数组转化为student对象
ByteArrayInputStream bis = new ByteArrayInputStream(data);
Hessian2Input input = new Hessian2Input(bis);
Student deStudent = (Student) input.readObject();
input.close();

System.out.println(deStudent);

相对于JDK、JSON，由于Hessian更加高效，生成的字节数更小，有非常好的兼容性和稳定性，所以Hessian更加适合作为RPC框架远程通信的序列化协议。

但Hessian本身也有问题，官方版本对Java里面一些常见对象的类型不支持，比如：

  •  Linked系列，LinkedHashMap、LinkedHashSet等，但是可以通过扩展CollectionDeserializer类修复
  •  Locale类，可以通过扩展ContextSerializerFactory类修复
  • Byte/Short反序列化的时候变成Integer

2.4 Protobuf

Protobuf 是 Google 公司内部的混合语言数据标准，是一种轻便、高效的结构化数据存储格式，可以用于结构化数据序列化，支持Java、Python、C++、Go等语言。Protobuf使用的时候需要定义IDL（Interface description language），然后使用不同语言的IDL编译器，生成序列化工具类，它的优点是：

  •  序列化后体积相比 JSON、Hessian小很多；
  • IDL能清晰地描述语义，所以足以帮助并保证应用程序之间的类型不会丢失，无需类似 XML 解析器；
  • 序列化反序列化速度很快，不需要通过反射获取类型；
  • 消息格式升级和兼容性不错，可以做到向后兼容。

使用代码示例如下：

/**
 *
 * // IDl 文件格式
 * synax = "proto3";
 * option java_package = "com.test";
 * option java_outer_classname = "StudentProtobuf";
 *
 * message StudentMsg {
 * //序号
 * int32 no = 1;
 * //姓名
 * string name = 2;
 * }
 * 
 */
 
StudentProtobuf.StudentMsg.Builder builder = StudentProtobuf.StudentMsg.newBuilder();
builder.setNo(103);
builder.setName("protobuf");

//把student对象转化为byte数组
StudentProtobuf.StudentMsg msg = builder.build();
byte[] data = msg.toByteArray();

//把刚才序列化出来的byte数组转化为student对象
StudentProtobuf.StudentMsg deStudent = StudentProtobuf.StudentMsg.parseFrom(data);

System.out.println(deStudent);

Protobuf 非常高效，但是对于具有反射和动态能力的语言来说，这样用起来很费劲，这一点就不如Hessian，比如用Java的话，这个预编译过程不是必须的，可以考虑使用Protostuff。

Protostuff不需要依赖IDL文件，可以直接对Java领域对象进行反/序列化操作，在效率上跟Protobuf差不多，生成的二进制格式和Protobuf是完全相同的，可以说是一个Java版本的Protobuf序列化框架。但在使用过程中，我遇到过一些不支持的情况，也同步给你：

  • • 不支持null；
  • • ProtoStuff不支持单纯的Map、List集合对象，需要包在对象里面。

3 RPC序列化选型

3.1 性能和效率

3.2 空间开销

即序列化之后的二进制数据的体积大小。序列化后的字节数据体积越小，网络传输的数据量就越小，传输数据的速度也就越快，由于RPC是远程调用，那么网络传输的速度将直接关系到请求响应的耗时。

3.3 通用性和兼容性

某类型为集合类的入参服务调用者不能解析了，服务提供方将入参类加一个属性之后服务调用方不能正常调用，升级了RPC版本后发起调用时报序列化异常…

通用性和兼容性的优先级考虑很高，直接关系到服务调用稳定性和可用率。看重这种序列化协议在版本升级后的兼容性，是否支持更多的对象类型，是否跨平台、跨语言，是否有很多人已用过并踩过很多坑，其次考虑性能、效率和空间开销。

3.4 安全性

JDK原生序列化存在漏洞。如果序列化存在安全漏洞，线上服务可能被入侵：

首选Hessian与Protobuf，性能、时间开销、空间开销、通用性、兼容性和安全性上，都满足要求：

  • • Hessian使用更方便，在对象的兼容性上更好
  • • Protobuf则更加高效，更通用

4 FAQ

4.1 对象构造得太复杂

属性很多，并且存在多层的嵌套，比如A对象关联B对象，B对象又聚合C对象，C对象又关联聚合很多其他对象，对象依赖关系过于复杂。

序列化框架在序列化与反序列化对象时，对象越复杂就越浪费性能，消耗CPU，这会严重影响RPC框架整体的性能。

4.2 对象太庞大

RPC请求经常超时，排查后发现他们的入参对象非常得大，比如为一个大List或者大Map，序列化之后字节长度达到了上兆字节。这种情况同样会严重地浪费性能、CPU，并且序列化一个如此大的对象是很耗费时间的，这肯定会直接影响到请求耗时。

4.3 使用序列化框架不支持的类作为入参类

如Hessian天然不支持LinkHashMap、LinkedHashSet等，而且大多数情况下最好不要使用第三方集合类，如Guava中的集合类，很多开源的序列化框架都是优先支持编程语言原生的对象。因此如果入参是集合类，应尽量选用原生的、最为常用的集合类，如HashMap、ArrayList。

4.4 对象有复杂继承关系

序列化对象时会将对象属性一一序列化，当有继承关系时，会不停寻找父类，遍历属性。就像问题1，对象关系越复杂，越浪费性能。

在RPC框架的使用过程中，尽量构建简单的对象作为入参和返回值对象，避免上述问题。

5 总结

使用RPC框架的过程中，我们构造入参、返回值对象，主要记住以下几点：

  1. 1. 对象要尽量简单，没有太多的依赖关系，属性不要太多，尽量高内聚；
  2. 2. 入参对象与返回值对象体积不要太大，更不要传太大的集合；
  3. 3. 尽量使用简单的、常用的、开发语言原生的对象，尤其是集合类；
  4. 4. 对象不要有复杂的继承关系，最好不要有父子类的情况。

实际上，虽然RPC框架可以让我们发起远程调用就像调用本地一样，但在RPC框架的传输过程中，入参与返回值的根本作用就是用来传递信息的，为了提高RPC调用整体的性能和稳定性，我们的入参与返回值对象要构造得尽量简单。

6 FAQ

RPC框架在序列化框架的选型上，你认为还需要考虑哪些因素？你还知道哪些优秀的序列化框架，它们又是否适合在RPC调用中使用？

序列化一般用在协议里面的payload里。

Redis使用的RESP，在做序列化时也是会增加很多冗余的字符，但它胜在实现简单、可读性强易于理解。

JSON和XML使用字符串表示所有的数据，对于非字符数据来说，字面量表达会占用很多额外的存储空间，并且会严重受到数值大小和精度的影响。一个32位浮点数 1234.5678 在内存中占用 4 bytes 空间，如果存储为 utf8 ，则需要占用 9 bytes空间，在JS这样使用utf16表达字符串的环境中，需要占用 18 bytes空间。使用正则表达式进行数据解析，在面对非字符数据时显得十分低效，不仅要耗费大量的运算解析数据结构，还要将字面量转换成对应的数据类型。

在面对海量数据时，这种格式本身就能够成为整个系统的IO与计算瓶颈，甚至直接overflow。

常见的序列化协议有：xml json protobuf jdk等 xml和json可读性好，序列化后空间大，性能差，而且json序列化后无类型，需要反射获取对象类型。而protobuf则是可读性差点，序列化后占用空间小，性能好，不需要反序列化获取属性类型等优点。对性能要求高的原则protobuf比较好点

为什么JSON的额外开销大呢？是因为存在大量的换行吗

最明显的就是你说的数据包大，因为字符相对二进制更占空间。

json需要内存去解析能理解，但为什么json序列化还需要磁盘开销啊。json序列化的二进制数据在体量比其他序列化方法小一些吧，可以减少带宽和流量？

说的如果json数据存储在磁盘上，json字节数相对其他数据都偏大。

分享名称：深入理解RPC框架的序列化方案
文章来源：http://www.shufengxianlan.com/qtweb/news32/239632.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联

猜你还喜欢下面的内容

品牌网站设计知识

行业网站建设

成都做网站　　 　证企宝企业　　 　建站公司　　 　成都机柜租用　　 　成都微信小程序　　 　成都未宇聚　　 　复盛机电设备安装　　 　网站免费收录　　 　成都电信服务器托管　　 　光华村机房　　 　宜宾网站设计　　 　成都云主机　　 　服务器租用　　 　网页设计制作　　 　四川中建建业　　 　成都圣月窗帘　　 　云服务器香港　　 　教育培训网站建设方案　　 　网站seo优化　　 　四川雕琢时光