聊聊序列化（一）关于序列化协议的一些思考和问题

最近在设计一个RPC框架，需要处理序列化的问题。有很多种序列化协议可以选择，比如Java原生的序列化协议，Protobuf, Thrift, Hessian, Kryo等等，这里说的序列化协议专指Java的基于二进制的协议，不是基于XML, JSON这种格式的协议。在实际开发中考虑了很多点，也遇到一些问题，拿出来说说。

抛开这些协议不说，结合实际的需求，一个理想的序列化协议至少考虑4个方面：

1. 序列化后的字节数大小

2. 序列化和反序列化的效率

3. 是否支持被序列化对象新旧版本的兼容性问题。这个需求在实际开发中经常遇到，比如发布了一个服务，有很多客户端使用。当服务需要修改，新 添加1个参数时，不可能要求所有客户端都更新，那样牵扯的面太大，所以要做到新旧版本的兼容

4. 是否可以直接序列化对象，而不需要额外的辅助类，比如用IDL生成辅助的序列化类

前3个要求是衡量一个序列化协议好坏的重点，第4点是一个使用性的考虑，毕竟在不考虑跨平台调用的情况下，不需要使用IDL。使用IDL的开发方式一般是从IDL文件开始的，而不是直接从Java类开始。

序列化这件事说白了就是把一个对象变成一个二进制流，然后把二进制流再转化成对象的过程。前者好说，关键是后者，后者其实就是一个如何分帧(Frame)的问题，即从哪个字节开始读几个字节来还原成数据的问题。常见的分帧方式有：

1. 加结束符，比如http协议

2. 定长

3. 消息头+消息，消息头可以包含长度，类型信息

对于Java序列化来说，肯定是第三种方式，但是如何设计这个分帧方式又有很多实现。下面说说上述的4个方面具体有哪些考虑和问题。

第一是序列化后的字节数大小。最优的序列化后的字节数大小肯定是只有数据的二进制流，这样没有任何多余的分帧信息。如果要做到在二进制流里不加任何分帧信息来反序列化二进制流，有两个关键点：