0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會(huì)員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

Java微服務(wù)隨機(jī)掉線排查過程

jf_ro2CN3Fa ? 來源:芋道源碼 ? 2023-03-07 09:30 ? 次閱讀

背景

我們的業(yè)務(wù)共使用 11 臺(tái)(阿里云)服務(wù)器,使用 SpringcloudAlibaba 構(gòu)建微服務(wù)集群, 共計(jì) 60 個(gè)微服務(wù), 全部注冊在同一個(gè) Nacos 集群。

流量轉(zhuǎn)發(fā)路徑:nginx -> spring-gateway -> 業(yè)務(wù)微服務(wù)。

使用的版本如下:

spring-boot.version:2.2.5.RELEASE

spring-cloud.version:Hoxton.SR3

spring-cloud-alibaba.version:2.2.1.RELEASE

java.version:1.8

基于 Spring Boot + MyBatis Plus + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序,支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項(xiàng)目地址:https://github.com/YunaiV/ruoyi-vue-pro

視頻教程:https://doc.iocoder.cn/video/

案發(fā)

春節(jié)放假期間收到反饋,網(wǎng)頁報(bào)錯(cuò)服務(wù)未找到(gateway 找不到服務(wù)的報(bào)錯(cuò)提示)。查看 nacos 集群列表,發(fā)現(xiàn)個(gè)別服務(wù)丟失 (下線)。

這個(gè)問題每幾天出現(xiàn)一次, 出現(xiàn)時(shí)間不固定, 每次掉線的服務(wù)像是隨機(jī)選的幾個(gè)。服務(wù)手動(dòng) kill+restart 后能穩(wěn)定運(yùn)行 2-3 天。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序,支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項(xiàng)目地址:https://github.com/YunaiV/yudao-cloud

視頻教程:https://doc.iocoder.cn/video/

排查和解決

懷疑對象一:服務(wù)器內(nèi)存爆了

進(jìn)阿里云控制臺(tái)查看故障機(jī)器近期的各項(xiàng)指標(biāo),但是發(fā)現(xiàn)故障機(jī)器的指標(biāo)有重要的幾項(xiàng)丟失。內(nèi)存使用率、CPU 使用率、系統(tǒng)負(fù)載均不顯示。

1509ec3e-bc7e-11ed-bfe3-dac502259ad0.jpg

控制臺(tái)看不了只好進(jìn)服務(wù)器內(nèi)查看各指標(biāo),free -m 查看內(nèi)存無異常。提交阿里工單。授權(quán)阿里工程師幫忙修復(fù)控制臺(tái)顯示問題,懷疑這個(gè)問題對業(yè)務(wù)有影響。

151b7224-bc7e-11ed-bfe3-dac502259ad0.jpg

控制臺(tái)修復(fù)后掉線問題依然存在。

懷疑對象二:CPU滿載

能感覺到執(zhí)行命令很流暢,所以感覺不是這個(gè)原因。top 查看后很正常。

懷疑對象三:磁盤滿了

雖然概率很小,但是 du -sh * 看一下,發(fā)現(xiàn)磁盤容量還能用到公司倒閉。

懷疑對象四:網(wǎng)絡(luò)有問題

服務(wù)器那三個(gè)基本故障暫時(shí)排除后,最大懷疑對象就是網(wǎng)絡(luò)。畢竟服務(wù)掉線肯定是服務(wù)端一段時(shí)間內(nèi)接收不到客戶端心跳包,所以把客戶端踢下線了。

通過 telnet,mtr -n ...,netstat -nat |grep "TIME_WAIT" | wc -l 這些命令也只能看個(gè)大概。

echo "1" > /proc/sys/net/ipv4/tcp_tw_reuse 修改內(nèi)核參數(shù),開啟 TIME_WAIT socket 復(fù)用能力,提升實(shí)例的網(wǎng)絡(luò)發(fā)送請求性能。

查看 nacos 客戶端(微服務(wù))的日志,在前面案發(fā)里提到?jīng)]有日志記錄。

懷疑對象五:Nacos 集群服務(wù)端故障

查看 nacos 集群部署的那幾臺(tái)服務(wù)器, 查看服務(wù)器基礎(chǔ)指標(biāo) (內(nèi)存、CPU、磁盤等),未發(fā)現(xiàn)異常 (畢竟還有幾十個(gè)微服務(wù)都很正常工作)。

查看 nacos 服務(wù)端日志,發(fā)現(xiàn)確實(shí)有主動(dòng)下線服務(wù)操作。那就奇怪了,這個(gè)機(jī)器上的有些服務(wù)還在正常工作,為什么會(huì)隨機(jī)下線幾個(gè)服務(wù)呢?

懷疑對象六:微服務(wù)占用資源太多

后來仔細(xì)想想,這個(gè)懷疑對象是不是有點(diǎn)離譜了?因?yàn)椴渴鹉_本都是同一個(gè),而且負(fù)載均衡也是一樣的。但其他機(jī)器的這個(gè)服務(wù)都好好的。

調(diào)大每個(gè)微服務(wù)的內(nèi)存占用。

添加堆棧打印。

15377b2c-bc7e-11ed-bfe3-dac502259ad0.jpg

等待一段時(shí)間后,異常依然存在,并且沒有堆棧打???因?yàn)檫M(jìn)程好好的并沒退出。

google 搜索 nacos 服務(wù)掉線,找到一篇看起來極其靠譜的文章。

154d718e-bc7e-11ed-bfe3-dac502259ad0.jpg

上文提到我使用的 springcloud 版本,恰好這個(gè)版本的 nacos-client 版本就是 1.4.1, 于是立馬測試升級。

156a6532-bc7e-11ed-bfe3-dac502259ad0.jpg

觀察幾天后,發(fā)現(xiàn)問題依舊,只能將探查方向繼續(xù)轉(zhuǎn)回微服務(wù)本身。

用 arthas 進(jìn)行勘測各項(xiàng)指標(biāo),發(fā)現(xiàn)所有正常的服務(wù)各指標(biāo)均正常。

想到服務(wù)掉線大概率是因?yàn)樾奶鼇G失,懷疑是心跳線程因?yàn)槟承┰虮粴⑺懒恕?/p>

翻看 nacos-client 源碼,找到心跳函數(shù)(nacos2.x 不是這個(gè)),使用 arthas 監(jiān)聽心跳包,嘗試能找到心跳丟失的證據(jù),貼上當(dāng)時(shí)的記錄。

158a3e98-bc7e-11ed-bfe3-dac502259ad0.jpg

159e847a-bc7e-11ed-bfe3-dac502259ad0.jpg

15b3e842-bc7e-11ed-bfe3-dac502259ad0.jpg

當(dāng)異常再次發(fā)生,arthas 監(jiān)聽卡死,無任何記錄和響應(yīng)。

無奈更換思路,寫一個(gè)監(jiān)聽服務(wù)掉線的程序,期望可以在工作時(shí)間內(nèi)及時(shí)獲取到異常。

15c914e2-bc7e-11ed-bfe3-dac502259ad0.jpg

終于在工作時(shí)間捕獲到異常,第一時(shí)間進(jìn)入服務(wù)器內(nèi)查看情況。

15ddcf18-bc7e-11ed-bfe3-dac502259ad0.jpg

確認(rèn)服務(wù)器基礎(chǔ)項(xiàng)沒問題后,使用 arthas 查看服務(wù)進(jìn)程堆棧情況,但是 arthas 無法進(jìn)入進(jìn)程。

15f40936-bc7e-11ed-bfe3-dac502259ad0.jpg

用 jstat 查看 GC 情況,顯示很正常。

160c1a26-bc7e-11ed-bfe3-dac502259ad0.jpg

用 jmap/jstack 輸出堆棧 jstack -l 25944 >heap.txt,但是提示無法進(jìn)入進(jìn)程。無奈使用添加 - F(這個(gè)參數(shù)的堆棧少了很多信息),jstack -F -l 25944 >heap.txt

查看堆棧文件上萬行記錄,眼都看花了但是沒有死鎖也沒有發(fā)現(xiàn)異常。

此時(shí)發(fā)現(xiàn)監(jiān)聽程序提示服務(wù)上線了?檢查后發(fā)現(xiàn)確實(shí)掉線的幾個(gè)微服務(wù)自動(dòng)恢復(fù)了,心想這就難排查了。

嘗試復(fù)現(xiàn) Bug,此時(shí)離第一次案發(fā)已經(jīng)過去一周多,必須盡快處理好這個(gè) Bug 否則可能得被迫離職了。

當(dāng)?shù)诙伟l(fā)生異常的時(shí)候,使用同樣的方式 arthas 無法進(jìn)入 ->...->jstack 輸出堆棧。奇跡發(fā)生了,服務(wù)又恢復(fù)正常了。

思考 / 猜測:因?yàn)?JVM 死了(假死),所以導(dǎo)致進(jìn)程中的一切內(nèi)容,包括心跳線程、日志等都 hold 住。

Google 搜索關(guān)鍵詞 JVM 停止(假死)排查,終于找到一個(gè)極其靠譜的回答。

16223568-bc7e-11ed-bfe3-dac502259ad0.jpg

連忙查看對比使用的幾個(gè)機(jī)器內(nèi)核版本號 uname -r。

1645a46c-bc7e-11ed-bfe3-dac502259ad0.png

1656a7c6-bc7e-11ed-bfe3-dac502259ad0.jpg

那個(gè)低版本的就是故障機(jī)器,確認(rèn)相關(guān)信息后,聯(lián)系阿里云提交工單。

16707e9e-bc7e-11ed-bfe3-dac502259ad0.jpg

升級完內(nèi)核并重啟機(jī)器后,觀察兩天至今這個(gè)問題不存在了。誰能想到這個(gè)問題居然是因?yàn)?Linux 內(nèi)核的 Bug 引起的?!不得不佩服第一個(gè)發(fā)現(xiàn)這個(gè) Bug 的大佬。

168a9c0c-bc7e-11ed-bfe3-dac502259ad0.jpg

完結(jié)感言

這個(gè)問題折磨了一周多,每日如鯁在喉!調(diào)試過程也是苦樂參半,樂的是突然有了調(diào)試思路,苦的是思路是一條死胡同,還好最終結(jié)果是滿意的。

作為一名程序員,還是要時(shí)刻保持一顆探索的心,學(xué)海無涯!

審核編輯 :李倩

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報(bào)投訴
  • 服務(wù)器
    +關(guān)注

    關(guān)注

    12

    文章

    8983

    瀏覽量

    85107
  • JAVA
    +關(guān)注

    關(guān)注

    19

    文章

    2953

    瀏覽量

    104496
  • spring
    +關(guān)注

    關(guān)注

    0

    文章

    338

    瀏覽量

    14298
  • 微服務(wù)
    +關(guān)注

    關(guān)注

    0

    文章

    131

    瀏覽量

    7322

原文標(biāo)題:Java 微服務(wù)隨機(jī)掉線排查過程

文章出處:【微信號:芋道源碼,微信公眾號:芋道源碼】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏

    評論

    相關(guān)推薦

    波特率漂移導(dǎo)致通信異常的故障排查過程

    示波器的協(xié)議解碼功能大家都不生疏,你是否有過波形看起來正常,協(xié)議參數(shù)、解碼設(shè)置都正確,卻無法正常解碼的經(jīng)歷呢?本文以UART協(xié)議為例,分享由于波特率漂移導(dǎo)致通信異常的故障排查過程
    的頭像 發(fā)表于 01-08 13:51 ?6354次閱讀
    波特率漂移導(dǎo)致通信異常的故障<b class='flag-5'>排查過程</b>

    網(wǎng)絡(luò)通訊中隨機(jī)數(shù)不隨機(jī)引發(fā)的問題及解決方法

    最近在排查一個(gè)項(xiàng)目的性能壓測問題,十分偶然地發(fā)現(xiàn)一個(gè)莫名偶現(xiàn)的網(wǎng)絡(luò)掉線問題,最后排查發(fā)現(xiàn)居然跟系統(tǒng)的隨機(jī)數(shù)特性有莫大的關(guān)系。
    的頭像 發(fā)表于 03-10 11:51 ?4394次閱讀
    網(wǎng)絡(luò)通訊中<b class='flag-5'>隨機(jī)</b>數(shù)不<b class='flag-5'>隨機(jī)</b>引發(fā)的問題及解決方法

    微服務(wù)架構(gòu)和CQRS架構(gòu)基本概念介紹

    微服務(wù)架構(gòu)現(xiàn)在很熱,到處可以看到各大互聯(lián)網(wǎng)公司的微服務(wù)實(shí)踐的分享總結(jié)。但是,我今天的分享和微服務(wù)沒有關(guān)系,希望可以帶給大家一些新的東西。如果一定要說微服務(wù)和CQRS架構(gòu)的關(guān)系,那我覺得
    發(fā)表于 05-22 09:03

    微服務(wù)網(wǎng)關(guān)gateway的相關(guān)資料推薦

    目錄微服務(wù)網(wǎng)關(guān) gateway 概述[路由器網(wǎng)關(guān) Zuul 概述]嵌入式 Zuul 反向代理微服務(wù)網(wǎng)關(guān) gateway 概述1、想象一下一個(gè)購物應(yīng)用程序的產(chǎn)品詳情頁面展示了指定商品的信息:2、若是
    發(fā)表于 12-23 08:19

    java微服務(wù)生態(tài)系統(tǒng)模型解讀

    微服務(wù)并不是孤立存在的,它們存在于一個(gè)環(huán)境里,微服務(wù)在這個(gè)環(huán)境里進(jìn)行交互。把這種環(huán)境看成微服務(wù)生態(tài)系統(tǒng)并分層,有助于理解微服務(wù)架構(gòu)。 在一個(gè)設(shè)計(jì)良好的
    發(fā)表于 09-27 13:06 ?0次下載
    <b class='flag-5'>java</b><b class='flag-5'>微服務(wù)</b>生態(tài)系統(tǒng)模型解讀

    實(shí)例分析Java微服務(wù)框架和優(yōu)勢

    本文首先簡單介紹了微服務(wù)的概念以及使用微服務(wù)所能帶來的優(yōu)勢,然后結(jié)合實(shí)例介紹了幾個(gè)常見的Java微服務(wù)框架。 微服務(wù)在開發(fā)領(lǐng)域的應(yīng)用越來越廣
    發(fā)表于 09-28 17:33 ?0次下載

    java微服務(wù)架構(gòu)有哪些

    本文首先簡單介紹了微服務(wù)的概念以及使用微服務(wù)所能帶來的優(yōu)勢,然后結(jié)合實(shí)例介紹了幾個(gè)常見的Java微服務(wù)框架。微服務(wù)在開發(fā)領(lǐng)域的應(yīng)用越來越廣泛
    的頭像 發(fā)表于 02-09 10:34 ?8611次閱讀
    <b class='flag-5'>java</b><b class='flag-5'>微服務(wù)</b>架構(gòu)有哪些

    什么是微服務(wù)和容器?微服務(wù)和容器的作用是什么

    微服務(wù)是將應(yīng)用程序拆分為多個(gè)服務(wù)的一種架構(gòu)類型,這些服務(wù)具備構(gòu)成整個(gè)應(yīng)用程序的細(xì)粒度功能。每個(gè)微服務(wù)將具備針對您的應(yīng)用程序的不同邏輯功能。與應(yīng)用程序的所有組件和功能都在單個(gè)實(shí)例中的單體
    的頭像 發(fā)表于 01-13 10:54 ?3.2w次閱讀
    什么是<b class='flag-5'>微服務(wù)</b>和容器?<b class='flag-5'>微服務(wù)</b>和容器的作用是什么

    DC-DC電源故障排查過程和總結(jié),珍貴的經(jīng)驗(yàn)!資料下載

    電子發(fā)燒友網(wǎng)為你提供DC-DC電源故障排查過程和總結(jié),珍貴的經(jīng)驗(yàn)!資料下載的電子資料下載,更有其他相關(guān)的電路圖、源代碼、課件教程、中文資料、英文資料、參考設(shè)計(jì)、用戶指南、解決方案等資料,希望可以幫助到廣大的電子工程師們。
    發(fā)表于 04-25 08:54 ?75次下載
    DC-DC電源故障<b class='flag-5'>排查過程</b>和總結(jié),珍貴的經(jīng)驗(yàn)!資料下載

    JVM CPU使用率飆高問題的排查分析過程

    %,為什么會(huì)出現(xiàn)這樣的現(xiàn)象呢? 排查過程 Step 1: 使用top命令,查詢資源占用情況: 如上圖所示,顯示了服務(wù)器當(dāng)前的資源占用情況,其中PID為5456的進(jìn)程占用的資源最多。 在這里,我們也使用top
    的頭像 發(fā)表于 10-10 16:31 ?2260次閱讀

    glibc導(dǎo)致的堆外內(nèi)存泄露的排查過程

    本文記錄一次glibc導(dǎo)致的堆外內(nèi)存泄露的排查過程
    的頭像 發(fā)表于 09-01 09:43 ?663次閱讀
    glibc導(dǎo)致的堆外內(nèi)存泄露的<b class='flag-5'>排查過程</b>

    springcloud微服務(wù)架構(gòu)

    Spring Cloud是一個(gè)開源的微服務(wù)架構(gòu)框架,它提供了一系列工具和組件,用于構(gòu)建和管理分布式系統(tǒng)中的微服務(wù)。它基于Spring框架,旨在通過簡化開發(fā)過程和降低系統(tǒng)復(fù)雜性來幫助開發(fā)人員構(gòu)建彈性
    的頭像 發(fā)表于 11-23 09:24 ?1177次閱讀

    java內(nèi)存溢出排查方法

    Java內(nèi)存溢出(Memory overflow)是指Java虛擬機(jī)(JVM)中的堆內(nèi)存無法滿足對象分配的需求,導(dǎo)致程序拋出OutOfMemoryError異常。內(nèi)存溢出是Java開發(fā)過程
    的頭像 發(fā)表于 11-23 14:46 ?3056次閱讀

    Java怎么排查oom異常

    據(jù)量的應(yīng)用中。要排查OOM異常,需要經(jīng)過以下幾個(gè)步驟: 理解OOM異常的原因:OOM異常通常有以下幾個(gè)原因:內(nèi)存泄露、內(nèi)存溢出、內(nèi)存不足以容納所需的數(shù)據(jù)等。理解OOM異常的原因?qū)?b class='flag-5'>排查問題非常重要。 配置Java堆內(nèi)存:要解決OO
    的頭像 發(fā)表于 12-05 13:47 ?1196次閱讀

    Java微服務(wù)隨機(jī)掉線排查過程簡析

    我們的業(yè)務(wù)共使用 11 臺(tái)(阿里云)服務(wù)器,使用 SpringcloudAlibaba 構(gòu)建微服務(wù)集群, 共計(jì) 60 個(gè)微服務(wù), 全部注冊在同一個(gè) Nacos 集群。
    的頭像 發(fā)表于 01-13 17:41 ?890次閱讀
    <b class='flag-5'>Java</b><b class='flag-5'>微服務(wù)</b><b class='flag-5'>隨機(jī)</b><b class='flag-5'>掉線</b><b class='flag-5'>排查過程</b>簡析