一、前言

上一节讲解了在 RPC 框架中，如何设计可扩展的、向后兼容的协议，其关键点就是利用好 Header 中的扩展字段以及 Payload 中的扩展字段，通过扩展字段向后兼容。

那么承接上一讲的一个重点，今天我会讲解下 RPC 框架中的序列化。要知道，在不同的场景下合理地选择序列化方式，对提升 RPC 框架整体的稳定性和性能是至关重要的。

　

三、为什么需要序列化？

首先，我们得知道什么是序列化与反序列化。

我们先回顾下 第一节【理解RPC核心原理】 介绍过的 RPC 原理的内容，在描述 RPC 通信流程的时候说过：网络传输的数据必须是二进制数据，但调用方请求的出入参数都是对象。

对象是不能直接在网络中传输的，所以我们需要提前把它转成可传输的二进制，并且要求转换算法是可逆的，这个过程我们一般叫做“序列化”。

这时，服务提供方就可以正确地从二进制数据中分割出不同的请求，同时根据请求类型和序列化类型，把二进制的消息体逆向还原成请求对象，这个过程我们称之为“反序列化”。

这两个过程如下图所示：

总结来说，序列化就是将对象转换成二进制数据的过程，而反序列就是反过来将二进制转换为对象的过程。

那么 RPC 框架为什么需要序列化呢？还是请你回想下 RPC 的通信流程：

不妨借用个例子帮助你理解，比如发快递，我们要发一个需要自行组装的物件。发件人发之前，会把物件拆开装箱，这就好比序列化；这时候快递员来了，不能磕碰呀，那就要打包，这就好比将序列化后的数据进行编码，封装成一个固定格式的协议；过了两天，收件人收到包裹了，就会拆箱将物件拼接好，这就好比是协议解码和反序列化。

所以现在你清楚了吗？因为网络传输的数据必须是二进制数据，所以在 RPC 调用中，对入参对象与返回值对象进行序列化与反序列化是一个必须的过程。