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