Dubbo分析之Serialize层

作者: 小牛学堂 | 来源:发表于2018-10-15 10:12 被阅读0次

Dubbo整体设计

关于Dubbo的整体设计可以查看官方文档，下图可以清晰的表达Dubbo的整体设计：

1.图例说明

图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口，位于中轴线上的为双方都用到的接口；

图中从下至上分为十层，各层均为单向依赖，右边的黑色箭头代表层之间的依赖关系；

图中绿色小块的为扩展接口，蓝色小块为实现类，图中只显示用于关联各层的实现类；

图中蓝色虚线为初始化过程，即启动时组装链，红色实线为方法调用过程，即运行时调时链，紫色三角箭头为继承，可以把子类看作父类的同一个节点，线上的文字为调用的方法；

2.各层说明

config 配置层：对外配置接口，以 ServiceConfig, ReferenceConfig 为中心，可以直接初始化配置类，也可以通过 spring 解析配置生成配置类；

proxy 服务代理层：服务接口透明代理，生成服务的客户端 Stub 和服务器端 Skeleton, 以 ServiceProxy 为中心，扩展接口为 ProxyFactory；

registry 注册中心层：封装服务地址的注册与发现，以服务 URL 为中心，扩展接口为 RegistryFactory, Registry, RegistryService；

cluster 路由层：封装多个提供者的路由及负载均衡，并桥接注册中心，以 Invoker 为中心，扩展接口为 Cluster, Directory, Router, LoadBalance；

monitor 监控层：RPC 调用次数和调用时间监控，以 Statistics 为中心，扩展接口为 MonitorFactory, Monitor, MonitorService；

protocol 远程调用层：封装 RPC 调用，以 Invocation, Result 为中心，扩展接口为 Protocol, Invoker, Exporter；

exchange 信息交换层：封装请求响应模式，同步转异步，以 Request, Response 为中心，扩展接口为 Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer；

transport 网络传输层：抽象 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为 Channel, Transporter, Client, Server, Codec；

serialize 数据序列化层：可复用的一些工具，扩展接口为 Serialization, ObjectInput, ObjectOutput, ThreadPool；

本文将从最底层的serialize层开始来对dubbo进行源码分析；

通讯框架

dubbo的底层通讯使用的是第三方框架，包括：netty，netty4，mina和grizzly；默认使用的是netty，分别提供了server端(服务提供方)和client端(服务消费方)；下面已使用的netty为例来看那一下NettyServer的部分代码：

在启动服务提供方时就会调用此doOpen方法，用来启动服务端口，供消费方连接；以上代码就是常规的启动nettyServer端代码，因为本文重点介绍dubbo的序列化，所以这里主要看decoder和encoder，这两个类分别定义在NettyCodecAdapter中：

1.编码器

在NettyCodecAdapter定义了内部类InternalEncoder：

此类其实是对codec的包装，本身并没有做编码处理，下面重点看一下codec类，此类是一个接口类，有多种实现类，Codec2源码如下：

实现包括：TransportCodec，TelnetCodec，ExchangeCodec，DubboCountCodec以及ThriftCodec，当然也可以自行扩展；不可能启动时把每种类型都加载，dubbo是通过在配置文件中配置好所有的类型，然后在运行中需要什么类加载什么类，

配置文件的具体路径：META-INF/dubbo/internal/com.alibaba.dubbo.remoting.Codec2，内容如下：

获取具体Codec2的代码如下：

通过在url中获取是否有关键字codec，如果有的话就获取当前的值，dubbo默认的codec为dubbo；如果没有值默认为telnet；这里有默认值为dubbo，所以实现类DubboCountCodec会被ExtensionLoader进行加载并进行缓存，下面具体看一下DubboCountCodec的编解码；

DubboCountCodec内部调用的是DubboCodec的encode方法，看一下如何对Request对象进行编码的，具体代码块如下：

前两个字节存放了魔数：0xdabb；第三个字节包含了四个信息分别是：是否是请求消息(还是响应消息)，序列化类型，是否双向通信，是否是心跳消息；

在请求消息中直接跳过了第四个字节，直接在5-12位置存放了requestId，是一个long类型，第四个字节在如果是编码响应消息中会存放响应的状态；

代码往下看，buffer跳过了HEADER_LENGTH长度的字节，这里表示的是header部分的长度为16个字节，然后通过指定的序列化方式把data对象序列化到buffer中，序列化之后可以获取到data对象总共的字节数，用一个int类型来保存字节数，此int类型存放在header的最后四个字节中；

最后把buffer的writerIndex设置到写完header和data的地方，防止数据被覆盖；

2.解码器

在NettyCodecAdapter定义了内部类InternalEncoder，同样是调用DubboCodec的decode方法，部分代码如下：

首先读取Math.min(readable, HEADER_LENGTH)，如果readable小于HEADER_LENGTH，表示接收方连头部的16个字节还没接受完，需要等待接收；正常header接收完之后需要进行检查，主要包括：魔数的检查，header消息长度检查，消息体长度检查(检查消息体是否已经接收完成)；检查完之后需要对消息体进行反序列化，具体在decodeBody方法中：