20140613故障處理紀要

背景：約100萬月活躍使用者，APP版本BUG（至少4萬使用者死逐一查看，堪比DDOS）,修複曆時7天7夜。


世界盃前夕，伺服器拒絕訪問，線程掛死，導致大量請求拒絕訪問，少量能訪問，但訪問時間緩慢導致逾時，相當於服務崩潰。


通過監聽連接埠有效訪問串連數，最高可達1000並發。
netstat -an | grep ESTABLISHED | wc -l 


訪問量已經是無法控制，只能從應用入手，強制更新有bug的APP版本，把有BUG的版本的所有介面全部拒絕訪問，以免影響其他版本的訪問，但效果甚微。


我懷疑此時的並發量已經遠遠超出現有伺服器的壓力，如果並發量超出伺服器的承受範圍，那無論如何最佳化代碼都是無事於補。為了驗證伺服器的極限，把所有介面都屏蔽（改成立刻響應，幾乎不消耗太多的資源），經過測試發現，每開啟入口，線程池立刻滿上，無論如何調大入口數，最大串連數，系統檔案最大開啟數（Linux ulimit）等參數，到達某一瓶頸值就立刻線程掛死，拒絕訪問，此時系統資源如CPU、記憶體、IO等係數都消耗不大，由此推斷我們web容器已經到達了瓶頸。


現在只剩下一個方案：擴容。擴容有兩種方式，垂直擴容，橫向擴容。垂直擴容相對需要時間有點長，需要安裝節點，添加節點等操作，還需要測試，還會存在多種不確定風險，畢竟對現網伺服器動手腳。橫向擴容是最佳方案，因為有現成的叢集伺服器可以用（另外項目已經停止，伺服器空閑），可以通過現網伺服器叢集的上一層做分流（F5），把一半的流量分過來新叢集。於是我們重新部署了應用到新叢集伺服器。開啟分流入口，系統業務恢複，訪問正常。


好景不長，大概運行了半天時間，發現web容器線程忽然飆升到某一瓶頸值大部分掛死，拒絕訪問。我又開始懷疑難道擴容都還不能支援現在的壓力，經過了強制更新和舊介面的拒絕訪問，效能消耗應該有所下降了。但發現有一個奇怪的問題，線程一開始是正常的，就是運行到某一個時間段是忽然慢慢上升，直到瓶頸值掛死，我開始懷疑應用同樣存在瓶頸，開始向代碼入手。由於曆史原因，查看代碼也是一件要命的事情，在這裡消耗還不如查看作業記錄，但同樣是曆史遺留問題，日誌的錯誤一大堆，之前是因為不影響業務運行就不管，因為以前系統從tomcat遷移到was的，tomcat的相容性好，沒有什麼錯誤，但是遷移到was後就報出一大堆問題，可能是was的要求比較高，但是後來沒人改修改，不影響現網運行就不理。所以現在從日誌入手也是一件很痛苦的事情，但這是沒辦法中的辦法。把一個10M的日誌文檔拿下來，一個個錯誤排除。功夫不負有心人。終於讓我發現了點苗頭。發現了線程掛死的介面，後來經過了代碼的排查，終於找到問題所在，是因為這個介面用到了synchronized，難怪線程會掛死，之前不會發生死結的原因訪問量不大，現在訪問量通過推廣和那個致命的BUG，不掛死才怪。


後來經過了代碼的修改和完善，把所有有用到了同步的都修改了，重啟應用開啟。應用訪問正常、線程正常、但是資料量CPU消耗有點大。通過對資料庫的排查，發現，是應用的商務邏輯很多沒有梳理好，SQL的許多的硬解析導致了資料庫CPU消耗比較高，但這是曆史遺留問題，現在一個個是非常不現實的，我們只能對消耗較高的SQL進行完善。


經過幾天的系統運行，相對穩定，就是資料庫CPU消耗時高時地，這個應用的推廣活動有關，但還不至於導致伺服器倒閉或掛死。


系統穩定後對現網的所有日誌等資料進行分析，發現我們APP的使用者數增長比較快。如果安裝現在的增長速度，必須還的提前申請伺服器擴容（系統客戶可以重視和給力）。


現網的系統架構是當初以一個“公司專屬應用程式”建立的，還包括了許多曆史遺留問題，只能說too young too simple。


現在已經是百萬級使用者的APP了，看來，架構需要重新設計和規划了。其實萬事具備，只欠東風（客戶的重視度）。我只能說，系統≠軟體+硬體，系統=軟體+硬體+溝通+企業政策+任何關聯因素。