dubbo系列之-入门
背景
DUBBO 的历史就不过多介绍了，打算将我对于dubbo的学习方式，应用，理解，等作为博客产出。此篇文章为入门介绍并不是介绍怎么一步步的搭建应用，run起hello world，这样的文章往往显得不耐操，今天我们换一种角度去切入，首先老样子我们启动生产者and消费者(为了更方便理解流程，我们采用xml配置)
项目代码
项目代码不是文章的重点，这里截下代码结构
结构大致如下(后面的内容都基于该项目结构)，总共分为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
<bean id="helloService" class="com.poizon.study.provider.service.impl.HelloServiceImpl"/>
<dubbo:application logger="slf4j" name="dubbo-provider"/>
<dubbo:protocol name="dubbo" port="20880"/>
<dubbo:registry protocol="zookeeper" address="localhost:2181"/>
<dubbo:service interface="com.poizon.study.api.service.HelloService" ref="helloService"/>
控制台输出如下：启动成功
启动消费者
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();
}
}
控制台输出如下： 调用成功
开个玩笑我们这里的整篇文章就结束了。
抓包分析
我们先不看代码，大家可以找一个自己习惯的抓包工具，博主这里用的是Wireshark(安利下一款666的不行的抓包工具，可以看的很深入，mac 最新版本安装会有bug 下载地址)
我们dubbo启动的provider 为20880端口，所以wireshark 我们观察本地网络20880端口的tcp/ip包信息
界面元素做一个简单介绍，头部Tab 有 No Time Source Destination Protocol length Info 等信息分别代表 No(序号) Time(触发时间已0开始单位是秒) Source(请求来源主机) Destination(请求目标主机) Protocol(协议) length(tcp数据长度) Info(数据简单描述)
tcp 协议分层我们不用关心，这里我们主要关注Data 层数据，既应用层数据
看着上面的图片，博主第一次探索的时候，并没有什么卵发现，大家先做个小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 出来
这张图可是经典中的经典，至于为什么这么说，这恐怕要等到我们整个dubbo系列讲完才能说明白，简单介绍下这图，主要表达的是Dubbo框架中的dubbo协议(注意区分这里非序列化协议) 主要包体内容，具体描述从官网摘抄
- Magic - Magic High & Magic Low (16 bits)
- 标识协议版本号，Dubbo 协议：0xdabb //这个相当于dubbo 的标志就像logo一样高的级别，我们对比下咋们之前记录的17长度的数据，如图有没有很像，没错这就是dubbo框架发出去的请求
各种观察
接下去我们先暂停解析，大家看看wireshark上面的记录，滚动条拉倒最后，这里的规律我就直接说了，每一分钟都有一个发往20880的请求，而且都来自dubbo客户端，既消费者，结合idea日志观察
已经很明了了，从生产者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相关的话题还是非常多的，今天的入门款就到这里了。
