建站
咨詢
售后
建站咨詢
新聞中心
[[396584]]
本文轉(zhuǎn)載自微信公眾號(hào)「捉蟲大師」，作者捉蟲大師。轉(zhuǎn)載本文請聯(lián)系捉蟲大師公眾號(hào)。
讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來自于我們對(duì)這個(gè)行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價(jià)值的長期合作伙伴，公司提供的服務(wù)項(xiàng)目有：申請域名、網(wǎng)絡(luò)空間、營銷軟件、網(wǎng)站建設(shè)、松北網(wǎng)站維護(hù)、網(wǎng)站推廣。
背景
我在公司內(nèi)負(fù)責(zé)自研的dubbo注冊中心相關(guān)工作，群里經(jīng)常接到業(yè)務(wù)方反饋dubbo接口注銷報(bào)錯(cuò)。經(jīng)排查，確定是同一個(gè)接口調(diào)用了兩次注銷接口導(dǎo)致，由于我們的注冊中心注銷接口不能重復(fù)調(diào)用，調(diào)用第二次會(huì)因?yàn)閷?shí)例已經(jīng)注銷而報(bào)實(shí)例找不到的錯(cuò)誤。
雖然這個(gè)報(bào)錯(cuò)僅會(huì)打印一條錯(cuò)誤日志，不影響業(yè)務(wù)，但本著 follow through的精神，我決定還是一探究竟，更何況重復(fù)注銷也增加了應(yīng)用的結(jié)束時(shí)間，影響了發(fā)布回滾速度。
問題復(fù)現(xiàn)
拿到業(yè)務(wù)方的dubbo版本，基于開源2.7.3內(nèi)部定制的一個(gè)版本，該版本修改主要涉及安全漏洞修復(fù)以及一些業(yè)務(wù)適配，寫了個(gè)demo跑起來，然后kill，發(fā)現(xiàn)果然報(bào)錯(cuò)了。
為了確定不是內(nèi)部修改導(dǎo)致的問題，用開源的2.7.3版本再次測試，發(fā)現(xiàn)還是報(bào)錯(cuò)。
同時(shí)為了確定這是一個(gè)bug，我將dubbo版本修改為2.7.7做測試，發(fā)現(xiàn)該版本不再報(bào)錯(cuò)。
說明了重復(fù)注銷至少是開源dubbo 2.7.3的一個(gè)bug，在更高的2.7.7版本中已經(jīng)被修復(fù)。
于是有了解決方案：升級(jí)dubbo，但如果這么簡單就沒有這篇文章了。
內(nèi)部的dubbo已經(jīng)做了修改，想升級(jí)得把改動(dòng)merge到新版本，比較費(fèi)勁
就算升級(jí)了內(nèi)部的dubbo版本，也不可能這么快速推動(dòng)業(yè)務(wù)方升級(jí)
所以應(yīng)該首先找到bug是哪里導(dǎo)致的，其次看注冊中心的擴(kuò)展是否可以修復(fù)這個(gè)問題，如果不能修復(fù)，就只能在內(nèi)部的dubbo版本中修復(fù)該問題。
問題排查
懷疑ShutdownHook
由于這幾天研究過ShutdownHook(點(diǎn)擊查看原文跳轉(zhuǎn)《ShutdownHook原理》)，第一時(shí)間懷疑ShutdownHook可能有問題。
dubbo 2.7.3代碼有關(guān)ShutdownHook的實(shí)現(xiàn)在DubboShutdownHook類，順著代碼梳理出如下關(guān)系
看到dubbo本身和spring都注冊了ShutdownHook，更加懷疑這里是不是ShutdownHook注冊重復(fù)了。于是debug看看是否是注冊重復(fù)了，這里給一個(gè)小經(jīng)驗(yàn)，IntelliIDEA調(diào)試ShutdownHook執(zhí)行時(shí)，要手動(dòng)kill進(jìn)程才會(huì)觸發(fā)debug，點(diǎn)IDE上的關(guān)閉按鈕不會(huì)觸發(fā)
在DubboShutdownHook.doDestroy打上斷點(diǎn)，debug發(fā)現(xiàn)只會(huì)執(zhí)行一次，這說明spring和dubbo的ShutdownHook只會(huì)注冊一次，這是怎么實(shí)現(xiàn)的呢?經(jīng)過很多次測試，發(fā)現(xiàn)了dubbo一個(gè)很牛逼的設(shè)計(jì)。
DubboShutdownHook中有register和unregister方法，分別是注冊和注銷ShutdownHook，在這兩個(gè)方法上都打上斷點(diǎn)，在程序啟動(dòng)時(shí)發(fā)現(xiàn)這樣一個(gè)有趣的執(zhí)行順序：
總結(jié)一下是dubbo本身注冊了ShutdownHook，但如果用到了spring框架，spring框架在初始化時(shí)注銷了dubbo注冊的ShutdownHook，這樣就只保留了spring的ShutdownHook，真是秒啊!實(shí)現(xiàn)的代碼只有這短短幾行
- public static void addApplicationContext(ApplicationContext context) {
- CONTEXTS.add(context);
- if (context instanceof ConfigurableApplicationContext) {
- ((ConfigurableApplicationContext) context).registerShutdownHook();
- DubboShutdownHook.getDubboShutdownHook().unregister();
- }
- BeanFactoryUtils.addApplicationListener(context, SHUTDOWN_HOOK_LISTENER);
- }
于是懷疑的ShutdownHook問題被證明沒有任何問題了。
從注銷堆棧繼續(xù)排查
能穩(wěn)定復(fù)現(xiàn)的問題一定很好排查，借助IDE的debug來看兩次注銷的調(diào)用堆棧，在注冊中心擴(kuò)展的unregister方法處加斷點(diǎn)，可以看到如下兩次來源不同的堆棧信息
代碼中體現(xiàn)是
也就是說一次ShutdownHook執(zhí)行，觸發(fā)了兩次注銷。
接下來就比較好排查了，一步一步debug，這里解釋下
- AbstractRegistryFactory.destroyAll()是銷毀所有注冊中心，銷毀時(shí)會(huì)調(diào)研注冊中心的注銷接口
- destroyProtocols是銷毀所有的protocol，注冊中心的protocol在銷毀時(shí)拿到registry，然后調(diào)用了registry的注銷接口
那么dubbo 2.7.7是如何避免這個(gè)問題的呢?
在dubbo 2.7.7的代碼中，注冊中心的protocol在銷毀時(shí)獲取注冊中心稍微增加了點(diǎn)代碼
原來在注冊中心被銷毀后，destroyed變量被置為true，從而在registry protocol再次獲取注冊中心時(shí)，已經(jīng)拿不到了原先的注冊中心了，拿到的是一個(gè)空的注冊中心，調(diào)用注銷，自然沒有什么效果。
追溯了下github，這次PR是
https://github.com/apache/dubbo/pull/5450
這個(gè)修復(fù)在2.7.5就已經(jīng)修復(fù)了
總結(jié)
- dubbo重復(fù)注銷問題存在于2.7.0 ~ 2.7.4版本，2.7.5修復(fù)，zk注冊中心不會(huì)報(bào)錯(cuò)，可能無法感知，但它確實(shí)存在，也會(huì)拖慢應(yīng)用的關(guān)閉速度
- 通過追查發(fā)現(xiàn)，其實(shí)該問題可以在注冊中心的擴(kuò)展中解決，讓registry的destroy只能被調(diào)用一次
- 遇到無論多小的問題，有空都去鉆研下，你會(huì)收貨一些新知識(shí)，比如這次dubbo中ShutdownHook如此巧妙的設(shè)計(jì)
分享題目：排查Dubbo接口重復(fù)注銷問題，我發(fā)現(xiàn)了一個(gè)巧妙的設(shè)計(jì)
網(wǎng)頁URL：http://www.dlmjj.cn/article/cccshii.html
