一、前言
上一节讲解了在 RPC 框架中,如何设计可扩展的、向后兼容的协议,其关键点就是利用好 Header 中的扩展字段以及 Payload 中的扩展字段,通过扩展字段向后兼容。
那么承接上一讲的一个重点,今天我会讲解下 RPC 框架中的序列化。要知道,在不同的场景下合理地选择序列化方式,对提升 RPC 框架整体的稳定性和性能是至关重要的。
三、为什么需要序列化?
首先,我们得知道什么是序列化与反序列化。
我们先回顾下 第一节【理解RPC核心原理】 介绍过的 RPC 原理的内容,在描述 RPC 通信流程的时候说过:网络传输的数据必须是二进制数据,但调用方请求的出入参数都是对象。
对象是不能直接在网络中传输的,所以我们需要提前把它转成可传输的二进制,并且要求转换算法是可逆的,这个过程我们一般叫做“序列化”。
这时,服务提供方就可以正确地从二进制数据中分割出不同的请求,同时根据请求类型和序列化类型,把二进制的消息体逆向还原成请求对象,这个过程我们称之为“反序列化”。
这两个过程如下图所示:
总结来说,序列化就是将对象转换成二进制数据的过程,而反序列就是反过来将二进制转换为对象的过程。
那么 RPC 框架为什么需要序列化呢?还是请你回想下 RPC 的通信流程:
不妨借用个例子帮助你理解,比如发快递,我们要发一个需要自行组装的物件。发件人发之前,会把物件拆开装箱,这就好比序列化;这时候快递员来了,不能磕碰呀,那就要打包,这就好比将序列化后的数据进行编码,封装成一个固定格式的协议;过了两天,收件人收到包裹了,就会拆箱将物件拼接好,这就好比是协议解码和反序列化。
所以现在你清楚了吗?因为网络传输的数据必须是二进制数据,所以在 RPC 调用中,对入参对象与返回值对象进行序列化与反序列化是一个必须的过程。