背景

某天Springboot Admin監(jiān)控告警，detail顯示微服務(wù)A offline，經(jīng)排查發(fā)現(xiàn)此時(shí)服務(wù)處于假死狀態(tài)，推斷由于數(shù)據(jù)庫(kù)連接池maxThreads配置過小導(dǎo)致高并發(fā)場(chǎng)景下服務(wù)無法響應(yīng)外部請(qǐng)求。

解決方案

nacos 公共配置添加

druid 連接池配置

spring.datasource.druid.timeBetweenEvictionRunsMillis=60000
spring.datasource.druid.max-active=100
spring.datasource.druid.initial-size=5
spring.datasource.druid.max-wait=10000
spring.datasource.druid.min-idle=5

配置添加完后，我們重啟了被告警的服務(wù)，但由于配置改在公共配置上，且公共配置開啟了自動(dòng)刷新功能，接著其他微服務(wù)也出現(xiàn)了異常。

排查過程

1）應(yīng)急方案：由于配置直接改在了生產(chǎn)環(huán)境，為了保障線上的正常響應(yīng)，我們首先回退該配置，因?yàn)榇藭r(shí)服務(wù)狀態(tài)已正常，故而暫不進(jìn)行線程池配置的優(yōu)化；

2）問題排查：

以上是部分告警內(nèi)容（敏感信息已剔除）。

通過告警內(nèi)容可見，服務(wù)異常原因是因?yàn)闊o法正確加載數(shù)據(jù)源相關(guān)配置導(dǎo)致。

接著，我們?cè)偃ゲ榭捶?wù)器日志信息。

通過服務(wù)器日志可見，由于nacos公共配置refresh屬性設(shè)置為true，因此nacos客戶端會(huì)基于長(zhǎng)連接定時(shí)同步服務(wù)端配置。接下來我們從NacosContextRefresher源碼開始分析。

我們發(fā)現(xiàn)NacosContextRefresher對(duì)象中registerNacosListener方法，方法如下：

該方法其實(shí)就是基于消息總線機(jī)制，創(chuàng)建一個(gè)監(jiān)聽器，放入注冊(cè)服務(wù)，如果有刷新了，就會(huì)調(diào)用innerReceive方法，進(jìn)行刷新歷史的添加和刷新事件的通知，也就是你自己可以接受到這個(gè)事件后做點(diǎn)擴(kuò)展。

接下來我們繼續(xù)debug nacos源碼。

我們發(fā)現(xiàn)斷點(diǎn)走過listener之后直接進(jìn)入了CacheData的異常捕獲之中，通過點(diǎn)擊異常發(fā)現(xiàn)確實(shí)是druid連接池報(bào)錯(cuò)。

異常信息如下圖。

圖片很清晰的表明是由于druid中 initial-size無法設(shè)置導(dǎo)致nacos重載失敗并拋出異常。

接下來我們查看druid源碼，發(fā)現(xiàn)該字段初始化方法有對(duì)init狀態(tài)的判斷，若init為true，則方法拋出異常，該異常也即nacos CacheData中捕獲的異常。

我們繼續(xù)查看源碼，發(fā)現(xiàn)該字段為容器初始化加載組件完成后即設(shè)置完成，該字段無法動(dòng)態(tài)修改。

至此，該異常原因鏈路完整，出現(xiàn)此異常就是因?yàn)閐ruid擴(kuò)展參數(shù)中initial-size該字段不支持動(dòng)態(tài)更新導(dǎo)致。

總結(jié)

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論