本文根據(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ò)誤，或者是長(zhǎng)時(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)測(cè)試環(huán)境時(shí)好時(shí)壞
發(fā)現(xiàn)問題
應(yīng)用聯(lián)調(diào)測(cè)試過程中，調(diào)用時(shí)好時(shí)壞，環(huán)境一天可用時(shí)間難以保證。
根因分析
測(cè)試某個(gè)功能，一會(huì)好用，一會(huì)不好用了。此時(shí)，某些同學(xué)修改了代碼，進(jìn)行了服務(wù)的重啟。導(dǎo)致重啟的過程中，服務(wù)調(diào)用失敗。
由于服務(wù)調(diào)用鏈路比較多而且繁雜，只要其中一個(gè)環(huán)節(jié)不可用，就會(huì)導(dǎo)致整個(gè)功能測(cè)試中斷，讓大家保持步調(diào)一致，以提升環(huán)境穩(wěn)定性。
解決辦法
約定大家的測(cè)試環(huán)境更新時(shí)間，更新（代碼、修改配置、數(shù)據(jù)庫(kù)）的時(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)用接口不通。
根因分析
線上的測(cè)試環(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)用管理詳情頁(yè)面中，點(diǎn)擊日志，發(fā)現(xiàn)日志不顯示，或者顯示有延遲現(xiàn)象
根因分析
在應(yīng)用詳情頁(yè)面中，通過日志頁(yè)簽查看到的日志不是最新的。
由于目前容器服務(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)烈建議將這些長(zhǎ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。
