Dubbo中的序列化
Dubbo RPC是Dubbo体系中最核心的一种高性能, 高吞吐量的远程调用方式, 可以称之为多路复用的TCP长连接调用
长连接: 避免了每次调用新建TCP连接, 提高了调用的响应速度
多路复用: 单个TCP连接可交替传输多个请求和响应的消息, 降低了连接的等待闲置时间, 从而减少了同样并发数下的网络连接数, 提高了系统吞吐量
Dubbo RPC主要用于两个Dubbo系统之间的远程调用, 特别适合高并发, 小数据的互联网场景, 而序列化对于远程调用的响应速度, 吞吐量, 网络带宽消耗等同样也起着至关重要的作用, 是提升分布式系统性能的最关键因素之一
Dubbo中支持的序列化方式:
dubbo序列化: 阿里尚未开发成熟的高效java序列化实现, 不建议在生产环境使用
hessian2序列化: hessian是一种跨语言的高效二进制序列化方式。但这里不是原生的hessian2序列化, 而是阿里修改过的hession lite, 它是dubbo RPC默认启用的序列化方式
json序列化: 目前有两种实现方式, 一种是采用阿里的fastjson库, 一种是采用dubbo中自己实现的json库, 实现都不成熟
java序列化: 主要是采用JDK自带的java序列化实现, 性能很不理想
在通常情况下, 这四种主要序列化方式的性能从上到下依次递减。对于dubbo RPC这种追求高性能的远程调用方式来说, 实际上只有1, 2两种高效序列化防水比较般配, 而第1个dubbo序列化由于还不成熟, 所以实际只剩下2可用, 所以dubbo RPC默认采用hessian2序列化
但hessian是一个比较老的序列化实现了, 而且它是跨语言的, 所以不是单独针对Java进行优化的。而dubbo RPC实际上是一种Java to Java的远程调用, 其实没有必要采用跨语言的序列化方式
最近几年, 各种新的高效序列化层出不穷, 不断刷新序列化性能的上限,
专门针对Java语言的: Kryo, FST
跨语言的: Protostuff, ProtoBuf, Thrift, Avro, MSgPack
其中, Kryo是一种非常成熟的序列化实现, 已经在Twitter, Groupon, Yohoo以及多个开源项目中广泛使用, 而FST是一种较新的序列化实现, 目前还缺乏足够多的成熟使用案例
在面向生产环境的应用中, 目前更优先选择Kryo.
启用Kryo
在Provider和Consumer项目启用Kryo高速序列化功能, 两个项目的配置方式相同
增加Kryo依赖
<dependency>
<groupId>de.javakaffee</groupId>
<artifactId>kryo-serializers</artifactId>
<version>0.42</version>
</dependency>
增加配置
protocol:
id: dubbo
name: dubbo
port: 12345
status: server
serialization: kryo
无参构造函数和Serializable接口
如果被序列化的类中不包含无参的构造函数, 则在Kryo的序列化中, 性能会大打折扣, 因为此时我们在底层将会用Java的序列化来透明的取代Kryo序列化, 所以, 尽可能为每一个被序列化的类添加无参构造函数是一种最佳实践
另外, Kryo和FST都不需要被序列化类实现Serializable接口, 但还是建议每个被序列化类都去实现Serializable接口, 因为这样可以保持和Java序列化以及dubbo序列化的兼容性。