降級是系統保護的重要手段，保證系統的高可用，簡單理解，降級就是丟車保帥，在系統壓力極大時，暫時不做非必要動作，以保證系統核心功能的正常。
例如電商系統中，購物車、結算這類的核心功能就是保護物件，是絕對不能降級的，而像個性化自動商品推薦服務就可以暫時不提供。
降級策略有很多種，可以從下面3個維度分為5種策略：
自動化維度
包括：自動開關降級、人工開關降級。
功能維度
包括：讀服務降級、寫服務降級。
系統層次維度
包括：多級降級。
1. 自動開關降級
系統在執行時根據執行狀態自動觸發降級，例如：
呼叫遠端非核心服務時，響應過慢後自動降級，先不調了。
需要配置好超時時間和超時重試次數。
有的服務可能不太穩定，例如外部的機票服務，當呼叫失敗次數超過容忍度後就自動降級。可以通過非同步執行緒去探測服務是否恢復了，可用後自動取消降級。
比如遠端服務掛掉了，就自動降級，可以使用預設值、提前準備的內容、之前的快取資料。
例如秒殺系統，通常會使用限流機制進行保護，當達到限流閾值時，後續請求就自動被降級，例如將使用者導流到排隊頁面過會兒重試、直接告訴使用者沒貨了。
2. 手動開關降級
自動降級是根據系統出現的一些問題進行響應，但在系統還沒有出現問題時，我就想降級某些服務，比如**馬上開始了，可以預知訪問量很大，我們提前就把推薦服務關掉；再比如新功能想上線進行灰度測試，當新功能不符合預期時我想馬上切換回老服務。
這類需求就需要使用可以人工控制的開關來實現。
開關可以存放到配置檔案、資料庫、redis/zookeeper等位置，定期同步開關資料。
分布式系統中通常會建立乙個配置中心，對整個系統中的配置開關進行集中管理，提供 web ui 介面進行便捷操作。目前有一些開源方案可以選擇，例如 zookeeper、diamond、etcd 3、consul。
3. 讀服務降級
從讀取資料 的角度考慮降級，例如商品詳情頁，其中有非常多的內容，比如商家資訊、推薦資訊、配送至資訊、相關分類、熱銷榜等等，這些都不是核心資料，所以在出現異常時可以進行降級處理。
還以商品詳情頁為例，在**活動之前，可以將整個頁面切換為靜態化，最大程度的降級讀服務。
4. 寫服務降級
寫服務都是很關鍵的，降級思路基本就是同步寫轉非同步寫。
例如扣減庫存的操作，正常情況下的設計一般是：
方案1：資料庫中扣減，成功後更新 redis 快取。
方案2：先扣減 redis 快取，同步扣減資料庫，如果失敗則回滾 redis 快取。
當資料庫效能跟不上時，就需要採用非同步方式了：
先扣減 redis 快取，同時向佇列中傳送一條扣減資料庫庫存的訊息，非同步進行資料庫扣減，實現最終一致性。
再比如使用者評價，如果量太大，就可以把評價從同步寫轉為非同步寫，還有評價後會給一些獎勵，也可以非同步。
5. 多級降級
從距離使用者遠近的角度，可以分為以下3個層面：
頁面js降級開關
主要控制頁面功能的降級，在頁面中通過js指令碼部署來控制在適當時機開啟/關閉開關。
接入層降級開關
在請求入口進行控制，請求進入後，會首先進入接入層，例如 nginx，在其中根據實際情況進行自動/人工降級。
接入層的控制功能是很強大的，可以實現秒級切換、增量式切換（按照機器組開啟）、細粒度服務開關、超時自動降級。
應用層降級開關
在應用中配置相應的功能開關，根據實際情況進行自動/人工降級。
微服務架構 服務降級
什麼是服務降級？當伺服器壓力劇增的情況下，根據實際業務情況及流量，對一些服務和頁面有策略的不處理或換種簡單的方式處理，從而釋放伺服器資源以保證核心交易正常運作或高效運作。服務降級主要用於什麼場景呢？當整個微服務架構整體的負載超出了預設的上限閾值或即將到來的流量預計將會超過預設的閾值時，為了保證重要或...
Dubbo之服務降級
dubbo之服務降級 1.可以通過dubbo控制台 遮蔽 不在呼叫遠端介面，在本地直接返回null 容錯 當呼叫遠端介面失敗的時候，返回null值，不拋異常 2.也可以通過配置中心向註冊中心寫入動態配置 官方示例 registryfactory registryfactory extensionlo...
億級流量架構之服務降級思路與方法
如果看過我前面對服務限流的分析,理解服務降級就很容易了,對於乙個景區,平時隨便進出,但是一到春節或者十一國慶這種情況客流量激增,那麼景區會限制同時進去的人數,這叫限流,那麼什麼是服務降級呢?簡單來說就是,將一些不太重要的景區專案砍掉,平時就那麼三五八個人,景區可以開放湖中游泳啦,摸魚啦,捉蝦啦,有情...