系統設計（系列二）--現上問題整理(雲崩潰和服務不可用)

1、線上問題整理（服務器問題）

昨晚(3月2號)爆出阿里雲宕機，致使華北地區相關使用的公司，其系統和APP沒法正常訪問。第一次強行蹭熱點，勿怪。聯想到我所在公司最近在項目線上所遇到的問題。其實咱們使用的是騰訊雲(阿里雲由其它項目組使用)，騰訊雲去年(2018年，真實)也崩過，一次是網線被挖斷；第二次是咱們的服務在騰訊雲DNS解析失敗。

首先是確認問題，最早表象是系統訪問不了，而後就去排查，因爲咱們是使用免費的HTTPS(有使用期限)，首先看看是否過時了，發現並無，最後到服務器進行ping，發現ping不通，聯繫騰訊雲客服，發現是網線被挖斷了。因爲沒有服務沒有部署到其餘服務器上(自建機房，阿里雲，亞馬遜雲)。那咱們只有等騰訊雲恢復了(須要跟騰訊雲客服確認恢復時間)，期間服務是不能正常運行的。第二次的問題解決思路也是差很少。

首先整理一下解決思路：

排查本身服務的問題(網絡等問題)；2.聯繫雲客服(主要確認恢復時間等)。

多談一點，其實上面的都不是最好的解決方案，由於網線被挖斷，只是一個地區的服務不能使用，若是項目那個時候是顧客高峯期，停一個小時損失也是很大的。不能叫顧客等半個小時或一個小時以上。其實個人思路是在雲服務上當即購買其餘地區的，至少能恢復服務，可是部署時間要和恢復時間進行對比一下。

第二個問題就是服務恢復以後的問題，查看數據是否一致，這個很重要。好比有部分剛恰好在支付階段鏈接不上，這個怎麼處理？有的過30分鐘以後會自動取消訂單，因爲服務沒法正常運行，定時任務也沒法正常運行了。咱們的解決思路是：1.查詢數據，確認數據是否異常；2.跟業務確認，這筆業務怎麼處理，是執行腳本(手動執行定時任務)繼續執行下去，仍是標記失效。

推薦一篇文章：架構師之路的，這篇更加的完善。https://mp.weixin.qq.com/s/Svrks178L03QM2KvwSnL2w

2、線上問題整理（服務不能訪問問題）

第一個是服務器崩潰的問題(騰訊雲，阿里雲崩了)，第二個問題是服務鏈接不上(最後查出來的問題：鏈接超時)。這個反映了哪些問題？

最表象的問題是訂單保存不了，而且是大面積的。項目羣已經炸了，都是這個問題截圖。一開始覺得是服務崩了，發現並非，覺得其餘功能是能夠正常服務的(服務是按照功能劃分的)，因此不是服務崩潰了。保存不了訂單覺得一直抱校驗失敗，覺得是JS的問題，覺得JS也有部分校驗功能，立馬打電話通知前端，是不是JS的問題。發現不是，最後看服務器的日誌，發現是一個第三方服務鏈接超時(數據庫)。心裏是崩潰的，找問題找了好久（報錯是咱們數據庫鏈接失敗，可是咱們數據庫在客戶端是能夠進行使用和查詢的）。解決的方式：通知不要進行操做了，此時持續操做將致使數據庫阻塞的更加嚴重。同時立馬重啓一下數據庫服務(docker搭建的，很快)。可是發現仍是會出現老問題，由於咱們不能把握第三方服務器資源，同時不是咱們這邊服務(數據庫)的問題。最後聯繫第三方，重啓他們那邊的服務，把以前阻塞的線程清空。

因爲是報錯的本象是咱們數據庫事務建立失敗(最後發現是第三方服務鏈接超時問題)。首先根據報錯，爲何事務建立失敗，查看代碼並無(update/insert等操做)，只有查詢操做，最後發現是查詢也開啓了事務，同時請求第三方很慢很慢。致使事務一直沒有釋放，因爲那個時期又是高峯期，致使一直阻塞，最後超過最大數，事務建立失敗。

反映的問題總結一下：1.不能當即定位問題出如今哪裏？2.報警系統失效(咱們是發送郵件)。3.爲何第三方服務鏈接超時致使服務失敗(容錯機制不行)。4.還有就是服務(數據庫)沒有作到高可用，沒有作成集羣。5.代碼寫的不規範(查詢也開啓事務)。

繁榮Aaron

沒時間解釋了，快長按左邊二維碼關注咱們～～