問題來源
2020年5月3日星期天。晚上7點39分，正是結賬的高峰期，然而就是在這個時候系統崩潰了。牽扯到錢的事沒一件事小事，可以定性此為重大事故。
造成的後果：
有人必須要背鍋了，先恢複再找問題源頭，再找誰的問題（這種鍋絕大多數是開發的問題）。
問題處理
常見思路：復原、重新開機大法！！！ 先恢複再查原因
f12 通路看問題到底在哪裡?
502服務端錯誤，可以肯定與代碼健壯性有關。
重新開機復原能解決百分之80的問題，但這裡的路徑多了一個/，路由是不是有問題，看日志，或看相關服務的連接配接。nginx就做了一個反向代理，我覺得還是跟請求的代碼有關，讓他們抓包看看流量到哪了，先看看解析有沒有問題，然後直接用ip能不能到ng，解析沒問題的話，确定一下域名通路能到ng不，後端直接在ng上用curl測試下正常不，代碼問題直接復原，不二話，域名問題看看是不是被劫持了。
GC了，....網關，開發自己寫的...
其實最開始出現問題，後面會出現有的可以通路，有的不行，我們的gatway是設定彈性伸縮的，剛才确實伸縮了，但是有些流量還是轉到了舊的pod上，因為GC了，是以不能通路gatway。
OOM是不會影響端口 端口隻有是否被開放 或者服務是否正确啟動才會有端口的問題，OOM是記憶體的問題和你服務端口無關，Pod中查詢OOM的問題：java應用出現記憶體溢出老正常了。最好加上監控（監控Pod的IO之類的），重新開機也行，加入注冊中心，服務不可用 剔除。
善後工作
- 監控日志，報警出來
-
做探針？
探針沒用，因為服務端口都在，pod狀态也是running。是以就是要api，檢測可用性的api。端口不能代表可用性，應該讓開發在網關加一個健康檢查端口。通過curl 健康檢查端口判斷業務是否正常
-
prestop
鈎子，有問題，就殺掉，然後剔除注冊中心，滾動更新的時候加上prestop，然後通過curl 注冊中心，将這個pod強制下線
由java程式引起的一次系統崩潰 具體參數得問開發
越是重大問題你處理了，越是展現價值，處理好了，應該的，處理不好，背鍋。真現實。
過手如登山，一步一重天