dubbo系列之-入門
背景
DUBBO 的歷史就不過多介紹了管宵，打算將我對于dubbo的學(xué)習(xí)方式懊悯，應(yīng)用击胜，理解握联，等作為博客產(chǎn)出桦沉。此篇文章為入門介紹并不是介紹怎么一步步的搭建應(yīng)用，run起hello world金闽，這樣的文章往往顯得不耐操，今天我們換一種角度去切入剿骨，首先老樣子我們啟動生產(chǎn)者and消費(fèi)者(為了更方便理解流程代芜，我們采用xml配置)
項(xiàng)目代碼
項(xiàng)目代碼不是文章的重點(diǎn)，這里截下代碼結(jié)構(gòu)
結(jié)構(gòu)大致如下(后面的內(nèi)容都基于該項(xiàng)目結(jié)構(gòu))浓利，總共分為3個模塊 dubbo-consumer 消費(fèi)者挤庇、dubbo-provider 生產(chǎn)者、dubbo-api 接口api贷掖。日志級別設(shè)置為info
前置操作
我們需要引入dubbo2.7.3 的pom 還有zk的工具curator包等嫡秕；本地需要啟動zookeeper
生產(chǎn)者
如下，三段樸實(shí)無華的代碼
//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"/>
控制臺輸出如下：啟動成功
啟動消費(fèi)者
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();
}
}
控制臺輸出如下： 調(diào)用成功
開個玩笑我們這里的整篇文章就結(jié)束了苹威。
抓包分析
我們先不看代碼昆咽，大家可以找一個自己習(xí)慣的抓包工具，博主這里用的是Wireshark(安利下一款666的不行的抓包工具牙甫，可以看的很深入掷酗，mac 最新版本安裝會有bug 下載地址)
我們dubbo啟動的provider 為20880端口，所以wireshark 我們觀察本地網(wǎng)絡(luò)20880端口的tcp/ip包信息
界面元素做一個簡單介紹窟哺，頭部Tab 有 No Time Source Destination Protocol length Info 等信息分別代表 No(序號) Time(觸發(fā)時間已0開始單位是秒) Source(請求來源主機(jī)) Destination(請求目標(biāo)主機(jī)) Protocol(協(xié)議) length(tcp數(shù)據(jù)長度) Info(數(shù)據(jù)簡單描述)
tcp 協(xié)議分層我們不用關(guān)心泻轰，這里我們主要關(guān)注Data 層數(shù)據(jù)，既應(yīng)用層數(shù)據(jù)
看著上面的圖片且轨，博主第一次探索的時候浮声，并沒有什么卵發(fā)現(xiàn)，大家先做個小tip 旋奢，把對應(yīng)的Length：17泳挥，還有底部的16進(jìn)制數(shù)據(jù)記錄下
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 文檔
思路繼續(xù)切回dubbo，我們先來看一波dubbo 文檔黄绩，這里大家自己去看吧羡洁，我覺得市面50%的文章或者書籍都是將文檔加以運(yùn)用的結(jié)果，我把文檔中最經(jīng)典的一張圖copy 出來
這張圖可是經(jīng)典中的經(jīng)典爽丹，至于為什么這么說筑煮，這恐怕要等到我們整個dubbo系列講完才能說明白辛蚊，簡單介紹下這圖，主要表達(dá)的是Dubbo框架中的dubbo協(xié)議(注意區(qū)分這里非序列化協(xié)議) 主要包體內(nèi)容真仲，具體描述從官網(wǎng)摘抄
- Magic - Magic High & Magic Low (16 bits)
- 標(biāo)識協(xié)議版本號袋马，Dubbo 協(xié)議：0xdabb //這個相當(dāng)于dubbo 的標(biāo)志就像logo一樣高的級別屡江，我們對比下咋們之前記錄的17長度的數(shù)據(jù)损话，如圖有沒有很像，沒錯這就是dubbo框架發(fā)出去的請求
各種觀察
接下去我們先暫停解析殖属，大家看看wireshark上面的記錄软啼，滾動條拉倒最后桑谍，這里的規(guī)律我就直接說了，每一分鐘都有一個發(fā)往20880的請求祸挪，而且都來自dubbo客戶端锣披，既消費(fèi)者，結(jié)合idea日志觀察
已經(jīng)很明了了贿条，從生產(chǎn)者info日志里面可以觀察到 "Received heartbeat..."雹仿，哈哈是每一分鐘的心跳??日志
心跳源碼區(qū)別簡單分析
心跳這邊和老版本的dubbo不太一樣，老版本是dubbo自己實(shí)現(xiàn)的一套整以，源碼來自
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新版本已經(jīng)廢棄該實(shí)現(xiàn)了胧辽，取而代之的是，netty(后面有機(jī)會分享) 的 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);
}
默認(rèn)沒有配置heartbeat 時間為 60秒公黑。
協(xié)議分析
好了邑商，回到我們dabb來，接下來我們繼續(xù)看圖帆调，建議大家可以吧協(xié)議圖在另一個顯示器打開對著看才有療效
接下來分析第三位e2 轉(zhuǎn)為二進(jìn)制是 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 這是請求響應(yīng)標(biāo)識奠骄，這里對應(yīng)Req 為1既請求，第二位是Way(僅在 Req/Res 為1（請求）時才有用番刊，標(biāo)記是否期望從服務(wù)器返回值含鳞。如果需要來自服務(wù)器的返回值，則設(shè)置為1),這個也對上了芹务，下一位Event 代表事件蝉绷，那心跳是不是事件呢，我們從剛才的心跳入口看看枣抱，果不其然正兒八經(jīng)的事件
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);//看重點(diǎn)
channel.send(req);
接下去是SerializationID 這回是序列化版本了熔吗，就是大家面試中問的比較多的Hession2 協(xié)議,dubbo 用5位來存協(xié)議id，這樣服務(wù)端收到協(xié)議id就可以按照約定的協(xié)議去解析不會造成亂碼,從 11100010 中看hession的序列化id 為2 我們驗(yàn)證下佳晶，找找看有沒有,答案肯定是有的桅狠，不然我沒辦法繼續(xù)bb了
package org.apache.dubbo.common.serialize;
public interface Constants {
byte HESSIAN2_SERIALIZATION_ID = 2; //重點(diǎn)在這里，
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位 的返回狀態(tài)碼，是生產(chǎn)者返回給消費(fèi)者端中跌，這里請求為0
后面我們在接著看8位咨堤，8位在java里面是Long儲存，代表dubbo請求次數(shù)漩符，依次加1(這里和tcp的syc ack 不是同一種概念一喘，這里是應(yīng)用層不要搞混)
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采用定長頭的協(xié)議傳輸嗜暴，這個主要用在 拆包粘包 中先不展開了凸克，
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
可以看到心跳事件的數(shù)據(jù)長度為1，我很好奇為啥心跳有event 了還有后面一個長度闷沥，于是打開源碼萎战，我們一看究竟,下面有點(diǎn)難的，跟斷了可以重復(fù)幾次狐赡，收貨還是很大的
十六進(jìn)制
dubbo.remoting.exchange.codec.ExchangeCodec.encodeRequest 這里是dubbo的編碼解碼
protected void encodeRequest(Channel channel, ChannelBuffer buffer, Request req) throws IOException {
//....省略一些不相關(guān)的代碼
if (req.isEvent()) {
// 因?yàn)樾奶鴮儆谑录拆模瑫哌@個分支
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) {// 由于我們只是心跳事件，沒有數(shù)據(jù)所以走這個分支
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;
}
//這里是重點(diǎn)颖侄，我們的hession通過 'N' 這個字符串來代替空
//而查閱 ASCII 之后發(fā)現(xiàn)他的 16 進(jìn)制為 4E,
//我們移位17位數(shù)據(jù)中的最后一位發(fā)現(xiàn) 驚人的相似 也是4e
buffer[offset++] = 'N';
_offset = offset;
}
好了，通過文章來描述源碼過程還是比較難得享郊，大家有空可以線下一起交流览祖，dubbo相關(guān)的話題還是非常多的，今天的入門款就到這里了炊琉。
