dubbo系列之-入门-2020-12-27

dubbo系列之-入门

背景

DUBBO 的历史就不过多介绍了，打算将我对于dubbo的学习方式，应用，理解，等作为博客产出。此篇文章为入门介绍并不是介绍怎么一步步的搭建应用，run起hello world，这样的文章往往显得不耐操，今天我们换一种角度去切入，首先老样子我们启动生产者and消费者(为了更方便理解流程，我们采用xml配置)

项目代码

项目代码不是文章的重点，这里截下代码结构

image

结构大致如下(后面的内容都基于该项目结构)，总共分为3个模块 dubbo-consumer 消费者、dubbo-provider 生产者、dubbo-api 接口api。日志级别设置为info

前置操作

我们需要引入dubbo2.7.3 的pom 还有zk的工具curator包等；本地需要启动zookeeper

生产者

如下，三段朴实无华的代码

//HelloServiceImpl.java
@Service
public class HelloServiceImpl implements HelloService {

    @Override
    public String sayHelloToDubbo(String name) {
        return "dubbo always say hello to " + name;
    }
}

//ProviderApplication.java
public class ProviderApplication {

    public static void main(String[] args) throws IOException {
        ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext("dubbo-provider.xml");
        ctx.start();

        System.out.println("run success.");
        System.in.read();
    }

}
//dubbo-provider.xml

控制台输出如下：启动成功

image

启动消费者

public class ConsumerApplication {
    public static void main(String[] args) throws IOException {
        ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext("dubbo-consumer.xml");
        ctx.start();

        HelloService bean = ctx.getBean(HelloService.class);
        String jack = bean.sayHelloToDubbo("jack");
        System.out.println(jack);

        System.out.println("run success.");
        System.in.read();
    }
}

控制台输出如下：调用成功

image

开个玩笑我们这里的整篇文章就结束了。

抓包分析

我们先不看代码，大家可以找一个自己习惯的抓包工具，博主这里用的是Wireshark(安利下一款666的不行的抓包工具，可以看的很深入，mac 最新版本安装会有bug 下载地址)

我们dubbo启动的provider 为20880端口，所以wireshark 我们观察本地网络20880端口的tcp/ip包信息

image

界面元素做一个简单介绍，头部Tab 有 No Time Source Destination Protocol length Info 等信息分别代表 No(序号) Time(触发时间已0开始单位是秒) Source(请求来源主机) Destination(请求目标主机) Protocol(协议) length(tcp数据长度) Info(数据简单描述)

tcp 协议分层我们不用关心，这里我们主要关注Data 层数据，既应用层数据

image

看着上面的图片，博主第一次探索的时候，并没有什么卵发现，大家先做个小tip ，把对应的Length：17，还有底部的16进制数据记录下

1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16 17
da bb e2 00 00 00 00 00 00 00 00 06 00 00 00 01 4e

DUBBO 文档

思路继续切回dubbo，我们先来看一波dubbo 文档，这里大家自己去看吧，我觉得市面50%的文章或者书籍都是将文档加以运用的结果，我把文档中最经典的一张图copy 出来

image

这张图可是经典中的经典，至于为什么这么说，这恐怕要等到我们整个dubbo系列讲完才能说明白，简单介绍下这图，主要表达的是Dubbo框架中的dubbo协议(注意区分这里非序列化协议) 主要包体内容，具体描述从官网摘抄

Magic - Magic High & Magic Low (16 bits)
- 标识协议版本号，Dubbo 协议：0xdabb //这个相当于dubbo 的标志就像logo一样高的级别，我们对比下咋们之前记录的17长度的数据，如图有没有很像，没错这就是dubbo框架发出去的请求

image

各种观察

接下去我们先暂停解析，大家看看wireshark上面的记录，滚动条拉倒最后，这里的规律我就直接说了，每一分钟都有一个发往20880的请求，而且都来自dubbo客户端，既消费者，结合idea日志观察

image

已经很明了了，从生产者info日志里面可以观察到 "Received heartbeat..."，哈哈是每一分钟的心跳日志

心跳源码区别简单分析

心跳这边和老版本的dubbo不太一样，老版本是dubbo自己实现的一套，源码来自

org.apache.dubbo.remoting.exchange.support.header.HeaderExchangeClient#startHeartBeatTask中的

private void startHeartBeatTask(URL url) {
    if (!client.canHandleIdle()) {
        AbstractTimerTask.ChannelProvider cp = () -> Collections.singletonList(HeaderExchangeClient.this);
        int heartbeat = getHeartbeat(url);
        long heartbeatTick = calculateLeastDuration(heartbeat);
        this.heartBeatTimerTask = new HeartbeatTimerTask(cp, heartbeatTick, heartbeat);
        IDLE_CHECK_TIMER.newTimeout(heartBeatTimerTask, heartbeatTick, TimeUnit.MILLISECONDS);
    }
}
@Override
public boolean canHandleIdle() {
    return true;
}

可以清楚的看到dubbo新版本已经废弃该实现了，取而代之的是，netty(后面有机会分享) 的 IdleStateHandler

bootstrap.handler(new ChannelInitializer() {

    @Override
    protected void initChannel(Channel ch) throws Exception {
        int heartbeatInterval = UrlUtils.getHeartbeat(getUrl());
        NettyCodecAdapter adapter = new NettyCodecAdapter(getCodec(), getUrl(), NettyClient.this);
        ch.pipeline()//.addLast("logging",new LoggingHandler(LogLevel.INFO))//for debug
                .addLast("decoder", adapter.getDecoder())
                .addLast("encoder", adapter.getEncoder())
                //心跳检测在这里配置
                .addLast("client-idle-handler", new IdleStateHandler(heartbeatInterval, 0, 0, MILLISECONDS))
                .addLast("handler", nettyClientHandler);
        String socksProxyHost = ConfigUtils.getProperty(SOCKS_PROXY_HOST);
        if(socksProxyHost != null) {
            int socksProxyPort = Integer.parseInt(ConfigUtils.getProperty(SOCKS_PROXY_PORT, DEFAULT_SOCKS_PROXY_PORT));
            Socks5ProxyHandler socks5ProxyHandler = new Socks5ProxyHandler(new InetSocketAddress(socksProxyHost, socksProxyPort));
            ch.pipeline().addFirst(socks5ProxyHandler);
        }
    }
});

String HEARTBEAT_KEY = "heartbeat";
int DEFAULT_HEARTBEAT = 60 * 1000;

public static int getHeartbeat(URL url) {
    return url.getParameter(Constants.HEARTBEAT_KEY, Constants.DEFAULT_HEARTBEAT);
}

默认没有配置heartbeat 时间为 60秒。

协议分析

好了，回到我们dabb来，接下来我们继续看图，建议大家可以吧协议图在另一个显示器打开对着看才有疗效

接下来分析第三位e2 转为二进制是 11100010

1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16 17
da bb e2 00 00 00 00 00 00 00 00 06 00 00 00 01 4e

看图走到了Req/Res 这是请求响应标识，这里对应Req 为1既请求，第二位是Way(仅在 Req/Res 为1（请求）时才有用，标记是否期望从服务器返回值。如果需要来自服务器的返回值，则设置为1),这个也对上了，下一位Event 代表事件，那心跳是不是事件呢，我们从刚才的心跳入口看看，果不其然正儿八经的事件

org.apache.dubbo.remoting.exchange.support.header.HeartbeatTimerTask#doTask
@Override
protected void doTask(Channel channel) {
    try {
        //.....
            Request req = new Request();
            req.setEvent(Request.HEARTBEAT_EVENT);//看重点
            channel.send(req);

接下去是SerializationID 这回是序列化版本了，就是大家面试中问的比较多的Hession2 协议,dubbo 用5位来存协议id，这样服务端收到协议id就可以按照约定的协议去解析不会造成乱码,从 11100010 中看hession的序列化id 为2 我们验证下，找找看有没有,答案肯定是有的，不然我没办法继续bb了

package org.apache.dubbo.common.serialize;
public interface Constants {
    byte HESSIAN2_SERIALIZATION_ID = 2; //重点在这里，
    byte FASTJSON_SERIALIZATION_ID = 6;//大名鼎鼎的fastjson 排在第6
//....
    byte PROTOBUF_JSON_SERIALIZATION_ID = 21;
}
org.apache.dubbo.remoting.exchange.codec.ExchangeCodec#encodeResponse
header[2] = serialization.getContentTypeId(); 这是使用的地方这里不展开

Status 比较简单 8位的返回状态码，是生产者返回给消费者端，这里请求为0

后面我们在接着看8位，8位在java里面是Long储存，代表dubbo请求次数，依次加1(这里和tcp的syc ack 不是同一种概念，这里是应用层不要搞混)

1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16 17
da bb e2 00 00 00 00 00 00 00 00 06 00 00 00 01 4e

后面到了Data Length 32位，dubbo采用定长头的协议传输，这个主要用在拆包粘包中先不展开了，

1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16 17
da bb e2 00 00 00 00 00 00 00 00 06 00 00 00 01 4e

可以看到心跳事件的数据长度为1，我很好奇为啥心跳有event 了还有后面一个长度，于是打开源码，我们一看究竟,下面有点难的，跟断了可以重复几次，收货还是很大的

十六进制

dubbo.remoting.exchange.codec.ExchangeCodec.encodeRequest 这里是dubbo的编码解码
protected void encodeRequest(Channel channel, ChannelBuffer buffer, Request req) throws IOException {
    //....省略一些不相关的代码
    if (req.isEvent()) {
    // 因为心跳属于事件，会走这个分支
        encodeEventData(channel, out, req.getData());//我们一路dubug下去
    } else {
        encodeRequestData(channel, out, req.getData(), req.getVersion());
    }
    // write
    buffer.writerIndex(savedWriteIndex);
    buffer.writeBytes(header); // write header.
    buffer.writerIndex(savedWriteIndex + HEADER_LENGTH + len);
}

dubbo.common.serialize.hessian2.Hessian2ObjectOutput#writeObject
@Override
public void writeObject(Object obj) throws IOException {
    mH2o.writeObject(obj);
}

@Override
public void writeObject(Object object)throws IOException {
    if (object == null) {// 由于我们只是心跳事件，没有数据所以走这个分支
        writeNull();
        return;
    }//.......
    serializer.writeObject(object, this);
}

@Override
public void writeNull()
        throws IOException {
    int offset = _offset;
    byte[] buffer = _buffer;

    if (SIZE <= offset + 16) {
        flush();
        offset = _offset;
    }
    //这里是重点，我们的hession通过 'N' 这个字符串来代替空 
    //而查阅 ASCII 之后发现他的 16 进制为 4E,
    //我们移位17位数据中的最后一位发现 惊人的相似 也是4e
    buffer[offset++] = 'N';
    _offset = offset;
}

好了，通过文章来描述源码过程还是比较难得，大家有空可以线下一起交流，dubbo相关的话题还是非常多的，今天的入门款就到这里了。

dubbo系列之-入门-2020-12-27

背景

项目代码

前置操作

生产者

启动消费者

抓包分析

DUBBO 文档

各种观察

心跳源码区别简单分析

协议分析

你可能感兴趣的:(dubbo系列之-入门-2020-12-27)