用慢排查與配置調(diào)優(yōu)實(shí)戰(zhàn)指南)
1. 項(xiàng)目概述與問(wèn)題背景1.1 核心需求解析我不知道你有沒(méi)有踩過(guò)這樣一個(gè)坑服務(wù)用 Spring Cloud Alibaba Nacos 做了服務(wù)注冊(cè)與發(fā)現(xiàn)平時(shí)用起來(lái)一切正常但每次服務(wù)剛啟動(dòng)完第一次去調(diào)用別的服務(wù)接口總感覺(jué)像卡住了一樣慢得離譜。等這第一次調(diào)用過(guò)去了后面的請(qǐng)求又一馬平川快得很。這個(gè)首次調(diào)用慢的問(wèn)題在微服務(wù)架構(gòu)里屬于那種不痛不癢、但真遇到又很折磨人的隱性 Bug。說(shuō)它不痛不癢是因?yàn)樗挥绊懽罱K結(jié)果——請(qǐng)求最終還是成功了只是慢了那么幾百毫秒甚至幾秒說(shuō)它折磨人是因?yàn)樗h(huán)境、版本、部署方式強(qiáng)行掛鉤同一個(gè)版本在這里沒(méi)事?lián)Q個(gè)環(huán)境就現(xiàn)原形排查起來(lái)非常折騰。這篇文章不是講解 Nacos 基礎(chǔ)概念的入門(mén)文而是要落地解決首次調(diào)用慢這一具體問(wèn)題的排障實(shí)錄。我會(huì)從 Nacos 的配置操作講起覆蓋原生部署和 Docker 部署兩種情況然后帶你一步步定位首次調(diào)用慢的根源并給出可以直接抄作業(yè)的配置方案。先說(shuō)結(jié)論Nacos 首次調(diào)用慢這個(gè)問(wèn)題絕大多數(shù)情況下不是 Nacos 服務(wù)端的問(wèn)題而是客戶(hù)端在啟動(dòng)初期與配置中心、注冊(cè)中心交互過(guò)程中一堆細(xì)節(jié)配置沒(méi)有調(diào)優(yōu)導(dǎo)致的。Nacos 本身只是一個(gè)分布式基礎(chǔ)設(shè)施它把服務(wù)注冊(cè)、發(fā)現(xiàn)、配置管理的活干完了但客戶(hù)端怎么配合它干活這個(gè)配合的細(xì)節(jié)直接決定了首次調(diào)用的體驗(yàn)。1.2 影響范圍與排查思路這個(gè)問(wèn)題的典型出現(xiàn)場(chǎng)景包括服務(wù)剛啟動(dòng)第一筆外部請(qǐng)求進(jìn)來(lái)到真正發(fā)出下游調(diào)用之間延遲明顯。多實(shí)例部署環(huán)境中部分實(shí)例首次調(diào)用慢部分實(shí)例正常。測(cè)試環(huán)境一切正常生產(chǎn)環(huán)境首次調(diào)用偶發(fā)超時(shí)。服務(wù)重啟后短時(shí)間內(nèi)大量請(qǐng)求涌入出現(xiàn)集中的慢調(diào)用或超時(shí)。如果你遇到了上述任意一種又不想每次重啟服務(wù)都提心吊膽這篇文章一定要往下看。排查思路的核心在于先確認(rèn)慢在哪一段再確認(rèn)導(dǎo)致慢的機(jī)制。Nacos 場(chǎng)景下慢的環(huán)節(jié)通常集中在服務(wù)發(fā)現(xiàn)、配置拉取、客戶(hù)端線(xiàn)程初始化三個(gè)環(huán)節(jié)。定位到具體環(huán)節(jié)之后配置調(diào)整才有針對(duì)性。下面我按自己的實(shí)戰(zhàn)經(jīng)過(guò)把整個(gè)配置過(guò)程和采坑點(diǎn)完整過(guò)一遍。2. Nacos 配置操作全流程2.1 配置之前先搞懂 Nacos 的兩個(gè)核心角色在動(dòng)手配置之前必須先分清你用的是 Nacos 的哪個(gè)能力。Nacos 本質(zhì)上是一個(gè)注冊(cè)中心 配置中心的二合一組件而這兩個(gè)角色對(duì)客戶(hù)端的影響路徑完全不同。注冊(cè)中心負(fù)責(zé)服務(wù)實(shí)例的管理。服務(wù)啟動(dòng)時(shí)客戶(hù)端把自身 IP、端口、健康狀態(tài)注冊(cè)到 Nacos 服務(wù)端服務(wù)調(diào)用方Consumer通過(guò) Nacos 獲取目標(biāo)服務(wù)的實(shí)例列表再根據(jù)負(fù)載均衡策略選擇實(shí)例發(fā)起調(diào)用。這一條鏈路如果出了問(wèn)題直接表現(xiàn)就是找不到服務(wù)或者拿到的是過(guò)期的實(shí)例列表。配置中心負(fù)責(zé)配置項(xiàng)的動(dòng)態(tài)管理。服務(wù)啟動(dòng)時(shí)客戶(hù)端向 Nacos 拉取配置運(yùn)行期間客戶(hù)端通過(guò)長(zhǎng)輪詢(xún)監(jiān)聽(tīng)配置變化。這一條鏈路如果出了問(wèn)題直接表現(xiàn)是配置沒(méi)生效或者啟動(dòng)時(shí)卡在拉配置環(huán)節(jié)。首次調(diào)用慢恰恰就集中在這兩條鏈路交匯的地方。服務(wù)啟動(dòng)后本地 Spring 容器的初始化工作可能早就完成了但 Nacos 客戶(hù)端的某些異步動(dòng)作還在進(jìn)行中這時(shí)候第一筆請(qǐng)求打進(jìn)來(lái)就會(huì)撞上客戶(hù)端暫時(shí)還沒(méi)準(zhǔn)備好的尷尬期。2.2 原生部署 Nacos 的基本配置操作先講原生部署。很多團(tuán)隊(duì)在測(cè)試環(huán)境會(huì)直接用解壓包方式啟動(dòng) Nacos Server雖然 Docker 已經(jīng)很普及了但原生部署依然有它不可替代的場(chǎng)景便于直接查看日志、便于調(diào)試、不依賴(lài)鏡像倉(cāng)庫(kù)。啟動(dòng) Nacos Server 前最基礎(chǔ)也最關(guān)鍵的配置在conf/application.properties### 是否開(kāi)啟認(rèn)證 nacos.core.auth.enabledfalse ### 控制臺(tái)登錄用戶(hù)名密碼開(kāi)啟認(rèn)證時(shí)生效 nacos.core.auth.plugin.nacos.token.secret.keySecretKey012345678901234567890123456789012345678901234567890123456789 ### 服務(wù)端口 server.port8848 ### 數(shù)據(jù)源配置默認(rèn)使用內(nèi)嵌 Derby生產(chǎn)建議切換 MySQL spring.datasource.platformmysql db.num1 db.url.0jdbc:mysql://127.0.0.1:3306/nacos_config?characterEncodingutf8connectTimeout1000socketTimeout3000autoReconnecttrueuseUnicodetrueuseSSLfalseserverTimezoneAsia/Shanghai db.user.0nacos db.password.0nacos這里有一個(gè)非常反直覺(jué)的坑很多人以為 Nacos Server 是內(nèi)存組件配置里沒(méi)有數(shù)據(jù)庫(kù)字段也沒(méi)關(guān)系。但 Nacos Server 的配置數(shù)據(jù)、注冊(cè)的持久化實(shí)例信息臨時(shí)實(shí)例除外都依賴(lài)數(shù)據(jù)庫(kù)存儲(chǔ)。默認(rèn)的內(nèi)嵌 Derby 只適合單機(jī)跑著玩一旦服務(wù)重啟Derby 數(shù)據(jù)文件可能損壞導(dǎo)致配置丟失。我自己就遇到過(guò)明明配置在頁(yè)面上能看到重啟之后全部蒸發(fā)的情況就是因?yàn)橛昧?Derby 且沒(méi)有做數(shù)據(jù)備份。所以生產(chǎn)環(huán)境務(wù)必配 MySQL別嫌麻煩。啟動(dòng)時(shí)單機(jī)模式用-m standalone參數(shù)sh startup.sh -m standalone如果是在 Linux 服務(wù)器上啟動(dòng)默認(rèn)是集群模式不指定standalone的話(huà)會(huì)嘗試去連其他節(jié)點(diǎn)然后一直報(bào)連接失敗。這個(gè)坑很常見(jiàn)尤其是在測(cè)試環(huán)境隨便拉起來(lái)一個(gè)服務(wù)用的時(shí)候。2.3 Docker 部署 Nacos 的操作細(xì)節(jié)Docker 部署 Nacos 其實(shí)是更主流的方式尤其是 Kubernetes 環(huán)境里Nacos Server 往往以 StatefulSet 方式部署。對(duì)于單體 Docker 部署最簡(jiǎn)潔的啟動(dòng)命令如下docker run -d \ --name nacos-server \ -p 8848:8848 \ -p 9848:9848 \ -p 9849:9849 \ -e MODEstandalone \ -e SPRING_DATASOURCE_PLATFORMmysql \ -e MYSQL_SERVICE_HOST127.0.0.1 \ -e MYSQL_SERVICE_PORT3306 \ -e MYSQL_SERVICE_DB_NAMEnacos_config \ -e MYSQL_SERVICE_USERnacos \ -e MYSQL_SERVICE_PASSWORDnacos \ nacos/nacos-server:latest注意這里我把 9848 和 9849 端口也映射出來(lái)了。Nacos 從 2.x 版本開(kāi)始客戶(hù)端與服務(wù)端之間的 gRPC 通信走 9848 端口9849 是服務(wù)端之間的 gRPC 通信端口。很多人只映射了 8848 端口結(jié)果注冊(cè)中心頁(yè)面能打開(kāi)服務(wù)也能注冊(cè)上但客戶(hù)端拉取服務(wù)列表時(shí)需要通過(guò) gRPC 建立長(zhǎng)連接端口不通就一直在重試表現(xiàn)出來(lái)就是服務(wù)剛啟動(dòng)時(shí)各種超時(shí)、首次調(diào)用極慢。這是首次調(diào)用慢的一個(gè)非常隱蔽的誘因Docker 容器沒(méi)把 9848 端口暴露出來(lái)。我建議你先自查這一條如果端口映射有缺失后續(xù)的配置優(yōu)化做得再好都白搭。注意Nacos 2.x 版本引入 gRPC 通信機(jī)制之后除了 8848 主端口還必須保證 9848客戶(hù)端 gRPC和 9849服務(wù)端 gRPC的端口可達(dá)。端口不通會(huì)導(dǎo)致客戶(hù)端連接狀態(tài)不穩(wěn)定間接引發(fā)首次調(diào)用慢。2.4 客戶(hù)端依賴(lài)與基礎(chǔ)配置服務(wù)端配置完之后客戶(hù)端側(cè)的 Maven 依賴(lài)也需要對(duì)齊版本。Spring Cloud Alibaba、Spring Cloud、Spring Boot、Nacos Client 四者之間的版本關(guān)系堪稱(chēng)微服務(wù)領(lǐng)域最大的版本深水區(qū)之一。我見(jiàn)過(guò)太多人把 Spring Cloud Alibaba 版本隨便升一升Nacos Client 的版本也跟著變了然后該通的調(diào)不通不該有的 Bug 全冒出來(lái)了。以當(dāng)前比較穩(wěn)定的組合為例組件版本Spring Boot2.6.xSpring Cloud2021.0.xSpring Cloud Alibaba2021.0.5.0Nacos Client由 Spring Cloud Alibaba 管理2.2.xMaven 依賴(lài)坐標(biāo)如下dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-discovery/artifactId /dependency dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-config/artifactId /dependency配置文件application.yml中核心配置項(xiàng)如下spring: application: name: order-service cloud: nacos: discovery: server-addr: 127.0.0.1:8848 namespace: public group: DEFAULT_GROUP register-enabled: true config: server-addr: 127.0.0.1:8848 file-extension: yaml namespace: public group: DEFAULT_GROUP refresh-enabled: true到這里為止基礎(chǔ)配置是能跑通的但離首次調(diào)用不慢還有距離。接下來(lái)進(jìn)入重點(diǎn)也就是首次調(diào)用慢的具體定位和解決。3. 首次調(diào)用慢問(wèn)題的定位3.1 確認(rèn)慢在哪一個(gè)環(huán)節(jié)如果你遇到首次調(diào)用慢第一步不是改配置而是要確認(rèn)慢在哪個(gè)環(huán)節(jié)。我用一個(gè)比較笨但很有效的方法來(lái)分段計(jì)時(shí)。在服務(wù)調(diào)用入口和出口分別打點(diǎn)記錄下時(shí)間戳然后看差值。偽代碼如下public Result doBiz(Req req) { long start System.currentTimeMillis(); log.info([TIMELINE] 入口收到請(qǐng)求{}, start); // 發(fā)起 Feign/RestTemplate 調(diào)用前 Result result remoteService.call(req); long end System.currentTimeMillis(); log.info([TIMELINE] 得到響應(yīng){}耗時(shí){}ms, end, end - start); return result; }同時(shí)在 Nacos Client 的日志里觀察關(guān)鍵節(jié)點(diǎn)。Nacos 客戶(hù)端默認(rèn)日志路徑是logs/nacos/核心日志文件是nacos-client.log。啟動(dòng)服務(wù)后觀察日志中以下幾個(gè)關(guān)鍵記錄的出現(xiàn)時(shí)間客戶(hù)端啟動(dòng)開(kāi)始連接 Nacos ServergRPC 連接建立成功訂閱服務(wù)列表成功第一次獲取到服務(wù)實(shí)例列表如果這幾個(gè)節(jié)點(diǎn)之間的間隔異常比如連接建立后到訂閱成功花了 3 秒那問(wèn)題就出在客戶(hù)端與 Nacos Server 的交互上。3.2 常見(jiàn)的三種慢路徑根據(jù)我的實(shí)際排查經(jīng)驗(yàn)Nacos 場(chǎng)景下首次調(diào)用慢可以歸類(lèi)為三種路徑第一種服務(wù)發(fā)現(xiàn)路徑慢。Consumer 發(fā)起調(diào)用時(shí)需要從本地緩存的服務(wù)列表中獲取 Provider 實(shí)例信息。如果服務(wù)列表還沒(méi)有成功拉取或者列表中的實(shí)例狀態(tài)還沒(méi)刷新就會(huì)等待或者重試。第二種配置拉取路徑慢。如果用了 Nacos 配置中心服務(wù)啟動(dòng)時(shí)會(huì)先拉取配置再啟動(dòng) Spring 容器。配置拉取的超時(shí)時(shí)間如果設(shè)置得過(guò)短在弱網(wǎng)或高延遲環(huán)境下就容易超時(shí)失敗。有些配置中心客戶(hù)端框架會(huì)在拉不到配置時(shí)直接啟動(dòng)失敗而 Spring Cloud Alibaba 的實(shí)現(xiàn)里對(duì)某些配置是允許先用舊配置啟動(dòng)的這個(gè)取舍就會(huì)影響首次調(diào)用的時(shí)機(jī)。第三種客戶(hù)端線(xiàn)程池初始化慢。Nacos Client 內(nèi)部有獨(dú)立的線(xiàn)程池用于負(fù)載均衡、健康檢查、服務(wù)列表更新。服務(wù)剛啟動(dòng)時(shí)這些線(xiàn)程池才剛創(chuàng)建如果 JVM 的類(lèi)加載還沒(méi)有完成預(yù)熱第一次調(diào)用就會(huì)觸發(fā)一堆類(lèi)的加載和初始化導(dǎo)致首次調(diào)用慢。3.3 用一個(gè)實(shí)例場(chǎng)景還原全過(guò)程為了把這個(gè)問(wèn)題講透徹我模擬一個(gè)真實(shí)的場(chǎng)景一個(gè)訂單服務(wù)order-service調(diào)用用戶(hù)服務(wù)user-service的 Feign 接口首次調(diào)用耗時(shí) 2.3 秒之后每次調(diào)用耗時(shí)穩(wěn)定在 50ms 以下。我在 order-service 的啟動(dòng)日志里發(fā)現(xiàn)了這樣幾條記錄2025-06-01 10:00:01.001 [main] INFO c.a.c.n.registry.NacosServiceRegistry - nacos registry, SERVICE_NAME: order-service 2025-06-01 10:00:01.105 [main] INFO c.a.c.n.registry.NacosServiceRegistry - nacos registry, register finished 2025-06-01 10:00:02.300 [main] INFO c.a.c.n.config.NacosPropertySourceLocator - get data from Nacos success, dataId: order-service.yaml注意時(shí)間線(xiàn)注冊(cè)中心注冊(cè) 1 秒內(nèi)完成但是配置拉取花了 1.2 秒才完成。也就是說(shuō)Spring 容器在配置還沒(méi)拉取完之前就已經(jīng)對(duì)外提供服務(wù)了實(shí)際上 Spring Cloud Alibaba 的啟動(dòng)流程中配置拉取發(fā)生在 Spring 容器刷新之前配置沒(méi)拉取完正常來(lái)說(shuō)服務(wù)不應(yīng)該對(duì)外暴露。那為什么首次調(diào)用會(huì)慢實(shí)際情況是服務(wù)注冊(cè)完成并不代表服務(wù)已經(jīng)可以被穩(wěn)定調(diào)用。在 Spring Cloud Alibaba 的實(shí)現(xiàn)中服務(wù)注冊(cè)動(dòng)作發(fā)生在 Spring 容器的WebServerInitializedEvent事件之后也就是 Tomcat 已經(jīng)監(jiān)聽(tīng)了端口、但某些后置處理器還沒(méi)跑完的階段。這個(gè)窗口期非常短但恰好第一筆請(qǐng)求打進(jìn)來(lái)時(shí)可能撞上 Feign 客戶(hù)端的第一次初始化這個(gè)初始化過(guò)程涉及生成動(dòng)態(tài)代理類(lèi)、加載負(fù)載均衡策略、初始化連接池一整套下來(lái)幾百毫秒是常事。所以首次調(diào)用慢的本質(zhì)往往是調(diào)用方Consumer側(cè)在第一次調(diào)用時(shí)才懶加載地去初始化 Feign/RestTemplate 的底層組件疊加 Nacos 客戶(hù)端剛拿到服務(wù)列表、還沒(méi)完成負(fù)載均衡器的預(yù)熱兩個(gè)慢啟動(dòng)堆疊在同一個(gè)請(qǐng)求上從外部感知就是首次調(diào)用特別慢。3.4 定位工具與日志分析技巧定位這種問(wèn)題你不能只靠猜要用工具把調(diào)用鏈拉出來(lái)看。我常用的方式是開(kāi)啟 Feign 的日志輸出logging.level.項(xiàng)目包名DEBUG觀察首次調(diào)用的日志時(shí)間點(diǎn)。用 Arthas 在線(xiàn)診斷執(zhí)行trace com.example.feign.UserClient getInfo命令能看到方法內(nèi)部各子步驟的耗時(shí)分布。開(kāi)啟 Nacos Client 的調(diào)試日志觀察注冊(cè)中心拉取列表的時(shí)間點(diǎn)。檢查 JVM 的類(lèi)加載日志-verbose:class確認(rèn)延遲是否來(lái)自懶加載。有一次我用 Arthas 追蹤一個(gè)調(diào)用鏈發(fā)現(xiàn)耗時(shí)的大頭不在 Feign 發(fā)請(qǐng)求而是在負(fù)載均衡選擇服務(wù)實(shí)例的時(shí)候。chooseServer方法耗時(shí) 800ms而實(shí)際 HTTP 調(diào)用只耗時(shí) 30ms。這就是典型的服務(wù)列表未就緒、負(fù)載均衡器在等待或重試的場(chǎng)景。提示Arthas 的 trace 命令定位微服務(wù)調(diào)用鏈路延遲非常有效建議每個(gè)排查這類(lèi)問(wèn)題的同學(xué)都掌握基本用法。它不需要改代碼生產(chǎn)環(huán)境也能應(yīng)急使用。4. 解決首次調(diào)用慢的配置實(shí)操4.1 服務(wù)端的關(guān)鍵配置解決這個(gè)問(wèn)題服務(wù)端能做的配置其實(shí)不多但有兩項(xiàng)值得重視。第一項(xiàng)是 Nacos Server 的 JVM 參數(shù)。如果 Nacos Server 自身 GC 頻繁、堆內(nèi)存不夠客戶(hù)端請(qǐng)求就會(huì)排隊(duì)間接導(dǎo)致首次調(diào)用慢。Nacos 默認(rèn)的 JVM 參數(shù)偏保守在bin/startup.sh中可以調(diào)整堆內(nèi)存JAVA_OPT${JAVA_OPT} -Xms1g -Xmx1g -Xmn512m如果服務(wù)規(guī)模不大幾臺(tái)到幾十臺(tái)實(shí)例1G 堆內(nèi)存足夠。第二項(xiàng)是開(kāi)啟 Nacos Server 的 prometheus 指標(biāo)暴露默認(rèn)已開(kāi)啟配合監(jiān)控大盤(pán)觀察服務(wù)端是否存在連接數(shù)飆高、請(qǐng)求超時(shí)的情況。如果服務(wù)端 CPU 打滿(mǎn)或者頻繁 Full GC那就是另一套調(diào)優(yōu)方案了。但說(shuō)實(shí)話(huà)服務(wù)端配置對(duì)首次調(diào)用慢的影響遠(yuǎn)不如客戶(hù)端配置直接。大多數(shù)情況下問(wèn)題出在客戶(hù)端下面重點(diǎn)講客戶(hù)端配置。4.2 客戶(hù)端配置項(xiàng)逐一調(diào)優(yōu)客戶(hù)端配置是解決首次調(diào)用慢的主戰(zhàn)場(chǎng)。Spring Cloud Alibaba 的 Nacos 客戶(hù)端適配中有幾個(gè)配置項(xiàng)直接影響首次調(diào)用的體驗(yàn)。4.2.1 關(guān)閉服務(wù)端的懶加載Nacos Discovery 客戶(hù)端默認(rèn)有一個(gè)開(kāi)關(guān)控制是否需要等待服務(wù)列表就緒后才對(duì)外提供服務(wù)。這個(gè)開(kāi)關(guān)在 Spring Cloud Alibaba 中通過(guò)spring.cloud.discovery.client.health-indicator間接控制。如果你沒(méi)有配置任何健康檢查、也沒(méi)有設(shè)置服務(wù)列表就緒等待那在極端情況下服務(wù)已經(jīng)暴露端口了但服務(wù)列表還是空的。更具體的配置是 Nacos Client 自身提供了幾個(gè)參數(shù)spring: cloud: nacos: discovery: # 注冊(cè)完成之前不進(jìn)行服務(wù)發(fā)現(xiàn) fail-fast: true # 客戶(hù)端開(kāi)啟服務(wù)列表緩存 cache-enabled: truefail-fast這個(gè)參數(shù)的作用是如果客戶(hù)端啟動(dòng)時(shí)無(wú)法連接 Nacos Server直接快速失敗而不是無(wú)限重試。這個(gè)參數(shù)對(duì)首次調(diào)用慢的影響是間接的——如果 Nacos Server 短時(shí)不可達(dá)不設(shè)置 fail-fast 的話(huà)客戶(hù)端會(huì)卡在注冊(cè)或拉取配置步驟很久表面上看起來(lái)就是服務(wù)啟動(dòng)后首次調(diào)用非常慢。4.2.2 關(guān)鍵設(shè)置合理的負(fù)載均衡預(yù)熱這是最重要的一項(xiàng)配置。Spring Cloud LoadBalancer 默認(rèn)在首次調(diào)用時(shí)才去查詢(xún)服務(wù)實(shí)例列表并建立負(fù)載均衡策略。可以通過(guò)開(kāi)啟饑餓加載eager-load來(lái)提前初始化spring: cloud: loadbalancer: eager-load: enabled: true clients: user-service, order-service, stock-service開(kāi)啟后應(yīng)用啟動(dòng)時(shí)就會(huì)提前初始化指定服務(wù)的負(fù)載均衡器避免第一次調(diào)用時(shí)才去加載。Spring Cloud LoadBalancer 的實(shí)現(xiàn)邏輯是BlockingLoadBalancerClient或ReactiveLoadBalancerClient在調(diào)用choose方法時(shí)會(huì)調(diào)用ServiceInstanceListSupplier獲取實(shí)例列表。默認(rèn)情況下這個(gè) supplier 是懶加載的也就是調(diào)用時(shí)才去 Nacos 拉取列表。而開(kāi)啟 eager-load 后會(huì)在應(yīng)用啟動(dòng)時(shí)主動(dòng)調(diào)用一次把列表緩存到本地后續(xù)調(diào)用直接從緩存取。我實(shí)測(cè)下來(lái)開(kāi)啟 eager-load 后首次調(diào)用的耗時(shí)可以從 1.3 秒降到 150ms 左右基本接近正常水平。注意clients要配置為需要預(yù)熱的服務(wù)名多個(gè)服務(wù)用逗號(hào)分隔。這里不能偷懶地寫(xiě)*或者all沒(méi)有這樣的通配符必須顯式列出。4.2.3 調(diào)整 Nacos 客戶(hù)端的服務(wù)列表獲取行為Nacos Client 在服務(wù)發(fā)現(xiàn)時(shí)默認(rèn)是先從本地緩存讀取服務(wù)列表再異步去服務(wù)端更新列表還是每次實(shí)時(shí)調(diào)服務(wù)端接口這個(gè)行為由 Nacos Client 的內(nèi)部機(jī)制決定在客戶(hù)端配置文件nacos.properties中有一個(gè)namingLoadCacheAtStart配置namingLoadCacheAtStarttrue默認(rèn)情況下這個(gè)值可能是 false意味著客戶(hù)端啟動(dòng)時(shí)不會(huì)主動(dòng)加載本地緩存文件中的服務(wù)列表而是等服務(wù)端推送。如果服務(wù)端推送有一點(diǎn)點(diǎn)延遲就會(huì)產(chǎn)生空窗期。把這個(gè)參數(shù)設(shè)為 true可以讓客戶(hù)端在啟動(dòng)時(shí)先加載本地磁盤(pán)緩存的服務(wù)列表再等待服務(wù)端更新。這個(gè)配置在實(shí)際配置中往往被忽略因?yàn)楹苌儆形恼绿岬剿?。但它在處理服?wù)重啟后快速恢復(fù)調(diào)用的場(chǎng)景里非常有效。4.2.4 配置超時(shí)與重試參數(shù)如果你是使用 OpenFeign 作為服務(wù)調(diào)用框架Feign 自身的超時(shí)和重試配置也需要一并調(diào)整避免首次調(diào)用超時(shí)時(shí)間太短導(dǎo)致失敗feign: client: config: default: connectTimeout: 5000 readTimeout: 10000 compression: request: enabled: true mime-types: text/xml,application/json,application/xml min-request-size: 2048 response: enabled: true連接超時(shí)設(shè)為 5 秒讀超時(shí)設(shè)為 10 秒這是一個(gè)比較穩(wěn)妥的起點(diǎn)。如果你把連接超時(shí)設(shè)成 200ms而首次調(diào)用恰好撞上初始化慢那就直接超時(shí)失敗了表現(xiàn)比慢更糟。4.2.5 線(xiàn)程池預(yù)熱如果你用的是 RestTemplate 或者 OkHttp 這種帶連接池的客戶(hù)端線(xiàn)程池的預(yù)熱其實(shí)就是提前發(fā)一個(gè)探測(cè)請(qǐng)求。這種手段比較 hack但確實(shí)有效。在應(yīng)用啟動(dòng)完成后主動(dòng)調(diào)用一個(gè)內(nèi)部接口讓 Feign/RestTemplate 完成類(lèi)加載和連接建立Component public class FeignPreheatRunner implements ApplicationRunner { private final UserClient userClient; public FeignPreheatRunner(UserClient userClient) { this.userClient userClient; } Override public void run(ApplicationArguments args) { // 提前觸發(fā)一次調(diào)用用于初始化代理類(lèi)和連接池 try { userClient.getInfo(preheat); } catch (Exception ignore) { // 預(yù)熱失敗不影響正常啟動(dòng) } } }這種方式的原理很好理解操作系統(tǒng)和 JVM 層面類(lèi)加載、動(dòng)態(tài)代理生成、TCP 連接建立都是需要時(shí)間的。第一次調(diào)用這些資源都沒(méi)準(zhǔn)備好所以要慢預(yù)熱之后這些資源都在了后續(xù)調(diào)用自然快。4.3 Docker 環(huán)境下的特別注意事項(xiàng)如果你用的是 Docker 部署的 Nacos Server還需要額外注意容器網(wǎng)絡(luò)對(duì)首次調(diào)用的影響。一個(gè)常見(jiàn)的場(chǎng)景Nacos Server 跑在 Docker 里客戶(hù)端跑在宿主機(jī)上?？蛻?hù)端配置的server-addr127.0.0.1:8848初次連接時(shí)如果 Nacos Server 返回給客戶(hù)端的服務(wù)實(shí)例 IP 是容器網(wǎng)段地址而客戶(hù)端無(wú)法訪(fǎng)問(wèn)這個(gè)網(wǎng)段就會(huì)導(dǎo)致連接失敗。首次調(diào)用時(shí)客戶(hù)端需要重新建立連接而連接失敗的重試時(shí)間往往比較長(zhǎng)。另一個(gè)場(chǎng)景客戶(hù)端跑在 Docker 容器里Nacos Server 在宿主機(jī)上。客戶(hù)端里的127.0.0.1指向的是容器自身而不是宿主機(jī)的 Nacos Server。這個(gè)可以說(shuō)是新手最容易踩的坑。解決方法是配置為宿主機(jī)的局域網(wǎng) IP或者使用 Docker 的host_network模式。Docker 環(huán)境下還經(jīng)常遇到 DNS 解析慢的問(wèn)題。如果 Nacos 用了域名而不是 IP容器內(nèi) DNS 解析延遲會(huì)直接疊加到首次調(diào)用耗時(shí)上。解決方法是讓 Nacos 服務(wù)端注冊(cè)為 IP 地址而不是主機(jī)名客戶(hù)端也盡量用 IP。4.4 完整配置參考可直接復(fù)制把上面所有客戶(hù)端配置匯總成一個(gè)相對(duì)完整的版本spring: application: name: order-service cloud: nacos: discovery: server-addr: nacos.example.com:8848 namespace: public group: DEFAULT_GROUP register-enabled: true fail-fast: true cache-enabled: true config: server-addr: nacos.example.com:8848 file-extension: yaml namespace: public group: DEFAULT_GROUP refresh-enabled: true loadbalancer: eager-load: enabled: true clients: user-service, stock-service啟動(dòng)應(yīng)用時(shí)額外加上 JVM 參數(shù)java -jar order-service.jar \ -Dnacos.naming.cache.dir/opt/nacos/cache \ -Dnacos.logging.default.config.enabledfalse-Dnacos.naming.cache.dir指定服務(wù)列表本地緩存目錄方便排查時(shí)直接查看緩存內(nèi)容。5. Nacos 健康檢查機(jī)制與配置補(bǔ)充5.1 健康檢查的基礎(chǔ)概念Nacos 的健康檢查分為兩個(gè)層面服務(wù)端視角的健康檢查和客戶(hù)端視角的健康檢查。服務(wù)端視角Nacos 會(huì)定期檢查臨時(shí)實(shí)例的存活狀態(tài)。臨時(shí)實(shí)例ephemeraltrue通過(guò)客戶(hù)端心跳續(xù)約默認(rèn)心跳間隔 5 秒超時(shí)時(shí)間 15 秒持久化實(shí)例ephemeralfalse由服務(wù)端主動(dòng)探測(cè)探測(cè)路徑為/actuator/health。客戶(hù)端視角Spring Cloud Alibaba 的健康檢查器會(huì)定期檢查服務(wù)列表是否就緒如果服務(wù)列表為空會(huì)把該服務(wù)標(biāo)記為不健康。這就是spring.cloud.discovery.client.health-indicator.enabledtrue配置的作用。完整的健康檢查配置如下management: endpoints: web: exposure: include: health,info,metrics health: nacos: enabled: true5.2 健康檢查與首次調(diào)用的關(guān)聯(lián)健康檢查和首次調(diào)用慢有什么關(guān)系關(guān)系大得很。如果上游服務(wù)有一個(gè)定期健康檢查器它每 30 秒檢查一次下游服務(wù)列表那么服務(wù)剛啟動(dòng)時(shí)如果健康檢查失敗因?yàn)榉?wù)列表還沒(méi)就緒這個(gè)失敗狀態(tài)會(huì)被標(biāo)記在注冊(cè)中心。此時(shí)如果其他服務(wù)嘗試調(diào)用這個(gè)剛啟動(dòng)的服務(wù)會(huì)發(fā)現(xiàn)它是不健康的于是拒絕調(diào)用或者走重試邏輯導(dǎo)致首次調(diào)用慢。這種問(wèn)題的解法是調(diào)整健康檢查器的狀態(tài)讓服務(wù)在啟動(dòng)初期不被標(biāo)記為不健康或者把健康檢查器的啟動(dòng)延遲調(diào)大spring: cloud: discovery: client: health-indicator: enabled: trueNacos Client 內(nèi)部有一個(gè)NacosWatch組件它每隔一段時(shí)間拉取服務(wù)列表并檢查所有健康狀態(tài)。如果你發(fā)現(xiàn)服務(wù)啟動(dòng)后需要等 30 秒左右才能被正常調(diào)用八九不離十跟這個(gè)NacosWatch的默認(rèn)重試間隔有關(guān)系。5.3 配置適度原則避免過(guò)度優(yōu)化這里必須潑一盆冷水Nacos 的配置不是越多越好也不是所有優(yōu)化手段都該一起上。我見(jiàn)過(guò)有人把健康檢查的間隔從 30 秒調(diào)到 1 秒把心跳間隔從 5 秒調(diào)到 1 秒把所有超時(shí)時(shí)間都調(diào)成 10 秒以上結(jié)果 Nacos Server 負(fù)載暴增服務(wù)端 GC 頻繁整體性能反而更差。你要清楚每個(gè)配置項(xiàng)背后的代價(jià)心跳間隔越短N(yùn)acos Server 收到的請(qǐng)求越多服務(wù)端壓力越大。健康檢查越頻繁客戶(hù)端和服務(wù)端的網(wǎng)絡(luò)開(kāi)銷(xiāo)越高。負(fù)載均衡預(yù)熱服務(wù)越多應(yīng)用啟動(dòng)時(shí)間越長(zhǎng)。所以我的建議是如果服務(wù)規(guī)模不大優(yōu)先做負(fù)載均衡預(yù)熱 Nacos 客戶(hù)端參數(shù)微調(diào)這兩個(gè)動(dòng)作其他配置按需追加。先解決主要矛盾再處理次要矛盾。6. 常見(jiàn)問(wèn)題與排查技巧6.1 問(wèn)題速查表問(wèn)題現(xiàn)象可能原因解決方案首次調(diào)用慢后續(xù)正常負(fù)載均衡懶加載開(kāi)啟 eager-load預(yù)熱指定服務(wù)服務(wù)啟動(dòng)后一段時(shí)間內(nèi)無(wú)法被調(diào)用NacosWatch 未就緒檢查spring.cloud.discovery.client.health-indicator.enabled結(jié)合健康檢查線(xiàn)程池調(diào)優(yōu)注冊(cè)成功但調(diào)用超時(shí)gRPC 端口 9848 不通檢查防火墻和 Docker 端口映射配置中心拉取慢網(wǎng)絡(luò)延遲或超時(shí)設(shè)置不合理調(diào)整spring.cloud.nacos.config.timeout首次調(diào)用時(shí)連接被拒絕客戶(hù)端初始化連接池過(guò)慢通過(guò) Feign/RestTemplate 預(yù)熱或調(diào)整連接池參數(shù)服務(wù)重啟后第一次調(diào)用極慢本地緩存未加載設(shè)置namingLoadCacheAtStarttrue6.2 排查技巧與工具清單實(shí)際排障過(guò)程中我總結(jié)了一套固定動(dòng)作分享出來(lái)供參考第一步看 Nacos 客戶(hù)端日志。Nacos 日志記錄了注冊(cè)、訂閱、心跳全過(guò)程的詳細(xì)時(shí)間線(xiàn)是定位問(wèn)題最直接的信息源。用grep過(guò)濾關(guān)鍵字即可grep -E register|subscribe|heartbeat|service list|get service logs/nacos/nacos-client.log | head -50第二步抓線(xiàn)程狀態(tài)。如果首次調(diào)用卡住用jstack看看卡在哪個(gè)線(xiàn)程。如果線(xiàn)程停留在SocketRead或者WAITING狀態(tài)十有八九是在等 Nacos 的響應(yīng)。第三步用 Arthas 做方法級(jí)追蹤。剛才提到的trace命令可以直接看到NacosServiceManager或LoadBalancer的內(nèi)部調(diào)用耗時(shí)分布不用改代碼就能定位熱點(diǎn)。第四步檢查網(wǎng)絡(luò)鏈路。用telnet或nc驗(yàn)證 8848 和 9848 端口是否連通。這一步最簡(jiǎn)單但能排除一半以上的問(wèn)題。6.3 采坑經(jīng)驗(yàn)匯總我在處理 Nacos 問(wèn)題的過(guò)程中攢下了一些很有意思的踩坑經(jīng)驗(yàn)挑幾個(gè)典型的分享第一版本混用的問(wèn)題。某個(gè)項(xiàng)目里注冊(cè)中心用的是 Nacos Server 1.4.2但客戶(hù)端依賴(lài)被 Spring Cloud Alibaba 自動(dòng)升級(jí)到了 2.x。2.x 的客戶(hù)端會(huì)嘗試通過(guò) gRPC 連接服務(wù)端而 1.4.2 的 Server 不支持 gRPC于是客戶(hù)端在兼容模式下退回到 1.x 的 HTTP 連接。這個(gè)回退過(guò)程在日志里幾乎看不到不對(duì)日志里會(huì)有一條明顯的連接異常記錄但很多人沒(méi)細(xì)看就導(dǎo)致每次首次調(diào)用都慢。排查這個(gè)問(wèn)題時(shí)第一件事就是確認(rèn)服務(wù)端和客戶(hù)端的大版本是否一致。第二多網(wǎng)卡問(wèn)題。服務(wù)器上有多塊網(wǎng)卡Nacos 客戶(hù)端注冊(cè)時(shí)選錯(cuò)了網(wǎng)卡 IP注冊(cè)的地址不可達(dá)。服務(wù)調(diào)用方拿到這個(gè)不可達(dá)的地址第一次連接就會(huì)超時(shí)。解決方法是顯式指定客戶(hù)端的 IPspring: cloud: nacos: discovery: ip: 192.168.1.100第三Spring Cloud 上下文刷新導(dǎo)致配置丟失。項(xiàng)目里用了RefreshScope在配置變更后觸發(fā)刷新但刷新過(guò)程中 Feign 客戶(hù)端被重建了重建后的客戶(hù)端是冷啟動(dòng)的就會(huì)出現(xiàn)非首次調(diào)用也慢的假象。這個(gè)坑很容易誤判為 Nacos 的問(wèn)題其實(shí)只是上下文刷新導(dǎo)致的懶加載重來(lái)。6.4 快速驗(yàn)證優(yōu)化效果的方法每次調(diào)整完配置都建議做一個(gè)標(biāo)準(zhǔn)化的驗(yàn)證不然你無(wú)法判斷這次優(yōu)化到底有沒(méi)有效果。我的驗(yàn)證流程是重啟服務(wù)清理所有本地緩存文件。記錄服務(wù)啟動(dòng)完成的時(shí)間點(diǎn)。立即發(fā)起第一次調(diào)用記錄耗時(shí)。連續(xù)調(diào)用 10 次記錄平均耗時(shí)。對(duì)比優(yōu)化前后的數(shù)據(jù)。如果首次調(diào)用耗時(shí)下降超過(guò) 50%說(shuō)明優(yōu)化生效了如果變化不明顯那就需要回到日志分析環(huán)節(jié)看看耗時(shí)到底消耗在哪一步。7. 實(shí)際操作中的一點(diǎn)體會(huì)最后聊點(diǎn)實(shí)際的。Nacos 首次調(diào)用慢這個(gè)問(wèn)題網(wǎng)上能搜到大量資料但每個(gè)團(tuán)隊(duì)的環(huán)境都不一樣直接抄別人的配置不一定好用。我個(gè)人在實(shí)戰(zhàn)中最大的體會(huì)是不要一上來(lái)就改配置先花十分鐘看日志把慢的環(huán)節(jié)確認(rèn)清楚。大多數(shù)情況下問(wèn)題定位準(zhǔn)確之后真正需要改的配置往往只有一兩個(gè)。我自己的習(xí)慣是加入 Nacos 的項(xiàng)目會(huì)提前把nacos-client.log的日志級(jí)別調(diào)到 DEBUG 并歸檔保留這樣出問(wèn)題的時(shí)候有據(jù)可查。同時(shí)會(huì)在項(xiàng)目里放一個(gè)啟動(dòng)自檢的接口專(zhuān)門(mén)用來(lái)觸發(fā) Feign 客戶(hù)端的預(yù)熱和一個(gè)無(wú)業(yè)務(wù)邏輯的服務(wù)發(fā)現(xiàn)查詢(xún)這樣既能順帶做健康檢查又能把首次調(diào)用慢的風(fēng)險(xiǎn)轉(zhuǎn)移到啟動(dòng)流程內(nèi)部而不是暴露給真實(shí)的業(yè)務(wù)請(qǐng)求。還有一個(gè)小技巧如果你在壓測(cè)或者聯(lián)調(diào)環(huán)境下需要頻繁重啟服務(wù)可以考慮在啟動(dòng)參數(shù)中加-Dnacos.naming.cache.dir指定一個(gè)持久化的緩存目錄這樣服務(wù)重啟后還能復(fù)用上一次的本地緩存減少服務(wù)列表拉取的等待時(shí)間。這個(gè)方向還可以延伸一步Nacos 集群模式下多個(gè)節(jié)點(diǎn)之間的數(shù)據(jù)一致性、Client 端從哪個(gè)節(jié)點(diǎn)拉取最新列表的調(diào)度策略都會(huì)影響服務(wù)的發(fā)現(xiàn)延遲。如果你們團(tuán)隊(duì)的 Nacos 規(guī)模比較大建議后面在做容量規(guī)劃時(shí)把客戶(hù)端的注冊(cè)、心跳、訂閱請(qǐng)求量納入評(píng)估而不是只盯著服務(wù)端 CPU 和內(nèi)存用。先把客戶(hù)端這側(cè)的基礎(chǔ)打牢服務(wù)端才能真的省心。 Nacos首次調(diào)用慢排查與配置調(diào)優(yōu)實(shí)戰(zhàn)指南
1. 項(xiàng)目概述與問(wèn)題背景1.1 核心需求解析我不知道你有沒(méi)有踩過(guò)這樣一個(gè)坑服務(wù)用 Spring Cloud Alibaba Nacos 做了服務(wù)注冊(cè)與發(fā)現(xiàn)平時(shí)用起來(lái)一切正常但每次服務(wù)剛啟動(dòng)完第一次去調(diào)用別的服務(wù)接口總感覺(jué)像卡住了一樣慢得離譜。等這第一次調(diào)用過(guò)去了后面的請(qǐng)求又一馬平川快得很。這個(gè)首次調(diào)用慢的問(wèn)題在微服務(wù)架構(gòu)里屬于那種不痛不癢、但真遇到又很折磨人的隱性 Bug。說(shuō)它不痛不癢是因?yàn)樗挥绊懽罱K結(jié)果——請(qǐng)求最終還是成功了只是慢了那么幾百毫秒甚至幾秒說(shuō)它折磨人是因?yàn)樗h(huán)境、版本、部署方式強(qiáng)行掛鉤同一個(gè)版本在這里沒(méi)事?lián)Q個(gè)環(huán)境就現(xiàn)原形排查起來(lái)非常折騰。這篇文章不是講解 Nacos 基礎(chǔ)概念的入門(mén)文而是要落地解決首次調(diào)用慢這一具體問(wèn)題的排障實(shí)錄。我會(huì)從 Nacos 的配置操作講起覆蓋原生部署和 Docker 部署兩種情況然后帶你一步步定位首次調(diào)用慢的根源并給出可以直接抄作業(yè)的配置方案。先說(shuō)結(jié)論Nacos 首次調(diào)用慢這個(gè)問(wèn)題絕大多數(shù)情況下不是 Nacos 服務(wù)端的問(wèn)題而是客戶(hù)端在啟動(dòng)初期與配置中心、注冊(cè)中心交互過(guò)程中一堆細(xì)節(jié)配置沒(méi)有調(diào)優(yōu)導(dǎo)致的。Nacos 本身只是一個(gè)分布式基礎(chǔ)設(shè)施它把服務(wù)注冊(cè)、發(fā)現(xiàn)、配置管理的活干完了但客戶(hù)端怎么配合它干活這個(gè)配合的細(xì)節(jié)直接決定了首次調(diào)用的體驗(yàn)。1.2 影響范圍與排查思路這個(gè)問(wèn)題的典型出現(xiàn)場(chǎng)景包括服務(wù)剛啟動(dòng)第一筆外部請(qǐng)求進(jìn)來(lái)到真正發(fā)出下游調(diào)用之間延遲明顯。多實(shí)例部署環(huán)境中部分實(shí)例首次調(diào)用慢部分實(shí)例正常。測(cè)試環(huán)境一切正常生產(chǎn)環(huán)境首次調(diào)用偶發(fā)超時(shí)。服務(wù)重啟后短時(shí)間內(nèi)大量請(qǐng)求涌入出現(xiàn)集中的慢調(diào)用或超時(shí)。如果你遇到了上述任意一種又不想每次重啟服務(wù)都提心吊膽這篇文章一定要往下看。排查思路的核心在于先確認(rèn)慢在哪一段再確認(rèn)導(dǎo)致慢的機(jī)制。Nacos 場(chǎng)景下慢的環(huán)節(jié)通常集中在服務(wù)發(fā)現(xiàn)、配置拉取、客戶(hù)端線(xiàn)程初始化三個(gè)環(huán)節(jié)。定位到具體環(huán)節(jié)之后配置調(diào)整才有針對(duì)性。下面我按自己的實(shí)戰(zhàn)經(jīng)過(guò)把整個(gè)配置過(guò)程和采坑點(diǎn)完整過(guò)一遍。2. Nacos 配置操作全流程2.1 配置之前先搞懂 Nacos 的兩個(gè)核心角色在動(dòng)手配置之前必須先分清你用的是 Nacos 的哪個(gè)能力。Nacos 本質(zhì)上是一個(gè)注冊(cè)中心 配置中心的二合一組件而這兩個(gè)角色對(duì)客戶(hù)端的影響路徑完全不同。注冊(cè)中心負(fù)責(zé)服務(wù)實(shí)例的管理。服務(wù)啟動(dòng)時(shí)客戶(hù)端把自身 IP、端口、健康狀態(tài)注冊(cè)到 Nacos 服務(wù)端服務(wù)調(diào)用方Consumer通過(guò) Nacos 獲取目標(biāo)服務(wù)的實(shí)例列表再根據(jù)負(fù)載均衡策略選擇實(shí)例發(fā)起調(diào)用。這一條鏈路如果出了問(wèn)題直接表現(xiàn)就是找不到服務(wù)或者拿到的是過(guò)期的實(shí)例列表。配置中心負(fù)責(zé)配置項(xiàng)的動(dòng)態(tài)管理。服務(wù)啟動(dòng)時(shí)客戶(hù)端向 Nacos 拉取配置運(yùn)行期間客戶(hù)端通過(guò)長(zhǎng)輪詢(xún)監(jiān)聽(tīng)配置變化。這一條鏈路如果出了問(wèn)題直接表現(xiàn)是配置沒(méi)生效或者啟動(dòng)時(shí)卡在拉配置環(huán)節(jié)。首次調(diào)用慢恰恰就集中在這兩條鏈路交匯的地方。服務(wù)啟動(dòng)后本地 Spring 容器的初始化工作可能早就完成了但 Nacos 客戶(hù)端的某些異步動(dòng)作還在進(jìn)行中這時(shí)候第一筆請(qǐng)求打進(jìn)來(lái)就會(huì)撞上客戶(hù)端暫時(shí)還沒(méi)準(zhǔn)備好的尷尬期。2.2 原生部署 Nacos 的基本配置操作先講原生部署。很多團(tuán)隊(duì)在測(cè)試環(huán)境會(huì)直接用解壓包方式啟動(dòng) Nacos Server雖然 Docker 已經(jīng)很普及了但原生部署依然有它不可替代的場(chǎng)景便于直接查看日志、便于調(diào)試、不依賴(lài)鏡像倉(cāng)庫(kù)。啟動(dòng) Nacos Server 前最基礎(chǔ)也最關(guān)鍵的配置在conf/application.properties### 是否開(kāi)啟認(rèn)證 nacos.core.auth.enabledfalse ### 控制臺(tái)登錄用戶(hù)名密碼開(kāi)啟認(rèn)證時(shí)生效 nacos.core.auth.plugin.nacos.token.secret.keySecretKey012345678901234567890123456789012345678901234567890123456789 ### 服務(wù)端口 server.port8848 ### 數(shù)據(jù)源配置默認(rèn)使用內(nèi)嵌 Derby生產(chǎn)建議切換 MySQL spring.datasource.platformmysql db.num1 db.url.0jdbc:mysql://127.0.0.1:3306/nacos_config?characterEncodingutf8connectTimeout1000socketTimeout3000autoReconnecttrueuseUnicodetrueuseSSLfalseserverTimezoneAsia/Shanghai db.user.0nacos db.password.0nacos這里有一個(gè)非常反直覺(jué)的坑很多人以為 Nacos Server 是內(nèi)存組件配置里沒(méi)有數(shù)據(jù)庫(kù)字段也沒(méi)關(guān)系。但 Nacos Server 的配置數(shù)據(jù)、注冊(cè)的持久化實(shí)例信息臨時(shí)實(shí)例除外都依賴(lài)數(shù)據(jù)庫(kù)存儲(chǔ)。默認(rèn)的內(nèi)嵌 Derby 只適合單機(jī)跑著玩一旦服務(wù)重啟Derby 數(shù)據(jù)文件可能損壞導(dǎo)致配置丟失。我自己就遇到過(guò)明明配置在頁(yè)面上能看到重啟之后全部蒸發(fā)的情況就是因?yàn)橛昧?Derby 且沒(méi)有做數(shù)據(jù)備份。所以生產(chǎn)環(huán)境務(wù)必配 MySQL別嫌麻煩。啟動(dòng)時(shí)單機(jī)模式用-m standalone參數(shù)sh startup.sh -m standalone如果是在 Linux 服務(wù)器上啟動(dòng)默認(rèn)是集群模式不指定standalone的話(huà)會(huì)嘗試去連其他節(jié)點(diǎn)然后一直報(bào)連接失敗。這個(gè)坑很常見(jiàn)尤其是在測(cè)試環(huán)境隨便拉起來(lái)一個(gè)服務(wù)用的時(shí)候。2.3 Docker 部署 Nacos 的操作細(xì)節(jié)Docker 部署 Nacos 其實(shí)是更主流的方式尤其是 Kubernetes 環(huán)境里Nacos Server 往往以 StatefulSet 方式部署。對(duì)于單體 Docker 部署最簡(jiǎn)潔的啟動(dòng)命令如下docker run -d \ --name nacos-server \ -p 8848:8848 \ -p 9848:9848 \ -p 9849:9849 \ -e MODEstandalone \ -e SPRING_DATASOURCE_PLATFORMmysql \ -e MYSQL_SERVICE_HOST127.0.0.1 \ -e MYSQL_SERVICE_PORT3306 \ -e MYSQL_SERVICE_DB_NAMEnacos_config \ -e MYSQL_SERVICE_USERnacos \ -e MYSQL_SERVICE_PASSWORDnacos \ nacos/nacos-server:latest注意這里我把 9848 和 9849 端口也映射出來(lái)了。Nacos 從 2.x 版本開(kāi)始客戶(hù)端與服務(wù)端之間的 gRPC 通信走 9848 端口9849 是服務(wù)端之間的 gRPC 通信端口。很多人只映射了 8848 端口結(jié)果注冊(cè)中心頁(yè)面能打開(kāi)服務(wù)也能注冊(cè)上但客戶(hù)端拉取服務(wù)列表時(shí)需要通過(guò) gRPC 建立長(zhǎng)連接端口不通就一直在重試表現(xiàn)出來(lái)就是服務(wù)剛啟動(dòng)時(shí)各種超時(shí)、首次調(diào)用極慢。這是首次調(diào)用慢的一個(gè)非常隱蔽的誘因Docker 容器沒(méi)把 9848 端口暴露出來(lái)。我建議你先自查這一條如果端口映射有缺失后續(xù)的配置優(yōu)化做得再好都白搭。注意Nacos 2.x 版本引入 gRPC 通信機(jī)制之后除了 8848 主端口還必須保證 9848客戶(hù)端 gRPC和 9849服務(wù)端 gRPC的端口可達(dá)。端口不通會(huì)導(dǎo)致客戶(hù)端連接狀態(tài)不穩(wěn)定間接引發(fā)首次調(diào)用慢。2.4 客戶(hù)端依賴(lài)與基礎(chǔ)配置服務(wù)端配置完之后客戶(hù)端側(cè)的 Maven 依賴(lài)也需要對(duì)齊版本。Spring Cloud Alibaba、Spring Cloud、Spring Boot、Nacos Client 四者之間的版本關(guān)系堪稱(chēng)微服務(wù)領(lǐng)域最大的版本深水區(qū)之一。我見(jiàn)過(guò)太多人把 Spring Cloud Alibaba 版本隨便升一升Nacos Client 的版本也跟著變了然后該通的調(diào)不通不該有的 Bug 全冒出來(lái)了。以當(dāng)前比較穩(wěn)定的組合為例組件版本Spring Boot2.6.xSpring Cloud2021.0.xSpring Cloud Alibaba2021.0.5.0Nacos Client由 Spring Cloud Alibaba 管理2.2.xMaven 依賴(lài)坐標(biāo)如下dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-discovery/artifactId /dependency dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-config/artifactId /dependency配置文件application.yml中核心配置項(xiàng)如下spring: application: name: order-service cloud: nacos: discovery: server-addr: 127.0.0.1:8848 namespace: public group: DEFAULT_GROUP register-enabled: true config: server-addr: 127.0.0.1:8848 file-extension: yaml namespace: public group: DEFAULT_GROUP refresh-enabled: true到這里為止基礎(chǔ)配置是能跑通的但離首次調(diào)用不慢還有距離。接下來(lái)進(jìn)入重點(diǎn)也就是首次調(diào)用慢的具體定位和解決。3. 首次調(diào)用慢問(wèn)題的定位3.1 確認(rèn)慢在哪一個(gè)環(huán)節(jié)如果你遇到首次調(diào)用慢第一步不是改配置而是要確認(rèn)慢在哪個(gè)環(huán)節(jié)。我用一個(gè)比較笨但很有效的方法來(lái)分段計(jì)時(shí)。在服務(wù)調(diào)用入口和出口分別打點(diǎn)記錄下時(shí)間戳然后看差值。偽代碼如下public Result doBiz(Req req) { long start System.currentTimeMillis(); log.info([TIMELINE] 入口收到請(qǐng)求{}, start); // 發(fā)起 Feign/RestTemplate 調(diào)用前 Result result remoteService.call(req); long end System.currentTimeMillis(); log.info([TIMELINE] 得到響應(yīng){}耗時(shí){}ms, end, end - start); return result; }同時(shí)在 Nacos Client 的日志里觀察關(guān)鍵節(jié)點(diǎn)。Nacos 客戶(hù)端默認(rèn)日志路徑是logs/nacos/核心日志文件是nacos-client.log。啟動(dòng)服務(wù)后觀察日志中以下幾個(gè)關(guān)鍵記錄的出現(xiàn)時(shí)間客戶(hù)端啟動(dòng)開(kāi)始連接 Nacos ServergRPC 連接建立成功訂閱服務(wù)列表成功第一次獲取到服務(wù)實(shí)例列表如果這幾個(gè)節(jié)點(diǎn)之間的間隔異常比如連接建立后到訂閱成功花了 3 秒那問(wèn)題就出在客戶(hù)端與 Nacos Server 的交互上。3.2 常見(jiàn)的三種慢路徑根據(jù)我的實(shí)際排查經(jīng)驗(yàn)Nacos 場(chǎng)景下首次調(diào)用慢可以歸類(lèi)為三種路徑第一種服務(wù)發(fā)現(xiàn)路徑慢。Consumer 發(fā)起調(diào)用時(shí)需要從本地緩存的服務(wù)列表中獲取 Provider 實(shí)例信息。如果服務(wù)列表還沒(méi)有成功拉取或者列表中的實(shí)例狀態(tài)還沒(méi)刷新就會(huì)等待或者重試。第二種配置拉取路徑慢。如果用了 Nacos 配置中心服務(wù)啟動(dòng)時(shí)會(huì)先拉取配置再啟動(dòng) Spring 容器。配置拉取的超時(shí)時(shí)間如果設(shè)置得過(guò)短在弱網(wǎng)或高延遲環(huán)境下就容易超時(shí)失敗。有些配置中心客戶(hù)端框架會(huì)在拉不到配置時(shí)直接啟動(dòng)失敗而 Spring Cloud Alibaba 的實(shí)現(xiàn)里對(duì)某些配置是允許先用舊配置啟動(dòng)的這個(gè)取舍就會(huì)影響首次調(diào)用的時(shí)機(jī)。第三種客戶(hù)端線(xiàn)程池初始化慢。Nacos Client 內(nèi)部有獨(dú)立的線(xiàn)程池用于負(fù)載均衡、健康檢查、服務(wù)列表更新。服務(wù)剛啟動(dòng)時(shí)這些線(xiàn)程池才剛創(chuàng)建如果 JVM 的類(lèi)加載還沒(méi)有完成預(yù)熱第一次調(diào)用就會(huì)觸發(fā)一堆類(lèi)的加載和初始化導(dǎo)致首次調(diào)用慢。3.3 用一個(gè)實(shí)例場(chǎng)景還原全過(guò)程為了把這個(gè)問(wèn)題講透徹我模擬一個(gè)真實(shí)的場(chǎng)景一個(gè)訂單服務(wù)order-service調(diào)用用戶(hù)服務(wù)user-service的 Feign 接口首次調(diào)用耗時(shí) 2.3 秒之后每次調(diào)用耗時(shí)穩(wěn)定在 50ms 以下。我在 order-service 的啟動(dòng)日志里發(fā)現(xiàn)了這樣幾條記錄2025-06-01 10:00:01.001 [main] INFO c.a.c.n.registry.NacosServiceRegistry - nacos registry, SERVICE_NAME: order-service 2025-06-01 10:00:01.105 [main] INFO c.a.c.n.registry.NacosServiceRegistry - nacos registry, register finished 2025-06-01 10:00:02.300 [main] INFO c.a.c.n.config.NacosPropertySourceLocator - get data from Nacos success, dataId: order-service.yaml注意時(shí)間線(xiàn)注冊(cè)中心注冊(cè) 1 秒內(nèi)完成但是配置拉取花了 1.2 秒才完成。也就是說(shuō)Spring 容器在配置還沒(méi)拉取完之前就已經(jīng)對(duì)外提供服務(wù)了實(shí)際上 Spring Cloud Alibaba 的啟動(dòng)流程中配置拉取發(fā)生在 Spring 容器刷新之前配置沒(méi)拉取完正常來(lái)說(shuō)服務(wù)不應(yīng)該對(duì)外暴露。那為什么首次調(diào)用會(huì)慢實(shí)際情況是服務(wù)注冊(cè)完成并不代表服務(wù)已經(jīng)可以被穩(wěn)定調(diào)用。在 Spring Cloud Alibaba 的實(shí)現(xiàn)中服務(wù)注冊(cè)動(dòng)作發(fā)生在 Spring 容器的WebServerInitializedEvent事件之后也就是 Tomcat 已經(jīng)監(jiān)聽(tīng)了端口、但某些后置處理器還沒(méi)跑完的階段。這個(gè)窗口期非常短但恰好第一筆請(qǐng)求打進(jìn)來(lái)時(shí)可能撞上 Feign 客戶(hù)端的第一次初始化這個(gè)初始化過(guò)程涉及生成動(dòng)態(tài)代理類(lèi)、加載負(fù)載均衡策略、初始化連接池一整套下來(lái)幾百毫秒是常事。所以首次調(diào)用慢的本質(zhì)往往是調(diào)用方Consumer側(cè)在第一次調(diào)用時(shí)才懶加載地去初始化 Feign/RestTemplate 的底層組件疊加 Nacos 客戶(hù)端剛拿到服務(wù)列表、還沒(méi)完成負(fù)載均衡器的預(yù)熱兩個(gè)慢啟動(dòng)堆疊在同一個(gè)請(qǐng)求上從外部感知就是首次調(diào)用特別慢。3.4 定位工具與日志分析技巧定位這種問(wèn)題你不能只靠猜要用工具把調(diào)用鏈拉出來(lái)看。我常用的方式是開(kāi)啟 Feign 的日志輸出logging.level.項(xiàng)目包名DEBUG觀察首次調(diào)用的日志時(shí)間點(diǎn)。用 Arthas 在線(xiàn)診斷執(zhí)行trace com.example.feign.UserClient getInfo命令能看到方法內(nèi)部各子步驟的耗時(shí)分布。開(kāi)啟 Nacos Client 的調(diào)試日志觀察注冊(cè)中心拉取列表的時(shí)間點(diǎn)。檢查 JVM 的類(lèi)加載日志-verbose:class確認(rèn)延遲是否來(lái)自懶加載。有一次我用 Arthas 追蹤一個(gè)調(diào)用鏈發(fā)現(xiàn)耗時(shí)的大頭不在 Feign 發(fā)請(qǐng)求而是在負(fù)載均衡選擇服務(wù)實(shí)例的時(shí)候。chooseServer方法耗時(shí) 800ms而實(shí)際 HTTP 調(diào)用只耗時(shí) 30ms。這就是典型的服務(wù)列表未就緒、負(fù)載均衡器在等待或重試的場(chǎng)景。提示Arthas 的 trace 命令定位微服務(wù)調(diào)用鏈路延遲非常有效建議每個(gè)排查這類(lèi)問(wèn)題的同學(xué)都掌握基本用法。它不需要改代碼生產(chǎn)環(huán)境也能應(yīng)急使用。4. 解決首次調(diào)用慢的配置實(shí)操4.1 服務(wù)端的關(guān)鍵配置解決這個(gè)問(wèn)題服務(wù)端能做的配置其實(shí)不多但有兩項(xiàng)值得重視。第一項(xiàng)是 Nacos Server 的 JVM 參數(shù)。如果 Nacos Server 自身 GC 頻繁、堆內(nèi)存不夠客戶(hù)端請(qǐng)求就會(huì)排隊(duì)間接導(dǎo)致首次調(diào)用慢。Nacos 默認(rèn)的 JVM 參數(shù)偏保守在bin/startup.sh中可以調(diào)整堆內(nèi)存JAVA_OPT${JAVA_OPT} -Xms1g -Xmx1g -Xmn512m如果服務(wù)規(guī)模不大幾臺(tái)到幾十臺(tái)實(shí)例1G 堆內(nèi)存足夠。第二項(xiàng)是開(kāi)啟 Nacos Server 的 prometheus 指標(biāo)暴露默認(rèn)已開(kāi)啟配合監(jiān)控大盤(pán)觀察服務(wù)端是否存在連接數(shù)飆高、請(qǐng)求超時(shí)的情況。如果服務(wù)端 CPU 打滿(mǎn)或者頻繁 Full GC那就是另一套調(diào)優(yōu)方案了。但說(shuō)實(shí)話(huà)服務(wù)端配置對(duì)首次調(diào)用慢的影響遠(yuǎn)不如客戶(hù)端配置直接。大多數(shù)情況下問(wèn)題出在客戶(hù)端下面重點(diǎn)講客戶(hù)端配置。4.2 客戶(hù)端配置項(xiàng)逐一調(diào)優(yōu)客戶(hù)端配置是解決首次調(diào)用慢的主戰(zhàn)場(chǎng)。Spring Cloud Alibaba 的 Nacos 客戶(hù)端適配中有幾個(gè)配置項(xiàng)直接影響首次調(diào)用的體驗(yàn)。4.2.1 關(guān)閉服務(wù)端的懶加載Nacos Discovery 客戶(hù)端默認(rèn)有一個(gè)開(kāi)關(guān)控制是否需要等待服務(wù)列表就緒后才對(duì)外提供服務(wù)。這個(gè)開(kāi)關(guān)在 Spring Cloud Alibaba 中通過(guò)spring.cloud.discovery.client.health-indicator間接控制。如果你沒(méi)有配置任何健康檢查、也沒(méi)有設(shè)置服務(wù)列表就緒等待那在極端情況下服務(wù)已經(jīng)暴露端口了但服務(wù)列表還是空的。更具體的配置是 Nacos Client 自身提供了幾個(gè)參數(shù)spring: cloud: nacos: discovery: # 注冊(cè)完成之前不進(jìn)行服務(wù)發(fā)現(xiàn) fail-fast: true # 客戶(hù)端開(kāi)啟服務(wù)列表緩存 cache-enabled: truefail-fast這個(gè)參數(shù)的作用是如果客戶(hù)端啟動(dòng)時(shí)無(wú)法連接 Nacos Server直接快速失敗而不是無(wú)限重試。這個(gè)參數(shù)對(duì)首次調(diào)用慢的影響是間接的——如果 Nacos Server 短時(shí)不可達(dá)不設(shè)置 fail-fast 的話(huà)客戶(hù)端會(huì)卡在注冊(cè)或拉取配置步驟很久表面上看起來(lái)就是服務(wù)啟動(dòng)后首次調(diào)用非常慢。4.2.2 關(guān)鍵設(shè)置合理的負(fù)載均衡預(yù)熱這是最重要的一項(xiàng)配置。Spring Cloud LoadBalancer 默認(rèn)在首次調(diào)用時(shí)才去查詢(xún)服務(wù)實(shí)例列表并建立負(fù)載均衡策略。可以通過(guò)開(kāi)啟饑餓加載eager-load來(lái)提前初始化spring: cloud: loadbalancer: eager-load: enabled: true clients: user-service, order-service, stock-service開(kāi)啟后應(yīng)用啟動(dòng)時(shí)就會(huì)提前初始化指定服務(wù)的負(fù)載均衡器避免第一次調(diào)用時(shí)才去加載。Spring Cloud LoadBalancer 的實(shí)現(xiàn)邏輯是BlockingLoadBalancerClient或ReactiveLoadBalancerClient在調(diào)用choose方法時(shí)會(huì)調(diào)用ServiceInstanceListSupplier獲取實(shí)例列表。默認(rèn)情況下這個(gè) supplier 是懶加載的也就是調(diào)用時(shí)才去 Nacos 拉取列表。而開(kāi)啟 eager-load 后會(huì)在應(yīng)用啟動(dòng)時(shí)主動(dòng)調(diào)用一次把列表緩存到本地后續(xù)調(diào)用直接從緩存取。我實(shí)測(cè)下來(lái)開(kāi)啟 eager-load 后首次調(diào)用的耗時(shí)可以從 1.3 秒降到 150ms 左右基本接近正常水平。注意clients要配置為需要預(yù)熱的服務(wù)名多個(gè)服務(wù)用逗號(hào)分隔。這里不能偷懶地寫(xiě)*或者all沒(méi)有這樣的通配符必須顯式列出。4.2.3 調(diào)整 Nacos 客戶(hù)端的服務(wù)列表獲取行為Nacos Client 在服務(wù)發(fā)現(xiàn)時(shí)默認(rèn)是先從本地緩存讀取服務(wù)列表再異步去服務(wù)端更新列表還是每次實(shí)時(shí)調(diào)服務(wù)端接口這個(gè)行為由 Nacos Client 的內(nèi)部機(jī)制決定在客戶(hù)端配置文件nacos.properties中有一個(gè)namingLoadCacheAtStart配置namingLoadCacheAtStarttrue默認(rèn)情況下這個(gè)值可能是 false意味著客戶(hù)端啟動(dòng)時(shí)不會(huì)主動(dòng)加載本地緩存文件中的服務(wù)列表而是等服務(wù)端推送。如果服務(wù)端推送有一點(diǎn)點(diǎn)延遲就會(huì)產(chǎn)生空窗期。把這個(gè)參數(shù)設(shè)為 true可以讓客戶(hù)端在啟動(dòng)時(shí)先加載本地磁盤(pán)緩存的服務(wù)列表再等待服務(wù)端更新。這個(gè)配置在實(shí)際配置中往往被忽略因?yàn)楹苌儆形恼绿岬剿?。但它在處理服?wù)重啟后快速恢復(fù)調(diào)用的場(chǎng)景里非常有效。4.2.4 配置超時(shí)與重試參數(shù)如果你是使用 OpenFeign 作為服務(wù)調(diào)用框架Feign 自身的超時(shí)和重試配置也需要一并調(diào)整避免首次調(diào)用超時(shí)時(shí)間太短導(dǎo)致失敗feign: client: config: default: connectTimeout: 5000 readTimeout: 10000 compression: request: enabled: true mime-types: text/xml,application/json,application/xml min-request-size: 2048 response: enabled: true連接超時(shí)設(shè)為 5 秒讀超時(shí)設(shè)為 10 秒這是一個(gè)比較穩(wěn)妥的起點(diǎn)。如果你把連接超時(shí)設(shè)成 200ms而首次調(diào)用恰好撞上初始化慢那就直接超時(shí)失敗了表現(xiàn)比慢更糟。4.2.5 線(xiàn)程池預(yù)熱如果你用的是 RestTemplate 或者 OkHttp 這種帶連接池的客戶(hù)端線(xiàn)程池的預(yù)熱其實(shí)就是提前發(fā)一個(gè)探測(cè)請(qǐng)求。這種手段比較 hack但確實(shí)有效。在應(yīng)用啟動(dòng)完成后主動(dòng)調(diào)用一個(gè)內(nèi)部接口讓 Feign/RestTemplate 完成類(lèi)加載和連接建立Component public class FeignPreheatRunner implements ApplicationRunner { private final UserClient userClient; public FeignPreheatRunner(UserClient userClient) { this.userClient userClient; } Override public void run(ApplicationArguments args) { // 提前觸發(fā)一次調(diào)用用于初始化代理類(lèi)和連接池 try { userClient.getInfo(preheat); } catch (Exception ignore) { // 預(yù)熱失敗不影響正常啟動(dòng) } } }這種方式的原理很好理解操作系統(tǒng)和 JVM 層面類(lèi)加載、動(dòng)態(tài)代理生成、TCP 連接建立都是需要時(shí)間的。第一次調(diào)用這些資源都沒(méi)準(zhǔn)備好所以要慢預(yù)熱之后這些資源都在了后續(xù)調(diào)用自然快。4.3 Docker 環(huán)境下的特別注意事項(xiàng)如果你用的是 Docker 部署的 Nacos Server還需要額外注意容器網(wǎng)絡(luò)對(duì)首次調(diào)用的影響。一個(gè)常見(jiàn)的場(chǎng)景Nacos Server 跑在 Docker 里客戶(hù)端跑在宿主機(jī)上?？蛻?hù)端配置的server-addr127.0.0.1:8848初次連接時(shí)如果 Nacos Server 返回給客戶(hù)端的服務(wù)實(shí)例 IP 是容器網(wǎng)段地址而客戶(hù)端無(wú)法訪(fǎng)問(wèn)這個(gè)網(wǎng)段就會(huì)導(dǎo)致連接失敗。首次調(diào)用時(shí)客戶(hù)端需要重新建立連接而連接失敗的重試時(shí)間往往比較長(zhǎng)。另一個(gè)場(chǎng)景客戶(hù)端跑在 Docker 容器里Nacos Server 在宿主機(jī)上。客戶(hù)端里的127.0.0.1指向的是容器自身而不是宿主機(jī)的 Nacos Server。這個(gè)可以說(shuō)是新手最容易踩的坑。解決方法是配置為宿主機(jī)的局域網(wǎng) IP或者使用 Docker 的host_network模式。Docker 環(huán)境下還經(jīng)常遇到 DNS 解析慢的問(wèn)題。如果 Nacos 用了域名而不是 IP容器內(nèi) DNS 解析延遲會(huì)直接疊加到首次調(diào)用耗時(shí)上。解決方法是讓 Nacos 服務(wù)端注冊(cè)為 IP 地址而不是主機(jī)名客戶(hù)端也盡量用 IP。4.4 完整配置參考可直接復(fù)制把上面所有客戶(hù)端配置匯總成一個(gè)相對(duì)完整的版本spring: application: name: order-service cloud: nacos: discovery: server-addr: nacos.example.com:8848 namespace: public group: DEFAULT_GROUP register-enabled: true fail-fast: true cache-enabled: true config: server-addr: nacos.example.com:8848 file-extension: yaml namespace: public group: DEFAULT_GROUP refresh-enabled: true loadbalancer: eager-load: enabled: true clients: user-service, stock-service啟動(dòng)應(yīng)用時(shí)額外加上 JVM 參數(shù)java -jar order-service.jar \ -Dnacos.naming.cache.dir/opt/nacos/cache \ -Dnacos.logging.default.config.enabledfalse-Dnacos.naming.cache.dir指定服務(wù)列表本地緩存目錄方便排查時(shí)直接查看緩存內(nèi)容。5. Nacos 健康檢查機(jī)制與配置補(bǔ)充5.1 健康檢查的基礎(chǔ)概念Nacos 的健康檢查分為兩個(gè)層面服務(wù)端視角的健康檢查和客戶(hù)端視角的健康檢查。服務(wù)端視角Nacos 會(huì)定期檢查臨時(shí)實(shí)例的存活狀態(tài)。臨時(shí)實(shí)例ephemeraltrue通過(guò)客戶(hù)端心跳續(xù)約默認(rèn)心跳間隔 5 秒超時(shí)時(shí)間 15 秒持久化實(shí)例ephemeralfalse由服務(wù)端主動(dòng)探測(cè)探測(cè)路徑為/actuator/health。客戶(hù)端視角Spring Cloud Alibaba 的健康檢查器會(huì)定期檢查服務(wù)列表是否就緒如果服務(wù)列表為空會(huì)把該服務(wù)標(biāo)記為不健康。這就是spring.cloud.discovery.client.health-indicator.enabledtrue配置的作用。完整的健康檢查配置如下management: endpoints: web: exposure: include: health,info,metrics health: nacos: enabled: true5.2 健康檢查與首次調(diào)用的關(guān)聯(lián)健康檢查和首次調(diào)用慢有什么關(guān)系關(guān)系大得很。如果上游服務(wù)有一個(gè)定期健康檢查器它每 30 秒檢查一次下游服務(wù)列表那么服務(wù)剛啟動(dòng)時(shí)如果健康檢查失敗因?yàn)榉?wù)列表還沒(méi)就緒這個(gè)失敗狀態(tài)會(huì)被標(biāo)記在注冊(cè)中心。此時(shí)如果其他服務(wù)嘗試調(diào)用這個(gè)剛啟動(dòng)的服務(wù)會(huì)發(fā)現(xiàn)它是不健康的于是拒絕調(diào)用或者走重試邏輯導(dǎo)致首次調(diào)用慢。這種問(wèn)題的解法是調(diào)整健康檢查器的狀態(tài)讓服務(wù)在啟動(dòng)初期不被標(biāo)記為不健康或者把健康檢查器的啟動(dòng)延遲調(diào)大spring: cloud: discovery: client: health-indicator: enabled: trueNacos Client 內(nèi)部有一個(gè)NacosWatch組件它每隔一段時(shí)間拉取服務(wù)列表并檢查所有健康狀態(tài)。如果你發(fā)現(xiàn)服務(wù)啟動(dòng)后需要等 30 秒左右才能被正常調(diào)用八九不離十跟這個(gè)NacosWatch的默認(rèn)重試間隔有關(guān)系。5.3 配置適度原則避免過(guò)度優(yōu)化這里必須潑一盆冷水Nacos 的配置不是越多越好也不是所有優(yōu)化手段都該一起上。我見(jiàn)過(guò)有人把健康檢查的間隔從 30 秒調(diào)到 1 秒把心跳間隔從 5 秒調(diào)到 1 秒把所有超時(shí)時(shí)間都調(diào)成 10 秒以上結(jié)果 Nacos Server 負(fù)載暴增服務(wù)端 GC 頻繁整體性能反而更差。你要清楚每個(gè)配置項(xiàng)背后的代價(jià)心跳間隔越短N(yùn)acos Server 收到的請(qǐng)求越多服務(wù)端壓力越大。健康檢查越頻繁客戶(hù)端和服務(wù)端的網(wǎng)絡(luò)開(kāi)銷(xiāo)越高。負(fù)載均衡預(yù)熱服務(wù)越多應(yīng)用啟動(dòng)時(shí)間越長(zhǎng)。所以我的建議是如果服務(wù)規(guī)模不大優(yōu)先做負(fù)載均衡預(yù)熱 Nacos 客戶(hù)端參數(shù)微調(diào)這兩個(gè)動(dòng)作其他配置按需追加。先解決主要矛盾再處理次要矛盾。6. 常見(jiàn)問(wèn)題與排查技巧6.1 問(wèn)題速查表問(wèn)題現(xiàn)象可能原因解決方案首次調(diào)用慢后續(xù)正常負(fù)載均衡懶加載開(kāi)啟 eager-load預(yù)熱指定服務(wù)服務(wù)啟動(dòng)后一段時(shí)間內(nèi)無(wú)法被調(diào)用NacosWatch 未就緒檢查spring.cloud.discovery.client.health-indicator.enabled結(jié)合健康檢查線(xiàn)程池調(diào)優(yōu)注冊(cè)成功但調(diào)用超時(shí)gRPC 端口 9848 不通檢查防火墻和 Docker 端口映射配置中心拉取慢網(wǎng)絡(luò)延遲或超時(shí)設(shè)置不合理調(diào)整spring.cloud.nacos.config.timeout首次調(diào)用時(shí)連接被拒絕客戶(hù)端初始化連接池過(guò)慢通過(guò) Feign/RestTemplate 預(yù)熱或調(diào)整連接池參數(shù)服務(wù)重啟后第一次調(diào)用極慢本地緩存未加載設(shè)置namingLoadCacheAtStarttrue6.2 排查技巧與工具清單實(shí)際排障過(guò)程中我總結(jié)了一套固定動(dòng)作分享出來(lái)供參考第一步看 Nacos 客戶(hù)端日志。Nacos 日志記錄了注冊(cè)、訂閱、心跳全過(guò)程的詳細(xì)時(shí)間線(xiàn)是定位問(wèn)題最直接的信息源。用grep過(guò)濾關(guān)鍵字即可grep -E register|subscribe|heartbeat|service list|get service logs/nacos/nacos-client.log | head -50第二步抓線(xiàn)程狀態(tài)。如果首次調(diào)用卡住用jstack看看卡在哪個(gè)線(xiàn)程。如果線(xiàn)程停留在SocketRead或者WAITING狀態(tài)十有八九是在等 Nacos 的響應(yīng)。第三步用 Arthas 做方法級(jí)追蹤。剛才提到的trace命令可以直接看到NacosServiceManager或LoadBalancer的內(nèi)部調(diào)用耗時(shí)分布不用改代碼就能定位熱點(diǎn)。第四步檢查網(wǎng)絡(luò)鏈路。用telnet或nc驗(yàn)證 8848 和 9848 端口是否連通。這一步最簡(jiǎn)單但能排除一半以上的問(wèn)題。6.3 采坑經(jīng)驗(yàn)匯總我在處理 Nacos 問(wèn)題的過(guò)程中攢下了一些很有意思的踩坑經(jīng)驗(yàn)挑幾個(gè)典型的分享第一版本混用的問(wèn)題。某個(gè)項(xiàng)目里注冊(cè)中心用的是 Nacos Server 1.4.2但客戶(hù)端依賴(lài)被 Spring Cloud Alibaba 自動(dòng)升級(jí)到了 2.x。2.x 的客戶(hù)端會(huì)嘗試通過(guò) gRPC 連接服務(wù)端而 1.4.2 的 Server 不支持 gRPC于是客戶(hù)端在兼容模式下退回到 1.x 的 HTTP 連接。這個(gè)回退過(guò)程在日志里幾乎看不到不對(duì)日志里會(huì)有一條明顯的連接異常記錄但很多人沒(méi)細(xì)看就導(dǎo)致每次首次調(diào)用都慢。排查這個(gè)問(wèn)題時(shí)第一件事就是確認(rèn)服務(wù)端和客戶(hù)端的大版本是否一致。第二多網(wǎng)卡問(wèn)題。服務(wù)器上有多塊網(wǎng)卡Nacos 客戶(hù)端注冊(cè)時(shí)選錯(cuò)了網(wǎng)卡 IP注冊(cè)的地址不可達(dá)。服務(wù)調(diào)用方拿到這個(gè)不可達(dá)的地址第一次連接就會(huì)超時(shí)。解決方法是顯式指定客戶(hù)端的 IPspring: cloud: nacos: discovery: ip: 192.168.1.100第三Spring Cloud 上下文刷新導(dǎo)致配置丟失。項(xiàng)目里用了RefreshScope在配置變更后觸發(fā)刷新但刷新過(guò)程中 Feign 客戶(hù)端被重建了重建后的客戶(hù)端是冷啟動(dòng)的就會(huì)出現(xiàn)非首次調(diào)用也慢的假象。這個(gè)坑很容易誤判為 Nacos 的問(wèn)題其實(shí)只是上下文刷新導(dǎo)致的懶加載重來(lái)。6.4 快速驗(yàn)證優(yōu)化效果的方法每次調(diào)整完配置都建議做一個(gè)標(biāo)準(zhǔn)化的驗(yàn)證不然你無(wú)法判斷這次優(yōu)化到底有沒(méi)有效果。我的驗(yàn)證流程是重啟服務(wù)清理所有本地緩存文件。記錄服務(wù)啟動(dòng)完成的時(shí)間點(diǎn)。立即發(fā)起第一次調(diào)用記錄耗時(shí)。連續(xù)調(diào)用 10 次記錄平均耗時(shí)。對(duì)比優(yōu)化前后的數(shù)據(jù)。如果首次調(diào)用耗時(shí)下降超過(guò) 50%說(shuō)明優(yōu)化生效了如果變化不明顯那就需要回到日志分析環(huán)節(jié)看看耗時(shí)到底消耗在哪一步。7. 實(shí)際操作中的一點(diǎn)體會(huì)最后聊點(diǎn)實(shí)際的。Nacos 首次調(diào)用慢這個(gè)問(wèn)題網(wǎng)上能搜到大量資料但每個(gè)團(tuán)隊(duì)的環(huán)境都不一樣直接抄別人的配置不一定好用。我個(gè)人在實(shí)戰(zhàn)中最大的體會(huì)是不要一上來(lái)就改配置先花十分鐘看日志把慢的環(huán)節(jié)確認(rèn)清楚。大多數(shù)情況下問(wèn)題定位準(zhǔn)確之后真正需要改的配置往往只有一兩個(gè)。我自己的習(xí)慣是加入 Nacos 的項(xiàng)目會(huì)提前把nacos-client.log的日志級(jí)別調(diào)到 DEBUG 并歸檔保留這樣出問(wèn)題的時(shí)候有據(jù)可查。同時(shí)會(huì)在項(xiàng)目里放一個(gè)啟動(dòng)自檢的接口專(zhuān)門(mén)用來(lái)觸發(fā) Feign 客戶(hù)端的預(yù)熱和一個(gè)無(wú)業(yè)務(wù)邏輯的服務(wù)發(fā)現(xiàn)查詢(xún)這樣既能順帶做健康檢查又能把首次調(diào)用慢的風(fēng)險(xiǎn)轉(zhuǎn)移到啟動(dòng)流程內(nèi)部而不是暴露給真實(shí)的業(yè)務(wù)請(qǐng)求。還有一個(gè)小技巧如果你在壓測(cè)或者聯(lián)調(diào)環(huán)境下需要頻繁重啟服務(wù)可以考慮在啟動(dòng)參數(shù)中加-Dnacos.naming.cache.dir指定一個(gè)持久化的緩存目錄這樣服務(wù)重啟后還能復(fù)用上一次的本地緩存減少服務(wù)列表拉取的等待時(shí)間。這個(gè)方向還可以延伸一步Nacos 集群模式下多個(gè)節(jié)點(diǎn)之間的數(shù)據(jù)一致性、Client 端從哪個(gè)節(jié)點(diǎn)拉取最新列表的調(diào)度策略都會(huì)影響服務(wù)的發(fā)現(xiàn)延遲。如果你們團(tuán)隊(duì)的 Nacos 規(guī)模比較大建議后面在做容量規(guī)劃時(shí)把客戶(hù)端的注冊(cè)、心跳、訂閱請(qǐng)求量納入評(píng)估而不是只盯著服務(wù)端 CPU 和內(nèi)存用。先把客戶(hù)端這側(cè)的基礎(chǔ)打牢服務(wù)端才能真的省心。