5.6 对象序列化/反序列化

2018-09-09 20:31:30 315 0

1 对象序列化/反序列化简介

在实际开发中,为了简化开发,通常请求和响应都使用使用Java对象表示,对使用者屏蔽底层的协议细节。例如一些RPC框架,支持把用户定义的Java对象当做参数去请求服务端,服务端响应也是一个Java对象。

而前面我们讲解的案例都是以字符串作为请求和响应参数,实际上,Netty对于我们的自定义的Java对象作为请求响应参数也是支持的,其默认支持通过以下机制对Java对象进行序列化和反序列化:

  • ObjectEncoder/ObjectDecoder:使用JDK序列化机制编解码

  • ProtobufEncoder/ ProtobufDecoder:使用google protocol buffer进行编解码

  • MarshallingEncoder/MarshallingDecoder:使用JBoss Marshalling进行编解码

  • XmlDecoder:使用Aalto XML parser进行解码,将xml解析成Aalto XML parser中定义的Java对象,没有提供相应的编码器

  • JsonObjectDecoder:使用Json格式解码。当检测到匹配数量的"{" 、”}”或”[””]”时,则认为是一个完整的json对象或者json数组。这个解码器只是将包含了一个完整Json格式数据的ByteBuf实例交给之后的ChannelInbounderHandler解析,因此我们需要依赖其他的JSON框架,如Gson、jackson、fastjson等。没有提供相应的编码器。 

除了Netty默认值支持的这些序列化机制,事实上还有很多的其他的序列化框架,如:hessianKryoAvrofstmsgback、thrift、protostuff等。

        在实际开发中,通常我们没有必要支持上述所有的序列化框架,支持部分即可。主要的选择依据如下表: 

选择依据说明
效率即序列化和反序列化的性能。这方面Kryo、Avro、fst、hessian等都不错。
序列化后的占用字节数对于同一个Java对象,不同的框架序列化后占用的字节数不同。例如JDK序列化体积较大,而Kryo的体积较小。体积过大的话,会增加网络带宽压力。
是否有可视化需求json、xml序列化机制的结果能以文本形式展示;但是其他的框架大多是二进制的,因此可视化。
开发成本一些序列化框架使用较为复杂,如thrift、protocol buffer;另外则很简单,如JDK序列化、Hessian等 

从本教程而言,主要是为了介绍如何在Netty中使用这些序列化框架,方式类似,因此不会对每一种都进行介绍。在后续的文章中,我们将会对:JDK序列化、Hessian序列化、protocol buffer序列化进行讲解。


2 通信协议格式要求

另外一点需要注意的是,上面提到的这些序列化框架通常不能单独使用。例如发送方只是将Java对象序列化成二进制字节,对于接收方而言,则无法判断到底哪些字节可以构成一个完整的Java对象,也就无法反序列化。因此我们通常需要结合长度编码,可以使用上一节提到的LengthFieldBasedFrameDecoder/LengthFieldPrepender来协助完成。

最简单的通信协议格式如下: 

+--------+----------+
| Length |  Content |
+--------+----------+

其中:

    Length:表示Content字段占用的字节数,Length本身占用的字节数我们可以指定为一个固定的值。

    Content:对象经过序列化后二进制字节内容

    对于上述协议,通常我们只能选择支持一种序列化框架,如果要支持多个序列化框架,我们可以对通信协议格式稍作改造,增加一个字段来表示使用的序列化框架,如: 

+--------+-------------+------------+
| Length |  Serializer |   Content  |
+--------+-------------+------------+

 中:Serializer我们可以指定使用1个字节表示,因此可以有256个值可选,我们用不同的值代表不同的框架。在编码时,选择好序列化框架后,进行序列化,并指定Serializer字段的值。在解码时,根据Serializer的值选择对应的框架进行反序列化;

在后面的章节中,让我们开启对象的序列化/反序列化之旅! 


上一篇:5.5 变长协议 下一篇:5.7 JDK序列化