Dubbo——协议详解

Dubbo协议详解

Dubbo协议设计参考了现有TCP/IP协议。一次RPC调用包括协议头和协议体两个部分。16字节长的报文头部主要携带了魔法数(0xdabb)，以及当前请求报文是否是Request、REsponse、心跳和事件的信息，请求时也会携带当前报文体内序列化协议编号。除此之外还携带了请求状态，以及请求唯一标识和报文体长度。

Dubbo协议字段解析：

偏移比特位	字段描述	作用
0~7	魔数高位	存储的是魔法数高位（0xda00）
8~15	魔数低位	存储的是魔法数低位（0xbb）
16	数据包类型	是否为双向RPC调用（比如方法调用有返回值），0为Response，1为Request
17	调用方式	仅在第16位被这设为1的情况下有效 0为单向调用，1位双向调用 比如在优雅停机时服务端发送readoly不需要双向调用，这里标志位就不会设定
18	事件标识	0为当前数据包是请求或响应包 1为当前数据包是心跳包，比如框架为了保活TCP连接，每次客户端和服务端相互发送心跳包时这个标志位被设定 设置了心跳报文不会透传到业务方法调用，仅用于框架内部保活机制
19~23	序列化器编号	2为HessianSerializatiion 3为JavaSerialization 4为CompactedJavaSerialization 6为FastJsonSerialization 7为NativJavaSerialization 8为KryoSerialization 9为FstSerialization
24~31	状态	20为OK 30为CLIENT_TIMEOUT 31为SERVER_TIMEOUT 40为BAD_REQUEST 50为BAD_RESPONSE …
32~95	请求编号	这8个字节存储RPC请求的唯一id，用来将请求和响应做关联
96~127	消息体长度	占用的4个字节存储消息体长度。在一次RPC请求过程中，消息体中一次会存储7部分内容

在消息体中，客户端严格按照序列化顺序写入消息，服务端也会遵循相同的顺序读取消息，客户端发起请求的消息体一次保存下列内容：Dubbo版本号、服务接口名、服务接口版本、方法名、参数类型、方法参数值和请求额外参数（attachment）。

完整状态响应码和作用：

状态值	状态符号	作用
20	OK	正确返回
30	CLIENT_TIMEOUT	客户端超时
31	SERVER_TIMEOUT	服务端超时
40	BAD_REQUEST	请求报文格式错误
50	BAD_RESPONSE	响应报文格式错误
60	SERVICE_NOT_FOUND	未找到匹配的服务
70	SERVICE_ERROR	服务调用错误
80	SERVER_ERROR	服务端内部错误
90	CLIENT_ERROR	客户端错误
100	SERVER_THREADPOOL_EXHAUSTED_ERROR	服务端线程池满拒绝执行

Dubbo响应标记：

状态值	状态符号	作用
5	RESPONSE_NULL_VALUE_WITH_ATTACHEMENTS	响应空值包含隐藏参数
4	RESPONSE_VALUE_WITH_ATTACHEMENTS	响应结果包含隐藏参数
3	RESPONSE_WITH_EXCEPTION_WITH_ATTACHMENTS	异常返回包含隐藏参数
2	RESPONSE_NULL_VALUE	响应空值
1	RESPONSE_VALUE	响应结果
0	RESPONSE_WITH_EXCEPTION	异常返回

在返回消息体中，会先把返回值状态标记写入输入流，根据标记状态判断RPC是否正常，比如一次正常RPC调用成功，则先往消息体中写一个标记1，紧接着再写方法返回值。

在网络通信中（基于TCP）需要解决网络粘包/解包的问题，一些常用解决办法比如用回车、换行、固定长度和特殊分隔符等进行处理，通过对前面协议的理解，很容易发现Dubbo其实就是用特殊符号0xdabb魔数来分隔处理粘包问题的。

客户端会使用多线程并发调用服务，Dubbo是如何做到正确响应调用线程的呢？

当客户端多个线程并发请求时，框架内部会调用Defaultfutre对象的get方法进行等待。在请求发起时，框架内部会创建Request对象，这个时候会被分配一个唯一的id，DefaultFuture可以从Request对象中获取id，并将关联关系存储到静态HashMap中，就是上图中的Future集合。当客户端收到响应时，会根据Response对象中的id，从Futures集合中查找对应的DefaultFuture对象，最终会唤醒对应的线程并通知结果。客户端也会启动一个定时扫描线程去探测超时没有返回的请求。