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