高并發系統之降級特技

2019獨角獸企業重金招聘Python工程師標準>>>

高并發系統之降級特技博客分類：架構

在開發高并發系統時有三把利器用來保護系統：緩存、降級和限流。之前已經有一些文章介紹過緩存和限流了。本文將詳細聊聊降級。當訪問量劇增、服務出現問題（如響應時間慢或不響應）或非核心服務影響到核心流程的性能時，仍然需要保證服務還是可用的，即使是有損服務。系統可以根據一些關鍵數據進行自動降級，也可以配置開關實現人工降級。本文將介紹一些筆者在實際工作中遇到的或見到過的一些降級方案供大家參考。

降級的最終目的是保證核心服務可用，即使是有損的。而且有些服務是無法降級的（如加入購物車、結算）。

降級預案

在進行降級之前要對系統進行梳理，看看系統是不是可以丟卒保帥；從而梳理出哪些必須誓死保護，哪些可降級；比如可以參考日志級別設置預案：

一般：比如有些服務偶爾因為網絡抖動或者服務正在上線而超時，可以自動降級；

警告：有些服務在一段時間內成功率有波動（如在95~100%之間），可以自動降級或人工降級，并發送告警；

錯誤：比如可用率低于90%，或者數據庫連接池被打爆了，或者訪問量突然猛增到系統能承受的最大閥值，此時可以根據情況自動降級或者人工降級；

嚴重錯誤：比如因為特殊原因數據錯誤了，此時需要緊急人工降級。

降級按照是否自動化可分為：自動開關降級和人工開關降級。

降級按照功能可分為：讀服務降級、寫服務降級。

降級按照處于的系統層次可分為：多級降級。

降級的功能點主要從服務端鏈路考慮，即根據用戶訪問的服務調用鏈路來梳理哪里需要降級：

頁面降級：在大促或者某些特殊情況下，某些頁面占用了一些稀缺服務資源，在緊急情況下可以對其整個降級，以達到丟卒保帥；

頁面片段降級：比如商品詳情頁中的商家部分因為數據錯誤了，此時需要對其進行降級；

頁面異步請求降級：比如商品詳情頁上有推薦信息/配送至等異步加載的請求，如果這些信息響應慢或者后端服務有問題，可以進行降級；

服務功能降級：比如渲染商品詳情頁時需要調用一些不太重要的服務：相關分類、熱銷榜等，而這些服務在異常情況下直接不獲取，即降級即可；

讀降級：比如多級緩存模式，如果后端服務有問題，可以降級為只讀緩存，這種方式適用于對讀一致性要求不高的場景；

寫降級：比如秒殺搶購，我們可以只進行Cache的更新，然后異步同步扣減庫存到DB，保證最終一致性即可，此時可以將DB降級為Cache。

爬蟲降級：在大促活動時，可以將爬蟲流量導向靜態頁或者返回空數據從而降級保護后端稀缺資源。

自動開關降級

自動降級是根據系統負載、資源使用情況、SLA等指標進行降級。

超時降級

當訪問的數據庫/http服務/遠程調用響應慢或者長時間響應慢，且該服務不是核心服務的話可以在超時后自動降級；比如商品詳情頁上有推薦內容/評價，但是推薦內容/評價暫時不展示對用戶購物流程不會產生很大的影響；對于這種服務是可以超時降級的。如果是調用別人的遠程服務，和對方定義一個服務響應最大時間，如果超時了則自動降級。

之前總結過一些的文章《使用httpclient必須知道的參數設置及代碼寫法、存在的風險》和《dbcp配置及jdbc超時設置總結》。在實際場景用一定主要配置好超時時間和超時重試次數和機制。

統計失敗次數降級

有時候依賴一些不穩定的API，比如調用外部機票服務，當失敗調用次數達到一定閥值自動降級；然后通過異步線程去探測服務是否恢復了，則取消降級。

故障降級

比如要調用的遠程服務掛掉了（網絡故障、DNS故障、http服務返回錯誤的狀態碼、rpc服務拋出異常），則可以直接降級。降級后的處理方案有：默認值（比如庫存服務掛了，返回默認現貨）、兜底數據（比如廣告掛了，返回提前準備好的一些靜態頁面）、緩存（之前暫存的一些緩存數據）。

限流降級

當我們去秒殺或者搶購一些限購商品時，此時可能會因為訪問量太大而導致系統崩潰，此時開發者會使用限流來進行限制訪問量，當達到限流閥值，后續請求會被降級；降級后的處理方案可以是：排隊頁面（將用戶導流到排隊頁面等一會重試）、無貨（直接告知用戶沒貨了）、錯誤頁（如活動太火爆了，稍后重試）。

人工開關降級

在大促期間通過監控發現線上的一些服務存在問題，這個時候需要暫時將這些服務摘掉；還有有時候通過任務系統調用一些服務，但是服務依賴的數據庫可能存在：網卡被打滿了、掛掉了或者很多慢查詢，此時需要暫停下任務系統讓服務方進行處理；還有發現突然調用量太大，可能需要改變處理方式（比如同步轉換為異步）；此時就可以使用開關來完成降級。開關可以存放到配置文件、存放到數據庫、存放到Redis/ZooKeeper；如果不是存放在本地，可以定期同步開關數據（比如1秒同步一次）。然后通過判斷某個KEY的值來決定是否降級。

另外對于新開發的服務想上線進行灰度測試；但是不太確定該服務的邏輯是否正確，此時就需要設置開關，當新服務有問題可以通過開關切換回老服務。還有多機房服務，如果某個機房掛掉了，此時需要將一個機房的服務切到另一個機房，此時也可以通過開關完成切換。

還有一些是因為功能問題需要暫時屏蔽掉某些功能，比如商品規格參數數據有問題，數據問題不能用回滾解決，此時需要開關控制降級。

讀服務降級

對于讀服務降級一般采用的策略有：暫時切換讀（降級到讀緩存、降級到走靜態化）、暫時屏蔽讀（屏蔽讀入口、屏蔽某個讀服務）。在《應用多級緩存模式支撐海量讀服務》中曾經介紹過讀服務，即接入層緩存-->應用層本地緩存-->分布式緩存-->RPC服務/DB，我們會在接入層、應用層設置開關，當分布式緩存、RPC服務/DB有問題自動降級為不調用。當然這種情況適用于對讀一致性要求不高的場景。

頁面降級、頁面片段降級、頁面異步請求降級都是讀服務降級，目的是丟卒保帥（比如因為這些服務也要使用核心資源、或者占了帶寬影響到核心服務）或者因數據問題暫時屏蔽。

還有一種是頁面靜態化場景：

動態化降級為靜態化：比如平時網站可以走動態化渲染商品詳情頁，但是到了大促來臨之際可以將其切換為靜態化來減少對核心資源的占用，而且可以提升性能；其他還有如列表頁、首頁、頻道頁都可以這么玩；可以通過一個程序定期的推送靜態頁到緩存或者生成到磁盤，出問題時直接切過去；

靜態化降級為動態化：比如當使用靜態化來實現商品詳情頁架構時，平時使用靜態化來提供服務，但是因為特殊原因靜態化頁面有問題了，需要暫時切換回動態化來保證服務正確性。

以上都保證出問題了有預案，用戶還是可以使用網站，不影響用戶購物。