本文根據(jù)近期大家聯(lián)調(diào)過程中出現(xiàn)的一些問題,做了一些梳理。其內(nèi)容涉及人力云、協(xié)同云、財(cái)務(wù)云、云平臺(tái)等多個(gè)領(lǐng)域。大家在奮戰(zhàn)的過程中相互幫助,在掉坑與爬坑中不斷進(jìn)步。經(jīng)過不斷磨合,研發(fā)調(diào)試上線過程慢慢順暢起來。本期梳理出趟坑36計(jì)中的8計(jì),后續(xù)會(huì)不斷梳理輸出其他部分給大家,一起進(jìn)步,防止遇到類似問題掉坑翻車。
1、應(yīng)用訪問時(shí)出現(xiàn)504錯(cuò)誤
發(fā)現(xiàn)問題
應(yīng)用不能正常訪問,在瀏覽器中提示504錯(cuò)誤,查看容器內(nèi)部僵死。
根因分析
應(yīng)用通過域名不能正確訪問,顯示504錯(cuò)誤,或者是長時(shí)間卡住不動(dòng)。
通過控制臺(tái)進(jìn)入到容器里面,通過
curl localhost:8080
命令也不能訪問,證明應(yīng)用自身已死掉。
應(yīng)用日志沒明顯異常信息,通過jstack打出堆棧信息,發(fā)現(xiàn)大量的logback寫日志線程等待。
網(wǎng)上也有同學(xué)遇到多線程死鎖問題,供參閱:
https://blog.csdn.net/shipengyy/article/details/50184709
解決辦法
將應(yīng)用代碼中,logback配置文件里,向console打日志的部分注釋掉。
2、應(yīng)用聯(lián)調(diào)測試環(huán)境時(shí)好時(shí)壞
發(fā)現(xiàn)問題
應(yīng)用聯(lián)調(diào)測試過程中,調(diào)用時(shí)好時(shí)壞,環(huán)境一天可用時(shí)間難以保證。
根因分析
測試某個(gè)功能,一會(huì)好用,一會(huì)不好用了。此時(shí),某些同學(xué)修改了代碼,進(jìn)行了服務(wù)的重啟。導(dǎo)致重啟的過程中,服務(wù)調(diào)用失敗。
由于服務(wù)調(diào)用鏈路比較多而且繁雜,只要其中一個(gè)環(huán)節(jié)不可用,就會(huì)導(dǎo)致整個(gè)功能測試中斷,讓大家保持步調(diào)一致,以提升環(huán)境穩(wěn)定性。
解決辦法
約定大家的測試環(huán)境更新時(shí)間,更新(代碼、修改配置、數(shù)據(jù)庫)的時(shí)間為12:00-13:00、17:30-18:30。
3、應(yīng)用已僵死,但狀態(tài)仍顯示健康
發(fā)現(xiàn)問題
應(yīng)用的健康狀態(tài)顯示正常,但應(yīng)用實(shí)際已僵死,不能準(zhǔn)確感知應(yīng)用狀態(tài)
根因分析
由于默認(rèn)是基于端口進(jìn)行健康檢查,所以顯示的狀態(tài)是端口存活狀態(tài),不能真實(shí)的反饋出來應(yīng)用的健康度。
如果配置了http方式的檢查url,可以根據(jù)檢查mysql、redis、核心服務(wù)等方式,確定服務(wù)的健康狀況。
解決辦法
增加http的健康檢查url,如:/healthcheck,并編寫詳細(xì)的檢查邏輯。
4、微服務(wù)調(diào)用不通
發(fā)現(xiàn)問題
微服務(wù)調(diào)用時(shí),發(fā)現(xiàn)調(diào)用接口不通。
根因分析
線上的測試環(huán)境,服務(wù)調(diào)用失敗,報(bào)網(wǎng)絡(luò)錯(cuò)誤。
一般是本地的服務(wù)注冊(cè)到線上了,或者是停掉的服務(wù),沒能及時(shí)的從服務(wù)注冊(cè)中心注銷掉,導(dǎo)致服務(wù)消費(fèi)方,調(diào)用到了壞的服務(wù)提供方。
解決辦法
將本地IDE中啟動(dòng)的微服務(wù),環(huán)境改對(duì),防止線上服務(wù)調(diào)用到本地筆記本上的情況(或拔掉網(wǎng)線)。
其他情況,也可以聯(lián)系運(yùn)維同學(xué),幫大家從后臺(tái)殺掉野服務(wù)或狀態(tài)不同步的服務(wù)。
5、應(yīng)用重啟升級(jí)時(shí),異常實(shí)例還存在
發(fā)現(xiàn)問題
將應(yīng)用重啟或升級(jí)時(shí),健康狀態(tài)為異常容器實(shí)例仍然存在。
根因分析
應(yīng)用升級(jí)的過程中,由于線程死鎖或等待狀態(tài),導(dǎo)致發(fā)送了kill信號(hào)后,容器不能及時(shí)被殺掉。
用戶只能等在那,點(diǎn)擊銷毀實(shí)例按鈕,也不生效,待優(yōu)雅退出后,才能完成升級(jí)。
導(dǎo)致這個(gè)問題的原因主要有兩種:
- 大量請(qǐng)求訪問,存在大量積壓的線程
- 應(yīng)用本身線程死鎖,狀態(tài)異常
解決辦法
平臺(tái)優(yōu)化調(diào)度器,對(duì)于不能優(yōu)雅退出的應(yīng)用,增加強(qiáng)殺策略。
6、應(yīng)用管理詳情中的日志不顯示或有延遲
發(fā)現(xiàn)問題
在應(yīng)用管理詳情頁面中,點(diǎn)擊日志,發(fā)現(xiàn)日志不顯示,或者顯示有延遲現(xiàn)象
根因分析
在應(yīng)用詳情頁面中,通過日志頁簽查看到的日志不是最新的。
由于目前容器服務(wù)巨多,日志輸出量巨大,日志收集服務(wù)器不能及時(shí)處理如此多的海量數(shù)據(jù),導(dǎo)致收集的日志寫入ES時(shí),有延時(shí)。
解決辦法
通過“應(yīng)用日志”和“錯(cuò)誤日志”按鈕查看實(shí)時(shí)的日志信息,也可以進(jìn)入到控制臺(tái),通過tail命令查看相應(yīng)的日志文件。
7、應(yīng)用發(fā)布失敗,提示無可用資源
發(fā)現(xiàn)問題
應(yīng)用在構(gòu)建后進(jìn)行發(fā)布操作,結(jié)果失敗,顯示問題為可用資源為0。
根因分析
應(yīng)用通過流水線構(gòu)建成功,最終部署的時(shí)候,提示失敗。查看資源池剩余資源,發(fā)現(xiàn)剩余資源確實(shí)不足。
解決辦法
向資源池中添加新機(jī)器,增加可用的計(jì)算資源。
8、服務(wù)調(diào)用超時(shí),一些環(huán)節(jié)提前關(guān)閉
發(fā)現(xiàn)問題
服務(wù)調(diào)用提示超時(shí),鏈路上某些環(huán)節(jié)提前關(guān)閉了連接。
根因分析
有些服務(wù),導(dǎo)集團(tuán)數(shù)據(jù)時(shí)大約需要5分鐘,由于某些負(fù)載均衡的超時(shí)時(shí)間是30s,導(dǎo)致某個(gè)請(qǐng)求結(jié)束后,不能正常返回處理結(jié)果。
但是,強(qiáng)烈建議將這些長時(shí)間處理的任務(wù),改為異步方式,防止同步調(diào)用造成的超時(shí)等待。
微服務(wù)和Docker容器是一個(gè)完美的結(jié)合,這種模式可以將封裝好的服務(wù),不斷的運(yùn)輸?shù)竭\(yùn)行環(huán)境中。結(jié)合DevOps的理念,可以通過流水線,多套環(huán)境隔離管理等方式,提升研發(fā)的效率。
解決辦法
將各負(fù)載均衡的超時(shí)時(shí)間調(diào)大,SLB、Nginx、HaProxy、MLB等,目前調(diào)整為 Nginx:600s;MLB:180s。