源码分析Dubbo编码解码实现原理---Dubbo协议编码

   本节主要介绍了Dubbo协议的编码方式，涉及协议头、协议体具体的编码规则，默认使用Dubbo协议，其核心类图如下：

   在Dubbo整个框架中，codec2的可选值为dubbo、thrift，本文将重点分析Dubbo协议的编码解码。
   本文主要以Dubbo协议为例进行展开，其他通信方式，例如Thrift就不做过多分析，其实现思路基本是样的，Dubbo协议的编解码实现类为DubboCodec。

@SPI
public interface Codec2 {
    @Adaptive({Constants.CODEC_KEY})
    void encode(Channel channel, ChannelBuffer buffer, Object message) throws IOException;     

    @Adaptive({Constants.CODEC_KEY})
    Object decode(Channel channel, ChannelBuffer buffer) throws IOException;

    enum DecodeResult {
        NEED_MORE_INPUT, SKIP_SOME_INPUT
    }
}

   Codec2主要定义两个接口，一个枚举类型，
    ● void encode(Channel channel, ChannelBuffer buffer, Object message)：编码，在客户端发送消息时，需要将请求对象按照一定的格式（二进制流）将对象编码成二进制流，以便消息接收端能正确从二进流中按照格式解码出一个完整的请求信息。
    ● Object decode(Channel channel, ChannelBuffer buffer) ：解码，在消息接受端，按照协议的规范，从二进制流中解码出一个一个的请求信息，以便处理。
    ● DecodeResult.NEED_MORE_INPUT在解码过程中如果收到的字节流不是一个完整包时，结束此次读事件处理，等待更多数据到达， SKIP_SOME_INPUT：忽略掉一部分输入数据。
   编码解码实现类层次职责说明（从顶到下）：
    ● Codec2：编码解码根接口。
    ● AbstractCodec：编码解码抽象实现类，主要定义与协议无关的帮助类。
    1. protected static void checkPayload(Channel channel, long size)：检查负载长度是否符合协议规范。
    2. protected Serialization getSerialization(Channel channel)：根据序列化协议配置，获取对应的序列化实现类。
    3. protected boolean isClientSide(Channel channel)：判断当前是否是客户端
    4. protected boolean isServerSide(Channel channel)：判断当前是否是服务端
    ● TransportCodec 传输编码解码器，Codec2的具体实现类。
    ● TelnetCodec Dubbo telnet协议实现类。
    ● ExchangeCodec：交互层编码器，其他具体协议的基础类，可以看出是业务协议的模板类
    ● DubboCodec：dubbo协议。
   既然ExchangeCodec是业务协议，包含Dubbo协议的模板实现类，我们就从ExchangeCodec开始，探究   Dubbo编码解码实现原理。
   1、ExchangeCodec核心属性

// header length.
    protected static final int HEADER_LENGTH = 16;                                                         
    // magic header.
    protected static final short MAGIC = (short) 0xdabb;
    protected static final byte MAGIC_HIGH = Bytes.short2bytes(MAGIC)[0];
    protected static final byte MAGIC_LOW = Bytes.short2bytes(MAGIC)[1];
    // message flag.
    protected static final byte FLAG_REQUEST = (byte) 0x80;
    protected static final byte FLAG_TWOWAY = (byte) 0x40;
    protected static final byte FLAG_EVENT = (byte) 0x20;
    protected static final int SERIALIZATION_MASK = 0x1f;

   属性解读如下：
    ● HEADER_LENGTH ：协议头部长度，共16个字节。
    ● MAGIC ：魔数，固定为0xdabb，2个字节。
    ● MAGIC_HIGH ：魔数的高8位。
    ● MAGIC_LOW ：魔数的低8位。
    ● FLAG_REQUEST ：消息请求类型为消息请求。
    ● FLAG_TWOWAY ：消息请求类型为心跳。
    ● FLAG_EVENT ：消息请求类型为事件。
    ● SERIALIZATION_MASK ：serialization掩码。
    2、ExchangeCodec编码实现原理
    ExchangeCodec#encode

public void encode(Channel channel, ChannelBuffer buffer, Object msg) throws IOException {    // @1
        if (msg instanceof Request) {                                                                                                   // @2
            encodeRequest(channel, buffer, (Request) msg); 
        } else if (msg instanceof Response) {                                                                                       // @3
            encodeResponse(channel, buffer, (Response) msg);
        } else {
            super.encode(channel, buffer, msg);                                                                                     // @4
        }
    }

   代码@1：参数说明：Channel channel：Dubbo网络通道的抽象，底层实现有NettyChannel、MinaChannel；ChannelBuffer buffer：buffer抽象类，屏蔽netty,mina等底层实现差别；Object msg：请求对象、响应对象或其他消息对象。
   代码@2：如果msg是Request，则按照请求对象协议编码。
   代码@3：如果是响应对象，则按照响应协议编码。
   代码@4：如果是业务类对象（请求、响应），则使用父类默认的编码方式。
   2.1 ExchangeCodec#encodeRequest
   ExchangeCodec#encodeRequest

Serialization serialization = getSerialization(channel);     // @1
// header.
byte[] header = new byte[HEADER_LENGTH];               // @2
// set magic number.
Bytes.short2bytes(MAGIC, header);                                 // @3
// set request and serialization flag.
header[2] = (byte) (FLAG_REQUEST | serialization.getContentTypeId());  // @4

if (req.isTwoWay()) header[2] |= FLAG_TWOWAY;
if (req.isEvent()) header[2] |= FLAG_EVENT;
    // set request id.
    Bytes.long2bytes(req.getId(), header, 4);  // @5

   Step1：初始化协议头，同时填充部分字段。header[0]、header[1]、header[2]、header[4-11]，注意,header[3]未填充。
   代码@1：获取通道的序列化实现类。
   代码@2：构建请求头部,header数组，长度为16个字节。
   代码@3：首先填充头部的前两个字节，协议的魔数。header[0] = 魔数的高8个字节，header[1] = 魔数的低8个字节。
   代码@4：头部的第3个字节存储的是消息请求标识与序列化器类别，那这8位是如何存储的呢？
   首先看一下消息请求标志的定义：
      protected static final byte FLAG_REQUEST = (byte) 0x80; // 其二进制为 1000 0000
      protected static final byte FLAG_TWOWAY = (byte) 0x40; // 其二进制为 0100 0000
      protected static final byte FLAG_EVENT = (byte) 0x20; // 其二进制为 0010 0000
      protected static final int SERIALIZATION_MASK = 0x1f; // 其序列化的掩码，为什么是这样的呢？
   serialization.getContentTypeId() 返回的类型如下：
      CompactedJavaSerialization ： 4 二进制为0000 0010
      FastJsonSerialization : 6 二进制为0000 0110
      FstSerialization : 9 二进制为0000 1001
      Hessian2Serialization : 2 二进制为0000 0010
      JavaSerialization : 3 二进制为0000 0011
      KryoSerialization : 8 二进制为0000 1000
      NativeJavaSerialization ： 7 二进制为0000 0111
   结合代码header[2] = (byte) (FLAG_REQUEST | serialization.getContentTypeId()) 可以得出一个结论,header[2]为8字节标志位，前4位，表示消息请求类型，依次为：请求、twoway、event，保留位。后4为：序列化的类型，也就是说dubbo协议只支持16中序列化协议。
   代码@5：head[4]- head[11] 共8个字节为请求ID。Dubbo传输使用大端字节序列，也就说在接受端，首先读到的字节是高位字节。

public static void long2bytes(long v, byte[] b, int off) {
        b[off + 7] = (byte) v;
        b[off + 6] = (byte) (v >>> 8);
        b[off + 5] = (byte) (v >>> 16);
        b[off + 4] = (byte) (v >>> 24);
        b[off + 3] = (byte) (v >>> 32);
        b[off + 2] = (byte) (v >>> 40);
        b[off + 1] = (byte) (v >>> 48);
        b[off + 0] = (byte) (v >>> 56);
    }

ExchangeCodec#encodeRequest
        //encode request data.
        int savedWriteIndex = buffer.writerIndex();
        buffer.writerIndex(savedWriteIndex + HEADER_LENGTH);
        ChannelBufferOutputStream bos = new ChannelBufferOutputStream(buffer);        // @1
        ObjectOutput out = serialization.serialize(channel.getUrl(), bos);                             // @2
        if (req.isEvent()) {                                                                                                      //  @3
            encodeEventData(channel, out, req.getData());
        } else {
            encodeRequestData(channel, out, req.getData());
        }
        out.flushBuffer();
        if (out instanceof Cleanable) {
            ((Cleanable) out).cleanup();
        }
        bos.flush();
        bos.close();
        int len = bos.writtenBytes();                                                                                       //@4
        checkPayload(channel, len);
        Bytes.int2bytes(len, header, 12);                                                                                //@5

   Step2：编码请求体（body），协议的设计，一般是基于 请求头部+请求体构成。
   代码@1：对buffer做一个简单封装，返回ChannelBufferOutputStream实例。
   代码@2：根据序列化器，将通道的URL进行序列化，变存入buffer中。
   代码@3：根据请求类型，事件或请求对Request.getData()请求体进行编码，encodeEventData、encodeRequestData不同的编码器会重写该方法，下文详细看一下DubboCode的实现。
   代码@4：最后得到bos的总长度，该长度等于 (header+body)的总长度，也就是一个完整请求包的长度。
   代码@5：将包总长度写入到header的header[12-15]中。
   从ExchangeCodec#encodeRequest这个方法可以得知，Dubbo的整体传输协议由下图所示：

   2.3 Dubbo协议体编码
   2.3.1 Dubbo协议请求体(body)编码规则
   在ExchangeCodec#encodeRequest中，将会调用encodeRequestData对body进行编码

protected void encodeRequestData(Channel channel, ObjectOutput out, Object data) throws IOException {
        RpcInvocation inv = (RpcInvocation) data;

        out.writeUTF(inv.getAttachment(Constants.DUBBO_VERSION_KEY, DUBBO_VERSION));  
        out.writeUTF(inv.getAttachment(Constants.PATH_KEY));
        out.writeUTF(inv.getAttachment(Constants.VERSION_KEY));

        out.writeUTF(inv.getMethodName());
        out.writeUTF(ReflectUtils.getDesc(inv.getParameterTypes()));  
        Object[] args = inv.getArguments();
        if (args != null)
            for (int i = 0; i < args.length; i++) {
                out.writeObject(encodeInvocationArgument(channel, inv, i));
            }
        out.writeObject(inv.getAttachments());
    }

   该方法，依次将 dubbo、服务path（interface name）、版本号、方法名、方法参数类型描述，参数值、附加属性（例如参数回调等，该部分会在服务调用相关章节重点分析）。上述内容，根据不同的序列化实现，其组织方式不同，当然，其基本组织方式（标记位、长度 、 具体内容），将在下节中重点分析序列化的实现。
   2.3.2 Dubbo响应数据包编码规则

protected void encodeResponseData(Channel channel, ObjectOutput out, Object data) throws IOException {
        Result result = (Result) data;

        Throwable th = result.getException();
        if (th == null) {
            Object ret = result.getValue();
            if (ret == null) {
                out.writeByte(RESPONSE_NULL_VALUE);
            } else {
                out.writeByte(RESPONSE_VALUE);
                out.writeObject(ret);
            }
        } else {
            out.writeByte(RESPONSE_WITH_EXCEPTION);
            out.writeObject(th);
        }
    }

   1字节（请求结果），取值：RESPONSE_NULL_VALUE：表示空结果；RESPONSE_WITH_EXCEPTION：表示异常，RESPONSE_VALUE：正常响应。N字节的请求响应，使用readObject读取即可。
   3、ExchangeCodec解码实现原理
ExchangeCodec#decode

public Object decode(Channel channel, ChannelBuffer buffer) throws IOException {
        int readable = buffer.readableBytes();
        byte[] header = new byte[Math.min(readable, HEADER_LENGTH)];    // @1
        buffer.readBytes(header);  // @2
        return decode(channel, buffer, readable, header);   // @3
    }

   代码@1：创建一个byte数组，其长度为 头部长度和可读字节数取最小值。
   代码@2：读取指定字节到header中。
   代码@3：调用decode方法尝试解码。
   ExchangeCodec#decode

protected Object decode(Channel channel, ChannelBuffer buffer, int readable, byte[] header)

   Step1：解释一下方法的参数：

• Channel channel ：网络通道
• ChannelBuffer buffer ： 通道读缓存区
• int readable ：可读字节数。
• byte[] header ：已读字节数，（尝试读取一个完整头部）

   ExchangeCodec#decode

 // check magic number.
        if (readable > 0 && header[0] != MAGIC_HIGH
                || readable > 1 && header[1] != MAGIC_LOW) {     
            int length = header.length;
            if (header.length < readable) {                               
                header = Bytes.copyOf(header, readable);
                buffer.readBytes(header, length, readable - length);
            }
            for (int i = 1; i < header.length - 1; i++) {
                if (header[i] == MAGIC_HIGH && header[i + 1] == MAGIC_LOW) {
                    buffer.readerIndex(buffer.readerIndex() - header.length + i);
                    header = Bytes.copyOf(header, i);
                    break;
                }
            }
            return super.decode(channel, buffer, readable, header);
        }

   Step2：检查魔数，判断是否是dubbo协议，如果不是dubbo协议，则调用父类的解码方法，例如telnet协议。
   如果至少读取到一个字节，如果第一个字节与魔数的高位字节不相等或至少读取了两个字节，并且第二个字节与魔数的地位字节不相等，则认为不是   dubbo协议，则调用父类的解码方法,如果是其他协议的化，将剩余的可读字节从通道中读出，提交其父类解码。
   ExchangeCodec#decode

// check length.
if (readable < HEADER_LENGTH) {
     return DecodeResult.NEED_MORE_INPUT;
}

   Step3：如果是dubbo协议，判断可读字节的长度是否大于协议头部的长度，如果可读字节小于头部字节，则跳过本次读事件处理，待读缓存区中更多的数据到达。
   ExchangeCodec#decode

// get data length.
        int len = Bytes.bytes2int(header, 12);
        checkPayload(channel, len);

        int tt = len + HEADER_LENGTH;
        if (readable < tt) {
            return DecodeResult.NEED_MORE_INPUT;
        }

   Step4：如果读取到一个完整的协议头，然后读取消息体长度，如果当前可读自己小于消息体+header的长度，返回NEED_MORE_INPUT,表示放弃本次解码，待更多数据到达缓冲区时再解码。
   ExchangeCodec#decode

// limit input stream.
        ChannelBufferInputStream is = new ChannelBufferInputStream(buffer, len);   // @1

        try {
            return decodeBody(channel, is, header);                                                      // @2
        } finally {
            if (is.available() > 0) {
                try {
                    if (logger.isWarnEnabled()) {
                        logger.warn("Skip input stream " + is.available());
                    }
                    StreamUtils.skipUnusedStream(is);                  // @3
                } catch (IOException e) {
                    logger.warn(e.getMessage(), e);
                }
            }
        }

   代码@1：创建一个ChannelBufferInputStream，并限制最多只读取len长度的字节。
   代码@2：调用decodeBody方法解码协议体。
   代码@3：如果本次并未读取len个字节，则跳过这些字节，保证下一个包从正确的位置开始处理。
   这个其实就是典型的网络编程（自定义协议）的解码实现。
   由于本文只关注Dubbo协议的解码，故decodeBody方法的实现，请看DubboCodec#decodeBody。
   3.1 DubboCodec#decodeBody 详解

byte flag = header[2], proto = (byte) (flag & SERIALIZATION_MASK);
Serialization s = CodecSupport.getSerialization(channel.getUrl(), proto);
// get request id.
long id = Bytes.bytes2long(header, 4);

   Step1：根据协议头获取标记为(header[2])（根据协议可知，包含请求类型、序列化器）。
   DubboCodec#decodeBody

if ((flag & FLAG_REQUEST) == 0) {   // @1
            // decode response.
            Response res = new Response(id);       // @2
            if ((flag & FLAG_EVENT) != 0) {
                res.setEvent(Response.HEARTBEAT_EVENT);     // @3
            }
            // get status.
            byte status = header[3];         // @4
            res.setStatus(status);
            if (status == Response.OK) {
                try {
                    Object data;
                    if (res.isHeartbeat()) {
                        data = decodeHeartbeatData(channel, deserialize(s, channel.getUrl(), is));
                    } else if (res.isEvent()) {                                                                                                   // @5
                        data = decodeEventData(channel, deserialize(s, channel.getUrl(), is));
                    } else {
                        DecodeableRpcResult result;
                        if (channel.getUrl().getParameter(
                                Constants.DECODE_IN_IO_THREAD_KEY,
                                Constants.DEFAULT_DECODE_IN_IO_THREAD)) {                                      // @6
                            result = new DecodeableRpcResult(channel, res, is,
                                    (Invocation) getRequestData(id), proto);
                            result.decode();
                        } else {
                            result = new DecodeableRpcResult(channel, res,                                               // @7
                                    new UnsafeByteArrayInputStream(readMessageData(is)),
                                    (Invocation) getRequestData(id), proto);
                        }
                        data = result;
                    }
                    res.setResult(data);
                } catch (Throwable t) {
                    if (log.isWarnEnabled()) {
                        log.warn("Decode response failed: " + t.getMessage(), t);
                    }
                    res.setStatus(Response.CLIENT_ERROR);
                    res.setErrorMessage(StringUtils.toString(t));
                }
            } else {
                res.setErrorMessage(deserialize(s, channel.getUrl(), is).readUTF());
            }
            return res;
} 

   Step2：解码响应消息请求体。
   代码@1：根据flag标记相应标记为，如果与FLAG_REQUEST进行逻辑与操作，为0说明不是请求类型，那对应的就是响应数据包。
   代码@2：根据请求ID，构建响应结果。
   代码@3：如果是事件类型。
   代码@4：获取响应状态码。
   代码@5：如果是心跳事件，则直接调用readObject完成解码即可。
   代码@6：获取decode.in.io的配置值，默认为true，表示在IO线程中解码消息体，如果decode.in.io设置为false,则会在DecodeHanler中执行（受Dispatch事件派发模型影响）。
   代码@7：不在IO线程池中完成解码操作，实现方式也就是不在io线程中调用DecodeableRpcInvocation#decode方法。
   上述介绍了协议解码的经典实现流程，下文就不详细去探究具体针对dubbo协议进行解码，因为只要从一个完整的二进制流(ByteBuffer)按格式进行字节的读取，主要就是针对ByteBuffer API的应用。
   其他协议，将在主流程分析完成后，再选择一两个进行介绍。

---

欢迎加笔者微信号(dingwpmz)，加群探讨，笔者优质专栏目录：
1、源码分析RocketMQ专栏(40篇+)
2、源码分析Sentinel专栏(12篇+)
3、源码分析Dubbo专栏(28篇+)
4、源码分析Mybatis专栏
5、源码分析Netty专栏(18篇+)
6、源码分析JUC专栏
7、源码分析Elasticjob专栏
8、Elasticsearch专栏（20篇+）
9、源码分析MyCat专栏