開發高併發系統時有三把利器用來保護系統：快取、降級和限流。本文將詳細聊聊降級。
為什麼需要降級：當訪問量劇增、服務出現問題（如響應時間慢或不響應）或非核心服務影響到核心流程的效能時，仍然需要保證服務還是可用的，即使是有損服務。
降級的最終目：保證核心服務可用，即使是有損的。而且有些服務是無法降級的（如加入購物車、結算）
降級預案
一般：比如有些服務偶爾因為網路抖動或者服務正在上線而超時，可以自動降級；
警告：有些服務在一段時間內成功率有波動（如在95~100%之間），可以自動降級或人工降級，並傳送告警；
錯誤：比如可用率低於90%，或者資料庫連線池被打爆了，或者訪問量突然猛增到系統能承受的最大閥值，此時可以根據情況自動降級或者人工降級；
嚴重錯誤：比如因為特殊原因資料錯誤了，此時需要緊急人工降級。
降級按照是否自動化可分為：自動開關降級和人工開關降級，按照功能可分為：讀服務降級、寫服務降級，按照處於的系統層次可分為：多級降級。
降級的功能點主要從服務端鏈路考慮，即根據使用者訪問的服務呼叫鏈路來梳理**需要降級：
頁面降級：在大促或者某些特殊情況下，某些頁面占用了一些稀缺服務資源，在緊急情況下可以對其整個降級，以達到丟卒保帥；
頁面片段降級：比如商品詳情頁中的商家部分因為資料錯誤了，此時需
要對其進行降級；
服務功能降級：比如渲染商品詳情頁時需要呼叫一些不太重要的服務：相 關分類、熱銷榜等，而這些服務在異常情況下直接不獲取，即降級即可；
讀降級：比如多級快取模式，如果後端服務有問題，可以降級為唯讀快取，這種方式適用於對讀一致性要求不高的場景；
寫降級：比如秒殺搶購，我們可以只進行cache的更新，然後非同步同步扣減庫存到db，保證最終一致性即可，此時可以將db降級為cache。
爬蟲降級：在大促活動時，可以將爬蟲流量導向靜態頁或者返回空資料從而降級保護後端稀缺資源。
自動開關降級：自動降級是根據系統負載、資源使用情況、sla等指標進行降級。
超時降級：當訪問的資料庫/http服務/遠端呼叫響應慢或者長時間響應慢，且該服務不是核心服務的話可以在超時後自動降級；比如商品詳情頁上有推薦內容/評價，但是推薦內容/評價暫時不展示對使用者購物流 程不會產生很大的影響； 對於這種服務是可以超時降級的。如果是呼叫別人的遠端服務，和對方定義乙個服務響應最大時間，如果超時了則自動降級。
統計失敗次數降級：有時候依賴一些不穩定的api，比如呼叫外部機票服務，當失敗呼叫次數達到一定閥值自動降級；然後通過非同步執行緒去探測服務是否恢復了，則取消降級。
故障降級：比如要呼叫的遠端服務掛掉了（網路故障、dns故障、http服務返回錯誤的狀態碼、rpc服務丟擲異常），則可以直接降級。降級後的處理方案有：預設值（比如庫存服務掛了，返回預設現貨）、兜底資料（比如廣告掛了，返回提前準備好的一些靜態頁面）、快取（之前暫存的一些快取資料）。
限流降級：當我們去秒殺或者搶購一些限購商品時，此時可能會因為訪問量太大而導致系統崩潰，此時開發者會使用限流來進行限制訪問量，當達到限流閥值，後續請求會被降級；降級後的處理方案可以是：排隊頁面（將使用者導流到排隊頁面等一會重試）、無貨（直接告知使用者沒貨了）、錯誤頁（如活動太火爆了，稍後重試）。
人工開關降級：在大促期間通過監控發現線上的一些服務存在問題，這個時候需要暫時將這些服務摘掉；還有有時候通過任務系統呼叫一些服務，但是服務依賴的資料庫可能存在：網絡卡被打滿了、掛掉了或者很多慢查詢，此時需要暫停下任務系統讓服務方進行處理；還有發現突然呼叫量太大，可能需要改變處理方式（比如同步轉換為非同步）；此時就可以使用開關來完成降級。
開關可以存放到配置檔案、存放到資料庫、存放到redis/zookeeper；如果不是存放在本地，可以定期同步開關資料（比如1秒同步一次）。然後通過判斷某個key的值來決定是否降級。
另外對於新開發的服務想上線進行灰度測試；但是不太確定該服務的邏輯是否正確，此時就需要設定開關，當新服務有問題可以通過開關切換回老服務。還有多機房服務，如果某個機房掛掉了，
此時需要將乙個機房的服務切到另乙個機房，此時也可以通過開關完成切換。
還有一些是因為功能問題需要暫時遮蔽掉某些功能，比如商品規格引數資料有問題，資料問題不能用回滾解決，此時需要開關控制降級。
讀服務降級：對於讀服務降級一般採用的策略有：暫時切換讀（降級到讀快取、降級到走靜態化）、暫時遮蔽讀（遮蔽讀入口、遮蔽某個讀服務）。在《應用多級快取模式支撐海量讀服務》中曾經介紹過讀服務，
即接入層快取-->應用層本地快取-->分布式快取-->rpc服務/db，我們會在接入層、應用層設定開關，當分布式快取、rpc服務/db有問題自動降級為不呼叫。當然這種情況適用於對讀一致性要求不高的場景。
頁面降級、頁面片段降級、頁面非同步請求降級都是讀服務降級，目的是丟卒保帥（比如因為這些服務也要使用核心資源、或者佔了頻寬影響到核心服務）或者因資料問題暫時遮蔽。
還有一種是頁面靜態化場景：
可以通過乙個程式定期的推送靜態頁到快取或者生成到磁碟，出問題時直接切過去；
靜態化降級為動態化：比如當使用靜態化來實現商品詳情頁架構時，平時使用靜態化來提供服務，但是因為特殊原因靜態化頁面有問題了，需要暫時切換回動態化來保證服務正確性。
以上都保證出問題了有預案，使用者還是可以使用**，不影響使用者購物。
寫服務降級：寫服務在大多數場景下是不可降級的，不過可以通過一些迂迴戰術來解決問題。比如將同步操作轉換為非同步操作，或者限制寫的量/比例。
比如扣減庫存一般這樣操作：
方案1：
1、扣減db庫存
2、扣減成功後更新redis中的庫存
方案2：
1、扣減redis庫存
2、同步扣減db庫存，如果扣減失敗則回滾redis庫存；
前兩種方案非常依賴db，假設此時db效能跟不上則扣減庫存就會遇到問題；
方案3：
1、扣減redis庫存
2、正常同步扣減db庫存，效能扛不住時降級為傳送一條扣減db庫存的訊息，然後非同步進行db庫存扣減實現最終一致即可；
這種方式傳送扣減db庫存訊息也可能成為瓶頸；這種情況我們可以考慮方案4
方案4：
1、扣減redis庫存
2、正常同步扣減db庫存，效能扛不住時降級為寫扣減db庫存訊息到本機，然後本機通過非同步進行db庫存扣減來實現最終一致性。
也就是說正常情況可以同步扣減庫存，在效能扛不住時降級為非同步；另外如果是秒殺場景可以直接降級為非同步，從而保護系統。還有如下單操作可以在大促時暫時降級將下單資料寫入redis，然後等峰值過去了再同步回db，當然也有更好的解決方案，但是更複雜，不是本文的重點。
還有如使用者評價，如果評價量太大，也可以把評價從同步寫降級為非同步寫。當然也可以對評價按鈕進行按比例開放（比如一些人的看不到評價操作按鈕）。比如評價成功後會發一些獎勵，在必要的時候降級同步到非同步。
多級降級：快取是離使用者最近越高效；而降級是離使用者越近越能對系統保護的好。因為業務的複雜性導致越到後端qps/tps越低。
頁面js降級開關：主要控制頁面功能的降級，在頁面中通過js指令碼部署功能降級開關，在適當時機開啟/關閉開關；
接入層降級開關：主要控制請求入口的降級，請求進入後會首先進入接入層，在接入層可以配置功能降級開關，可以根據實際情況進行自動/人工降級；這個可以參考《京東商品詳情頁服務閉環實踐》，尤其在後端應用服務出問題時，通過接入層降級從而給應用服務有足夠的時間恢復服務；
應用層降級開關：主要控制業務的降級，在應用中配置相應的功能開關，根據實際業務情況進行自動/人工降級。
某東《服務降級背後的技術架構設計》ppt內容
犧牲部分使用者體驗
降低安全級別
結算頁前端下單不啟用驗證碼
集中式session不可用，cookie解密即可
ip limit服務，註冊、登入不限制次數
商品修改內容不做敏感詞過濾
犧牲部分業務邏輯
延緩任務處理
損失資料永續性
降低準確性/實時性
降低效能
降低容災能力
服務雪崩解決方案一 服務降級
1 消費者中新增依賴 org.springframework.cloud spring cloud starter netflix hystrix 2 建立配置類config，例項化resttemplate configuration public class consumerconfig 3 服務...
服務熔斷 服務降級
當某個微服務不可用或者響應時間太長時，會進行服務的降級，進而熔斷該節點微服務的呼叫，快速返回錯誤的響應資訊。當檢測到該節點微服務呼叫響應正常後，恢復呼叫鏈路。當伺服器壓力劇增的情況下，根據實際業務情況及流量，對一些服務和頁面有策略的不處理或換種簡單的方式處理，從而釋放伺服器資源以保證核心交易正常運作...
dubbo 服務降級
經歷過12306搶票的人應該經常會遇到這個問題 在搶票高峰的時候，明明票還有，但是查詢出來的列表卻是為空的 如果沒票列表也應該會呈現 等高峰過後再查詢，列表又恢復正常。個人猜測應該是查詢過程中出現了問題，要麼超時，要麼網路問題導致查詢失敗採用的服務降級處理。所以，最終呈現給使用者的並不是內部系統出錯...