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