業務高峰期，為了保證核心服務，需要停掉一些不太重要的業務，eg 商品評論、論壇或者粉絲積分等

另外一些場景就是某些服務不可用時，又不能直接讓整個流程失敗就本地Mcok(模擬)實現，做流程放通

eg 使用者登入餘額鑑權服務不能正常工作，需要做業務放通，記錄消費話單允許使用者繼續訪問，而不是返回失敗

為了保證以上兩種場景的正常服務，服務需要有降級

服務降級主要包括容錯降級和遮蔽降級

遮蔽降級：1）throw null 不發起遠端呼叫，直接返回空

         2）throw exception 不發起遠端呼叫，直接丟擲指定異常

         3）execute bean 不發起遠端呼叫，直接執行本地模擬介面實現

服務降級是可逆操作，當系統壓力恢復到一定值不需要降級服務時，要重新發起遠端呼叫，服務狀態改為正常

容錯降級：非核心服務不可呼叫時，可以對故障服務做業務放通，保證主流程不受影響

1）RPC異常：通常指超時、訊息解碼異常、流控異常、系統擁塞保護異常等

2）Service異常 eg登入校驗異常、資料庫操作失敗異常等

容錯降級和遮蔽降級的區別在於：

1）觸發條件不同：遮蔽降級往往是人工根據系統的執行，手動設定

                容錯降級是根據服務呼叫返回的結果，結合當前的服務級別，自動匹配觸發

2）作用不同：容錯降級是服務不可用時，讓消費者執行業務放通

            遮蔽降級主要目的是將原屬於降級業務的資源調配出來供核心業務使用

3）呼叫機制不同，一個發起遠端服務呼叫，一個只做本地呼叫

執行業務放通的Mock介面往往放在消費者端

1）執行業務放通時可能會依賴本地的資源，包括但不限於消費者依賴的服務、資料結構、資料庫等資源，這些事消費者私有的，服務提供者不可見，若放到服務提供者，會造成資源依賴，導致系統耦合

2）不同的消費者消費同一個服務時，對失敗之後的處理策略存在差異，若都搬到服務提供者的Mock介面，會造成程式碼臃腫，難以維護

服務降級的優先順序是  消費者配置策略>服務提供者配置策略

遮蔽降級高於容錯降級

實現服務降級需要考慮幾個問題

1）那些服務是核心服務，哪些服務是非核心服務

2）那些服務可以支援降級，那些服務不能支援降級，降級策略是什麼

3）除服務降級之外是否存在更復雜的業務放通場景，策略是什麼？