由于爆炸性的流量沖擊，對一些服務進行有策略的放棄，以此緩解系統壓力，保證目前主要業務的正常運行。它主要是針對非正常情況下的應急服務措施：當此時一些業務服務無法執行時，給出一個統一的返回結果。

　　1、降級服務的特征

　　原因：整體負荷超出整體負載承受能力。

　　目的：保證重要或基本服務正常運行，非重要服務延遲使用或暫停使用。

　　大小：降低服務粒度，要考慮整體模塊粒度的大小，將粒度控制在合適的范圍內。

　　可控性：在服務粒度大小的基礎上增加服務的可控性，后臺服務開關的功能是一項必要配置(單機可配置文件，其他可領用數據庫和緩存)，可分為手動控制和自動控制。

　　次序：一般從外圍延伸服務開始降級，需要有一定的配置項，重要性低的優先降級，比如可以分組設置等級1-10，當服務需要降級到某一個級別時，進行相關配置。

　　2、降級方式

　　延遲服務：比如發表了評論，重要服務，比如在文章中顯示正常，但是延遲給用戶增加積分，只是放到一個緩存中，等服務平穩之后再執行。

　　在粒度范圍內關閉服務(片段降級或服務功能降級)：比如關閉相關文章的推薦，直接關閉推薦區。

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

　　頁面跳轉(頁面降級)：比如可以有相關文章推薦，但是更多的頁面則直接跳轉到某一個地址。

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

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

　　3、降級預案

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

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

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

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

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

　　4、服務降級分類

　　降級按照是否自動化可分為：自動開關降級(超時、失敗次數、故障、限流)和人工開關降級(秒殺、電商大促等)。

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

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

　　5、自動降級分類

　　超時降級：主要配置好超時時間和超時重試次數和機制，并使用異步機制探測回復情況。

　　失敗次數降級：主要是一些不穩定的api，當失敗調用次數達到一定閥值自動降級，同樣要使用異步機制探測回復情況。

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

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