RPC的序列化方案详解

╰半橙微兮° 2024-03-27 12:13 39阅读 0赞

### 1 为什么需要序列化？ ###

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

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

![序列化与反序列化][4019cfa9ad948fd26f09fb7268018462.jpeg]

RPC框架为何需要序列化？

回想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序列化过程图][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原生序列化存在漏洞。如果序列化存在安全漏洞，线上服务可能被入侵：

![img][]

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

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

### 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字节数相对其他数据都偏大。

[4019cfa9ad948fd26f09fb7268018462.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/00ce0fb34a8042308d0abcc3e3cfb159.png
[RPC]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/1eb7a92753ec43bdb48faad0b54c99bc.png
[ObjectOutputStream]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/664c4e8665b242909e5821f380c94466.png
[img]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/359c0c9a8ac74aa6afaa4f6b2d8a0d41.png