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对象，最终会唤醒对应的线程并通知结果。客户端也会启动一个定时扫描线程去探测超时没有返回的请求。