服務降級
服務壓力劇增的時候根據當前的業務情況及流量對一些服務和頁面有策略的降級，以此緩解服務器的壓力，以
保證核心任務的進行。同時保證部分甚至大部分任務客戶能得到正確的響應。也就是當前的請求處理不了了或者出錯了，給一個默認的返回。
服務熔斷
在股票市場，熔斷這個詞大家都不陌生，是指當股指波幅達到某個點后，交易所為控制風險采取的暫停交易措施。相應的，服務熔斷一般是指軟件系統中，由於某些原因使得服務出現了過載現象，為防止造成整個系統故障，從而采用的一種保護措施，所以很多地方把熔斷亦稱為
過載保護。
降級分類
降級按照
是否自動化可分為：
自動開關降級和
人工開關降級。
降級按照
功能可分為：
讀服務降級、
寫服務降級。
降級按照處於的
系統層次可分為：
多級降級。
自動降級分類
（1）超時降級：主要配置好超時時間和超時重試次數和機制，並使用異步機制探測回復情況
（2）失敗次數降級：主要是一些不穩定的api，當失敗調用次數達到一定閥值自動降級，同樣要使用異步機制探測回復情況
（3）故障降級：比如要調用的遠程服務掛掉了（網絡故障、DNS故障、http服務返回錯誤的狀態碼、rpc服務拋出異常），則可以直接降級。降級后的處理方案有：默認值（比如庫存服務掛了，返回默認現貨）、兜底數據（比如廣告掛了，返回提前准備好的一些靜態頁面）、緩存（之前暫存的一些緩存數據）
（4）限流降級
當我們去秒殺或者搶購一些限購商品時，此時可能會因為訪問量太大而導致系統崩潰，此時開發者會使用限流來進行限制訪問量，當達到限流閥值，后續請求會被降級；降級后的處理方案可以是：排隊頁面（將用戶導流到排隊頁面等一會重試）、無貨（直接告知用戶沒貨了）、錯誤頁（如活動太火爆了，稍后重試）。
服務熔斷和服務降級比較
兩者其實從有些角度看是有一定的類似性的：
- 目的很一致，都是從可用性可靠性着想，為防止系統的整體緩慢甚至崩潰，采用的技術手段；
- 最終表現類似，對於兩者來說，最終讓用戶體驗到的是某些功能暫時不可達或不可用；
- 粒度一般都是服務級別，當然，業界也有不少更細粒度的做法，比如做到數據持久層（允許查詢，不允許增刪改）；
- 自治性要求很高，熔斷模式一般都是服務基於策略的自動觸發，降級雖說可人工干預，但在微服務架構下，完全靠人顯然不可能，開關預置、配置中心都是必要手段；
而兩者的區別也是明顯的：
- 觸發原因不太一樣，服務熔斷一般是某個服務（下游服務）故障引起，而服務降級一般是從整體負荷考慮；
- 管理目標的層次不太一樣，熔斷其實是一個框架級的處理，每個微服務都需要（無層級之分），而降級一般需要對業務有層級之分（比如降級一般是從最外圍服務開始）
- 實現方式不太一樣
服務降級要考慮的問題
1.核心和非核心服務
2.是否支持降級，降級策略
3.業務放通的場景，策略
Hystrix
Hystrix，該庫旨在通過控制那些訪問遠程系統、服務和第三方庫的節點，從而對延遲和故障提供更強大的容錯能力。Hystrix具備擁有回退機制和斷路器功能的線程和信號隔離，請求緩存和請求打包（request collapsing，即自動批處理，譯者注），以及監控和配置等功能。
Hystrix能做什么？
- 在通過第三方客戶端訪問（通常是通過網絡）依賴服務出現高延遲或者失敗時，為系統提供保護和控制
- 在分布式系統中防止級聯失敗
- 快速失敗（Fail fast）同時能快速恢復
- 提供失敗回退（Fallback）和優雅的服務降級機制
- 提供近實時的監控、報警和運維控制手段
Hystrix設計原則？
- 防止單個依賴耗盡容器（例如 Tomcat）內所有用戶線程
- 降低系統負載，對無法及時處理的請求快速失敗（fail fast）而不是排隊
- 提供失敗回退，以在必要時讓失效對用戶透明化
- 使用隔離機制（例如『艙壁』/『泳道』模式，熔斷器模式等）降低依賴服務對整個系統的影響
- 針對系統服務的度量、監控和報警，提供優化以滿足近實時性的要求
- 在 Hystrix 絕大部分需要動態調整配置並快速部署到所有應用方面，提供優化以滿足快速恢復的要求
- 能保護應用不受依賴服務的整個執行過程中失敗的影響，而不僅僅是網絡請求
Hystrix怎樣實現目標？
- 在一個單獨的線程中通過 HystrixCommand 或 HystrixObservableCommand 對象包裝所有外部系統（或依賴）的調用。
- 調用超時比設置的閾值更長。雖然有默認值，但是大多數依賴自己配置的這些超時“屬性”，所以每個依賴都略高於實測性能的99.5%。
- 為每個依賴保持一個小的線程池；如果線程池滿了，新來的請求會立即拒絕掉，而不是排隊等候。
- 測試成功、失敗（客戶端拋出異常）、超時和線程拒絕。
- 當請求失敗、被拒、超時或者短路時的性能反饋邏輯。
- 准實時的監控指標和配置改變。
開發文檔