高可用之降級、限流、拒絕服務

Reference：https://time.geekbang.org/column/article/40744

 

高可用建設

系統的⾼可⽤建設，它實際上是⼀個系統⼯程，須要考慮到系統建設的各個階段，也就是說它其實貫穿了系統建設的整個⽣命週期，以下圖所⽰：

具體來講，系統的⾼可⽤建設涉及架構階段、編碼階段、測試階段、發佈階段、運⾏階段，以及故障發⽣時。
1. 架構階段：架構階段主要考慮系統的可擴展性和容錯性，要避免系統出現單點問題。例如多機房單元化部署，即便某個城市的某個機房出現總體故障，仍然不會影響總體⽹站的運轉。
2. 編碼階段：編碼最重要的是保證代碼的健壯性，例如涉及遠程調⽤問題時，要設置合理的超時退出機制，防⽌被其餘系統拖垮，也要對調⽤的返回結果集有預期，防⽌返回的結果超出程序處理範圍，最多見的作法就是對錯誤異常進⾏捕獲，對⽆法預料的錯誤要有默認處理結果。
3. 測試階段：測試主要是保證測試⽤例的覆蓋度，保證最壞狀況發⽣時，咱們也有相應的處理流程。
4. 發佈階段：發佈時也有⼀些地⽅須要注意，由於發佈時最容易出現錯誤，所以要有緊急的回滾機制。
5. 運⾏階段：運⾏時是系統的常態，系統⼤部分時間都會處於運⾏態，運⾏態最重要的是對系統的監控要準確及時，發現問題可以準確報警而且報警數據要準確詳細，以便於排查問題。
6. 故障發⽣：故障發⽣時⾸先最重要的就是及時⽌損，例如因爲程序問題致使商品價格錯誤，那就要及時下架商品或者關閉購買連接，防⽌形成重⼤資產損失。而後就是要可以及時恢復服務，並定位緣由解決問題。

 

降級

所謂「降級」，就是當系統的容量達到⼀定程度時，限制或者關閉系統的某些⾮核⼼功能，從⽽把有限的資源保留給更核⼼的業務。它是⼀個有⽬的、有計劃的執⾏過程，因此對降級⼀般須要有⼀套預案來配合執⾏。若是咱們把它系統化，就能夠經過預案系統和開關係統來實現降級。

降級的核⼼⽬標是犧牲次要的功能和⽤戶體驗來保證核⼼業務流程的穩定，是⼀個不得已⽽爲之的舉措。

 

限流

若是說降級是犧牲了⼀部分次要的功能和⽤戶的體驗效果，那麼限流就是更極端的⼀種保護措施了。限流就是當系統容量達到瓶頸時，須要經過限制⼀部分流量來保護系統，並作到既能夠⼈⼯執⾏開關，也⽀持⾃動化保護的措施。

在限流的實現⼿段上來說，基於QPS和線程數的限流應⽤最多，最⼤QPS很容易經過壓測提早獲取，例如咱們的系統最⾼⽀持1w QPS時，能夠設置8000來進⾏限流保護。線程數限流在客戶端⽐較有效，例如在遠程調⽤時咱們設置鏈接池的線程數，超出這個併發線程請求，就將線程進⾏排隊或者直接超時丟棄。

 

拒絕服務

若是限流還不能解決問題，最後⼀招就是直接拒絕服務了。
當系統負載達到⼀定閾值時，例如CPU使⽤率達到90%或者系統load值達到2*CPU核數時，系統直接拒絕全部請求，這種⽅式是最暴⼒但也最有效的系統保護⽅式。例如秒殺系統，咱們在以下⼏個環節設計過載保護：

• 在最前端的Nginx上設置過載保護，當機器負載達到某個值時直接拒絕HTTP請求並返回503錯誤碼，在Java層一樣也能夠設計過載保護。

拒絕服務能夠說是⼀種不得已的兜底⽅案，⽤以防⽌最壞狀況發⽣，防⽌因把服務器壓跨⽽長時間完全⽆法提供服務。像這種系統過載保護雖然在過載時⽆法提供服務，可是系統仍然能夠運做，當負載降低時又很容易恢復，因此每一個系統和每一個環節都應該設置這個兜底⽅案，對系統作最壞狀況下的保護。