這兩年捉過的蟲

hello，大家好，我是小樓。

1. 《記一次spring注解@Value不生效的深度排查》

時間撥回到2020年4月6日，周末，天晴，準(zhǔn)備將上周工作中遇到的一個問題解決并記錄下來。

是一個Spring和Dubbo結(jié)合起來無法入屬性的問題。

不過時間過去實(shí)在太久，現(xiàn)在讓我準(zhǔn)確地描述出來，有點(diǎn)困難，但我知道問題大概出在bean的初始化順序上。

文章寫完后，不知放哪里，于是匆匆注冊了個公眾號，取啥名呢？就叫「捉蟲大師」吧。

當(dāng)時匆忙地甚至忘了我還有個帶留言功能的公眾號，后來想想，將錯就錯吧，沒有留言也挺好，省的招來罵聲，影響寫作心情。

那時沒有排版，沒有任何技巧，樸實(shí)無華。

這便是我寫公眾號的初衷：記錄工作、學(xué)習(xí)中遇到的問題和解決過程，以及一些思考。

2. 《Sentinel在docker中獲取CPU利用率的一個BUG》

接下來的幾天瘋狂輸出，將之前工作中遇到的問題都一一回憶，記錄下來。

在搭建公司的Sentinel（限流熔斷系統(tǒng)）時發(fā)現(xiàn)，Sentinel的自適應(yīng)限流會根據(jù)CPU負(fù)載信息進(jìn)行限流，在Docker中獲取的CPU利用率是宿主機(jī)的，顯然這不合適。

當(dāng)時我還去github上提了issue，得到的回復(fù)是升級JDK，大家懂得，JDK萬年都是8，所以這條建議基本沒啥用。

不過后來，有位大佬用代碼解決了這個問題，我也把這段代碼Merge到了公司的系統(tǒng)上去。

這篇文章后來有好多小伙伴加我微信和我交流，這讓我發(fā)現(xiàn)，寫這類問題排查問題其實(shí)是有價值的。

3. 《以為是青銅，沒想到是王者的dubbo標(biāo)簽路由》

當(dāng)時在公司用Dubbo標(biāo)簽路由搭建了一套泳道測試環(huán)境，剛開始怎么都調(diào)不通，于是去看代碼，發(fā)現(xiàn)每次調(diào)用完了Dubbo都會把上下文清理掉，導(dǎo)致第二次調(diào)用丟失了標(biāo)簽。

于是又去github上問這算不算標(biāo)簽路由的BUG，得到回復(fù)否，但可以用filter的方式去把標(biāo)簽繼續(xù)帶下去，于是就通過這個思路解決問題。

有不少小伙伴來咨詢這個問題，聊過不少，還有直接要代碼的。

后來我發(fā)現(xiàn)大家有兩種方式解決這個問題，一個是像我這樣利用標(biāo)簽路由，另一個是自己再擴(kuò)展一個路由。

4. 《當(dāng)dubbo多注冊中心碰上標(biāo)簽路由》

還是標(biāo)簽路由，當(dāng)時在做一個遷移注冊中心的事，注冊中心遷移的中間態(tài)是多個注冊中心并存，當(dāng)時測試反饋，明明有Provider為什么調(diào)用不通。

查了半天，發(fā)現(xiàn)存在標(biāo)簽和多注冊中心時，不僅調(diào)用會走標(biāo)簽路由，甚至找注冊中心的邏輯也復(fù)用了RPC調(diào)用邏輯，也會走一遍標(biāo)簽路由，找不到合適的注冊中心時，就直接報錯。

顯然這是Dubbo的BUG，但2.7之后就沒這個問題了。

5. 《一次漫長的dubbo網(wǎng)關(guān)內(nèi)存泄露排查經(jīng)歷》

在搞注冊中心之前，還搞了一段時間的Dubbo網(wǎng)關(guān)。

這個問題非常的棘手，網(wǎng)關(guān)運(yùn)行地好好的，突然就內(nèi)存泄露了，不定時，可能幾周，可能幾個月。

當(dāng)時真的是絞盡腦汁，能用的方法都用上了，也查不出個所以然。剛好當(dāng)時看了「閃電俠」的《Netty堆外內(nèi)存排查盛宴》文章，文中通過植入一段監(jiān)聽代碼來發(fā)現(xiàn)問題。

這個啟發(fā)了我，于是我也在網(wǎng)關(guān)中植入了監(jiān)控代碼，終于讓我抓到了到底哪里泄露。

后來在網(wǎng)絡(luò)上看，其實(shí)有一些人的博客記錄了這個問題，但當(dāng)時很難從網(wǎng)上準(zhǔn)確找到，只有經(jīng)歷過，才知道問題是不是同一個。

6. 《skywalking內(nèi)存泄露排查》

雖然標(biāo)題是SkyWalking，其實(shí)是SkyWalking和Sentinel共同作用的結(jié)果，這個問題當(dāng)時直接導(dǎo)致了線上故障。

事后復(fù)盤，主要原因是測試環(huán)境與線上環(huán)境不一致導(dǎo)致。

所以說，灰度上線很重要。

至于問題排查，這篇可以算的上是比較典型的內(nèi)存泄露問題。

7. 《從nacos客戶端的TIME_WAIT說起》

再說回注冊中心遷移，當(dāng)時是往Nacos遷移，測試階段遇到了Nacos客戶端會出現(xiàn)大量TIME_WAIT的問題，還好測試充分，這要是上線了，也是個大故障。

但這要寫篇文章似乎也太短了，于是就帶大家復(fù)習(xí)了一下TCP的3次握手。

8. 《幾個你不知道的dubbo注冊中心細(xì)節(jié)》

這篇關(guān)于Dubbo注冊中心配置的文章算是一個小小的問題匯總，包括如何配置backup地址，如何配置多注冊中心的一些細(xì)節(jié)，都是從實(shí)際的生產(chǎn)中發(fā)現(xiàn)的。

9. 《升級dubbo，小心default.version！》

本文也是一次線上問題記錄，是Dubbo2.6和2.7的一個關(guān)于version/group的兼容性問題，很容易出問題。

本文當(dāng)時被一個大佬轉(zhuǎn)載了，他換了個標(biāo)題《升級Dubbo，竟然搞出線上P0故障》，果然標(biāo)題黨比較容易吸引人點(diǎn)擊。

10. 《排查dubbo接口重復(fù)注銷問題，我發(fā)現(xiàn)了一個巧妙的設(shè)計》

寫這篇文章時，我已經(jīng)開始負(fù)責(zé)自研的注冊中心了，當(dāng)時用戶經(jīng)常反饋Dubbo在停止時會報錯，我查了下發(fā)現(xiàn)有些版本的Dubbo會重復(fù)注銷。

當(dāng)時還查了不少資料，也找到了徐媽（Kirito的技術(shù)分享）關(guān)于Dubbo優(yōu)雅停機(jī)的文章，至今印象深刻。

11. 《rocketmq優(yōu)雅停機(jī)往事》

這是一篇舊文，我還在做業(yè)務(wù)時發(fā)現(xiàn)的問題，并嘗試了各種方法解決，雖然問題不大，但解決起來還是蘊(yùn)藏著很多技術(shù)點(diǎn)，后來也看到了官方在rocketmq的spring-boot-starter是如何解決的。

這篇文章最早寫的比較樸素，發(fā)布在博客上，當(dāng)時我想試驗(yàn)下在文章中插入表情包，會不會讀者反響很好，但結(jié)果是并沒有多好。

我想并不是表情包不好，而是要合乎時宜、適度地使用。

12. 《給dubbo貢獻(xiàn)源碼，做夢都在修bug》

本文是當(dāng)時看Dubbo的Redis注冊中心源碼時發(fā)現(xiàn)的一個問題，并且提交源碼解決了。

當(dāng)時很神奇的一個事情是一個單元測試運(yùn)行時間稍微久了一點(diǎn)，然后當(dāng)天晚上竟然在夢里發(fā)現(xiàn)了白天提交的代碼有BUG，第二天早上起來看，果然有問題，而且夢里精準(zhǔn)到了出問題的代碼行數(shù)，簡直不可思議。

故事絕對真實(shí)。

13. 《Dubbo No provider問題排查思路》

這也是篇總結(jié)性質(zhì)文章，對于工作中有人問我Dubbo為什么調(diào)用時報No Provider錯時，我就把這篇文章甩給他，讓他先自查。

后來發(fā)現(xiàn)Dubbo的新版本在日志中透出了更詳細(xì)的信息，讓排查變得非常簡單，如果當(dāng)時更近一步，應(yīng)該也能想到這個方法。

14. 《案例分享 | dubbo 2.7.12 bug導(dǎo)致線上故障》

這篇文章算是個分水嶺，在這之前，我都是悶頭寫文，在這之后，開啟了投稿之旅。

當(dāng)時這篇文章被歪歪（why技術(shù)）轉(zhuǎn)發(fā)了下，于是很多大佬紛紛前來轉(zhuǎn)載。

雖然對我來說，本質(zhì)上沒有變化，但讀者變得更多了。

15. 《dubbo 配置 loadbalance 不生效？擼一把源碼》

也是一篇非常偏細(xì)節(jié)的文章，但寫文我也在想，關(guān)于Dubbo的文章，本身受眾就不算多，而且如此細(xì)節(jié)，有沒有寫的必要？

于是后面有意減少了關(guān)于Dubbo的文章，但實(shí)在碰到有意思的我還是會寫下來。

16. 《Java 問題排查技術(shù)分享》

這是在前公司的一次分享，分享主題是如何排查Java問題，當(dāng)時只是分享了一點(diǎn)點(diǎn)想法和案例。

后來我還有個寫一本問題排查方法論+案例的電子書，但始終沒有下手。

可能是太懶了吧。

17. 《我好像發(fā)現(xiàn)了一個Go的Bug？》

再后來，開始寫Go，一次用Go做Benchmark時，發(fā)現(xiàn)竟然超時了。

不得不說問題排查久了，是有一種感覺的，這個超時感覺就有問題。

于是花了2天時間，把Benchmark的源碼看了一遍，發(fā)現(xiàn)確實(shí)有問題，于是給Go提了BUG，官方也承認(rèn)有BUG。

而且也提交了修復(fù)代碼，但直到現(xiàn)在也沒合并。

不過也水了2篇文章，不虧。

18. 《踩了個DNS解析的坑，但我還是沒想通》

遇到了這么多問題，有沒有沒查出原因的？還真有。

這次就是，用Go的httpClient遇到了DNS的問題，雖然解決了，但沒查出根因。

由于時間比較緊張，于是不再糾結(jié)，遂記錄下此文，趁著這個機(jī)會把Go的DNS解析流程擼了一遍，后來也看了Java的實(shí)現(xiàn)，大差不差。

19. 《眼見不一定為實(shí)：調(diào)用鏈HBase傾斜修復(fù)》

這是一位朋友的投稿，其實(shí)跟HBase關(guān)系不大，但大家看到HBase就不想點(diǎn)開。

于是這篇文章的閱讀率很低。

20. 《太極限了，JDK的這個BUG都能被我踩到》

其實(shí)是個很簡單的BUG，不錯的地方是結(jié)合了實(shí)踐。

這篇文章也是寫了很久沒寫完，當(dāng)時一個勁地鉆牛角尖，想從JVM實(shí)現(xiàn)的角度看看為什么會出這種BUG，后來發(fā)現(xiàn)沒啥好寫的。

直到某一天想到是否可以換個角度寫，沒想到寫出來效果還挺好。

21. 《這不會又是一個Go的BUG吧？》

這篇文章記錄了一個線上Go讀寫鎖使用不當(dāng)導(dǎo)致的問題。

寫Java出身的我，感覺Go的實(shí)現(xiàn)很奇怪，于是和很多小伙伴討論，寫Java的小伙伴說Go的讀寫鎖有問題，寫Go的小伙伴認(rèn)為Java的鎖實(shí)現(xiàn)不合理。

究竟誰有問題？

Go沒有問題，Java也沒有問題，有問題的是我們不夠了解他們，所以學(xué)習(xí)一門編程語言，還是得腳踏實(shí)地，系統(tǒng)地學(xué)習(xí)一遍。

22. 《抓到Dubbo異步調(diào)用的小BUG，再送你一個貢獻(xiàn)開源代碼的機(jī)會》

這篇文章來源一個技術(shù)群，群里討論了大半天基本把結(jié)論說了出來，我只是事后又驗(yàn)證了一遍，用有趣的文字記錄下來。

好久沒用Arthas的我，又復(fù)習(xí)了一下它的用法，感覺很爽。

這22個問題只是開端，未完待續(xù)~