建站
咨詢
售后
建站咨詢
新聞中心
hello，大家好呀，我是小樓。
湯旺ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)公司的ssl證書銷售渠道，可以享受市場價(jià)格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：028-86922220（備注：SSL證書合作）期待與您的合作！
最近一個(gè)技術(shù)群有同學(xué)at我，問我是否熟悉Dubbo，這我熟啊~
他說遇到了一個(gè)Dubbo異步調(diào)用的問題，懷疑是個(gè)BUG，提到BUG我可就不困了，說不定可以水，哦不...寫一篇文章。
問題復(fù)現(xiàn)
遇到問題，尤其不是自己遇到的，必須要復(fù)現(xiàn)出來才好排查，截一個(gè)當(dāng)時(shí)的聊天記錄：
他的問題原話是：
今天發(fā)現(xiàn)一個(gè)問題 有一個(gè)dubbo接口返回類型是boolean， 把接口從同步改成異步 server 端返回true 消費(fèi)端卻返回false，把boolean改成Boolean就能正常返回結(jié)果 有碰到過這個(gè)問題嗎
注意幾個(gè)重點(diǎn)：
- 接口返回類型是boolean
- 同步改為異步調(diào)用返回的boolean和預(yù)期不符合
- boolean基本類型改成包裝類型Boolean就能正常返回
聽到這個(gè)描述，我的第一反應(yīng)是這個(gè)返回結(jié)果定義為boolean肯定有問題！
《Java開發(fā)手冊》中就強(qiáng)調(diào)了RPC接口返回最好不要使用基本類型，而要使用包裝類型：
但這個(gè)是業(yè)務(wù)編碼規(guī)范，如果RPC框架不能使用boolean作為返回值，豈不是個(gè)BUG？而且他強(qiáng)調(diào)了是同步改為異步調(diào)用才出現(xiàn)這種情況，說明同步?jīng)]問題，有可能是異步調(diào)用的鍋。
于是我順口問了Dubbo的版本，說不定是某個(gè)版本的BUG。得到回復(fù)，是2.7.4版本的Dubbo。
于是我拉了個(gè)工程準(zhǔn)備復(fù)現(xiàn)這個(gè)問題。
哎，等等~
Dubbo異步調(diào)用的寫法可多了，于是我又問了下他是怎么寫的。
知道怎么寫的就好辦了，寫個(gè)Demo先：
定義Dubbo接口，一個(gè)返回boolean，一個(gè)返回Boolean
public interface DemoService {
boolean isUser();
Boolean isFood();
}實(shí)現(xiàn)Provider，為了簡單，都返回true，并且打了日志
@Service
public class DemoServiceImpl implements DemoService {
@Override
public boolean isUser() {
System.out.println("server is user : true");
return true;
}
@Override
public Boolean isFood() {
System.out.println("server is food : true");
return true;
}
}
實(shí)現(xiàn)Consumer，為了方便調(diào)用，實(shí)現(xiàn)了一個(gè)Controller，為了防止本機(jī)調(diào)用，injvm設(shè)置為false，這里是經(jīng)驗(yàn)，injvm調(diào)用邏輯和遠(yuǎn)程調(diào)用區(qū)別挺大，為了防止干擾，統(tǒng)一遠(yuǎn)程調(diào)用。
@RestController
public class DemoCallerService {
@Reference(injvm = false, check = false)
private DemoService demoService;
@GetMapping(path = "/isUser")
public String isUser() throws Exception {
BlockingQueueq = new ArrayBlockingQueue<>(1);
RpcContext.getContext().asyncCall(
() -> demoService.isUser()
).handle(
(isUser, throwable) -> {
System.out.println("client is user = " + isUser);
q.add(isUser);
return isUser;
});
q.take();
return "ok";
}
@GetMapping(path = "/isFood")
public String isFood() throws Exception {
BlockingQueueq = new ArrayBlockingQueue<>(1);
RpcContext.getContext().asyncCall(
() -> demoService.isFood()
).handle(
(isFood, throwable) -> {
System.out.println("client is food = " + isFood);
q.add(isFood);
return isFood;
});
q.take();
return "ok";
}
}
啟動(dòng)一個(gè)Provider，再啟動(dòng)一個(gè)Consumer進(jìn)行測試，果然和提問的同學(xué)表現(xiàn)一致：
- 先調(diào)用isUser（返回boolean），控制臺(tái)打印：
// client ...
client is user = false
// server ...
server is user : true
- 再調(diào)用isFood（返回Boolean），控制臺(tái)打印：
// client ...
client is food = true
// server ...
server is food : true
問題排查
- Debug
先猜測一下是哪里的問題，server端返回true，應(yīng)該問題不大，可能是client端哪里轉(zhuǎn)換出錯(cuò)了。但這都是猜想，我們直接從client端接收到的數(shù)據(jù)開始，如果接收的數(shù)據(jù)沒問題，肯定就是后續(xù)處理出了點(diǎn)小差錯(cuò)。
如果你非常熟悉Dubbo的調(diào)用過程，直接知道大概在這里
com.alibaba.dubbo.remoting.exchange.support.DefaultFuture#doReceived
我們打3個(gè)斷點(diǎn)：
斷點(diǎn)①為了證明我們的請求進(jìn)來了
斷點(diǎn)②為了證明進(jìn)了回調(diào)
斷點(diǎn)③為了能從接收到數(shù)據(jù)包的初始位置開始排查
按照我們的想法，執(zhí)行順序應(yīng)該是①、③、②，但是這里很奇怪，并沒有按照我們的預(yù)期執(zhí)行，而是先執(zhí)行①，再執(zhí)行②，最后執(zhí)行③！
這是為什么？對于排查問題中的這些沒有符合預(yù)期的蛛絲馬跡，要特別留心，很可能就是一個(gè)突破點(diǎn)。
于是我們對asyncCall這個(gè)方法進(jìn)行跟蹤：
發(fā)現(xiàn)這里callable調(diào)用call返回了false，然后false不為null且不是CompletableFuture的實(shí)例，于是直接調(diào)用了CompletableFuture.completedFuture(o)。
看到這里估計(jì)有部分小伙伴發(fā)現(xiàn)了問題，正常情況下，Dubbo的異步調(diào)用，執(zhí)行調(diào)用后，不會(huì)立馬得到結(jié)果，只會(huì)拿到一個(gè)null或者一個(gè)CompletableFuture，然后在回調(diào)方法中等待server端的返回。
這里的邏輯是如果返回的結(jié)果不為null且不為CompletableFuture的實(shí)例就直接將CompletableFuture設(shè)置為完成，立馬執(zhí)行回調(diào)。
暫且不管這個(gè)邏輯。
我們先看為什么會(huì)返回false。這里的callable是Dubbo生成的一個(gè)代理類，其實(shí)就是封裝了調(diào)用Provider的邏輯，有沒有辦法看看他封裝的邏輯呢？有！用arthas。
- arthas
我們下載安裝一個(gè)arthas，可以參考如下文檔：https://arthas.aliyun.com/doc/quick-start.html
attach到我們的Consumer進(jìn)程上，執(zhí)行sc命令（查看已加載的類）查看所有生成的代理類，由于我們的Demo就生成了一個(gè)，所以看起來很清晰
sc *.proxy0
再使用jad命令反編譯已加載的類：
jad org.apache.dubbo.common.bytecode.proxy0
看到這里估計(jì)小伙伴們又揭開了一層疑惑，this.handler.invoke就是去調(diào)用Provider，由于這里是異步調(diào)用，必然返回的是null，所以返回值定義為boolean的方法返回了false。
看到這里，估計(jì)小伙伴們對《Java開發(fā)手冊》里的規(guī)范有了更深的理解，這里的處理成false也是無奈之舉，不然難道返回true？屬于信息丟失了，無法區(qū)分是調(diào)用的返回還是其他異常情況。
我們再回頭看asyncCall：
圈出來的這段代碼令人深思，尤其是最后一行，為啥直接將CompletableFuture設(shè)置為完成？
從這個(gè)方法的名字能看出它是執(zhí)行異步調(diào)用，但這里有行注釋：
//local invoke will return directly
首先這個(gè)注釋的格式上下不一，//之后講道理是需要一個(gè)空格的，我覺得這里提個(gè)PR改下代碼格式肯定能被接受~
其次local invoke，我理解應(yīng)該是injvm這種調(diào)用，為啥要特殊處理？這個(gè)處理直接就導(dǎo)致了返回基本類型的接口在異步調(diào)用時(shí)必然會(huì)返回false的BUG。
我們測試一下injvm的調(diào)用，將demo中injvm參數(shù)改為true，Consumer和Provider都在一個(gè)進(jìn)程中，果然和注釋說的一樣：
server is user : true
client is user = true
如何修復(fù)
我覺得這應(yīng)該算是Dubbo的一個(gè)BUG，雖然這種寫法不提倡，但作為一款RPC框架，這個(gè)錯(cuò)誤還是不應(yīng)該。
修復(fù)的辦法就是在injvm分支這里加上判斷，如果是injvm調(diào)用還是保持現(xiàn)狀，如果不是injvm調(diào)用，直接忽略，走最后的return邏輯：
publicCompletableFuture asyncCall(Callable callable) {
try {
try {
setAttachment(ASYNC_KEY, Boolean.TRUE.toString());
final T o = callable.call();
//local invoke will return directly
if (o != null) {
if (o instanceof CompletableFuture) {
return (CompletableFuture) o;
}
if (injvm()) { // 偽代碼
return CompletableFuture.completedFuture(o);
}
} else {
// The service has a normal sync method signature, should get future from RpcContext.
}
} catch (Exception e) {
throw new RpcException(e);
} finally {
removeAttachment(ASYNC_KEY);
}
} catch (final RpcException e) {
// ....
}
return ((CompletableFuture) getContext().getFuture());
}
最后
排查過程中還搜索了github，但沒有什么發(fā)現(xiàn)，說明這個(gè)BUG遇到的人很少，可能是大家用異步調(diào)用本來就很少，再加上返回基本類型就更少，所以也不奇怪。
而且最新的代碼這個(gè)BUG也還存在，所以你懂我意思吧？這也是個(gè)提交PR的好機(jī)會(huì)~
不過話說回來，我們寫代碼最好還是要遵循規(guī)范，這些都是前人為我們總結(jié)的最佳實(shí)踐，如果不按規(guī)范來，可能就會(huì)有意想不到的問題。
當(dāng)然遇到問題也不要慌，代碼就在那躺著，工具也多，還怕搞不定嗎？
當(dāng)前名稱：如何抓到Dubbo異步調(diào)用的小BUG
分享路徑：http://www.dlmjj.cn/article/cciiidi.html
