02 | 协议：怎么设计可扩展且向后兼容的协议？

我们为什么需要使用协议？

在网络通信的过程中，为了避免语义不一致的情况，我们需要在发送请求时设定一个边界，然后再收到请求时按照设定的边界对请求数据进行分割。这里的边界语义的表达，就是我们所说的协议。

为什么我们在RPC中不使用HTTP作为主要协议？

RPC负责应用间通信，对性能要求高，但HTTP协议的数据包大小相对请求数据来说，要大很多，包含了很多额外字符，例如换行、回车等。
HTTP协议属于无状态协议，客户端无法对请求和响应进行关联，不能很好地进行异步处理。

我们在设计协议时，一般会把协议分成两部分：

1. 协议头，由一堆固定长度的参数组成。
2. 协议体，根据请求接口和参数构造，长度可变。

什么是定长协议？

定长协议是指协议头长度固定。协议头示意图如下。

定长协议有什么缺点？

定长协议的协议头不能添加新参数，否则就会产生兼容性问题。例如我们设计了一个 88Bit 的协议头，其中协议长度占用32bit，然后为了加入新功能，在协议头里面加了2bit，并且放到协议头的最后。升级后的应用，会用新的协议发出请求，然而没有升级的应用收到的请求后，还是按照88bit 读取协议头，新加的2个bit会当作协议体前2个bit数据读出来，但原本的协议体最后2个bit会被丢弃了，这样就会导致协议体的数据是错的。

如何设计一个可扩展的协议？

我们需要让协议头支持可扩展，扩展后协议头的长度就不能定长了。这样整个协议变成了三部分：固定部分、协议头内容、协议体内容。
可扩展协议的示意图如下。

设计一个简单的RPC协议不难，难的地方在于怎么设计一个可“升级”的协议，不仅要让我们在扩展新特性的时候能够做到向下兼容，而且要尽可能地减少资源损耗。

协议头的具体内容是什么？

• Bit Offset：标识协议的起始位置。
• 魔术位：标识是什么协议。
• 整体长度：标识整个协议有多长，它减去头长度就是协议体长度
• 头长度：协议头的长度，因为协议头长度不固定，所以需要标识。
• 协议版本：标识协议的版本，主要用于兼容性控制。
• 消息类型：标识消息的类型，可能是文本、XML、JSON等。
• 序列化方式：标识用来做序列化和反序列化的方式。
• 消息ID：用于标识请求和响应的关系。
• 协议头扩展字段：用于扩展协议头，这样使得协议具有可扩展性，更加灵活。
• 协议体：协议的具体内容，二进制格式。

03 | 序列化：对象怎么在网络中传输？

什么是“序列化”和“反序列化”？

网络传输的数据必须是二进制数据，但调用方请求的出入参数都是对象。对象是不能直接在网络中传输，所以我们需要提前把它转变成可传输的二进制，并且要求转换算法是可逆的，这个过程称为“序列化”。
根据请求类型和序列化类型，服务提供方将请求传来的二进制数据还原成请求对象，这个过程称为“反序列化”。

序列化就是将对象转换成二进制数据的过程，而反序列化就是把二进制数据转换成对象的过程。

有哪些常用的序列化方式？

• JDK原生序列化
• JSON
• Hessian
• Protobuf
• Protostuff
• Thrift
• Avro

任何一种序列化框架，核心思想就是设计一种序列化协议，将对象的类型、属性类型、属性值一一按照固定的格式写到二进制字节流中来完成序列化，再按照固定的格式一一读出对象的类型、属性类型、属性值，通过这些信息重新创建出一个对象，来完成反序列化。

JSON进行序列化存在哪些问题？

1. JSON额外空间开销比较大，对于大数据量服务意味着巨大的内存和磁盘开销。
2. JSON没有类型，但Java属于强类型语言，这需要通过反射来解决类型问题，所以会影响性能，这样就要求服务提供者和调用者之间传输的数据量要小。

Hessian有什么缺点？

Hessian不支持Java一些常见类型，例如：

1. Linked系列
2. Locale类
3. Byte/Short在反序列化时会变成Integer

如何选择合适的序列化框架？

对于服务提供者来说，服务的可靠性要比性能更重要，因此，我们在选择序列化框架时，更关注协议在版本升级后的兼容性是否很好、是否支持更多的对象类型、是否跨平台、跨语言、是否有很多人已经用过并且踩过坑了，其次，我们才会考虑性能、效率和空间开销。
另外序列化协议的安全也是需要考虑的一个重要因素。
综合考虑，当我们选择序列化协议时，考虑因素如下所示：

RPC框架在使用序列化协议时有哪些注意事项？

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