服務熔斷
在微服務架構中，微服務之間的數據交互通過遠程調用完成，微服務A調用微服務B和微服務C，微服務B和微服務C又調用其它的微服務，此時如果鏈路上某個微服務的調用響應時間過長或者不可用，那么對微服務A的調用就會占用越來越多的系統資源，進而引起系統崩潰，導致“雪崩效應”。
服務熔斷是應對雪崩效應的一種微服務鏈路保護機制。例如在高壓電路中，如果某個地方的電壓過高，熔斷器就會熔斷，對電路進行保護。同樣，在微服務架構中，熔斷機制也是起着類似的作用。當調用鏈路的某個微服務不可用或者響應時間太長時，會進行服務熔斷，不再有該節點微服務的調用，快速返回錯誤的響應信息。當檢測到該節點微服務調用響應正常后，恢復調用鏈路。
在Spring Cloud框架里，熔斷機制通過Hystrix實現。Hystrix會監控微服務間調用的狀況，當失敗的調用到一定閾值，缺省是5秒內20次調用失敗，就會啟動熔斷機制。
服務熔斷解決如下問題： 1. 當所依賴的對象不穩定時，能夠起到快速失敗的目的；2. 快速失敗后，能夠根據一定的算法動態試探所依賴對象是否恢復。
服務降級
服務降級是指 當服務器壓力劇增的情況下，根據實際業務情況及流量，對一些服務和頁面有策略的不處理或換種簡單的方式處理，從而釋放服務器資源以保證核心業務正常運作或高效運作。說白了，就是盡可能的把系統資源讓給優先級高的服務。
資源有限，而請求是無限的。如果在並發高峰期，不做服務降級處理，一方面肯定會影響整體服務的性能，嚴重的話可能會導致宕機某些重要的服務不可用。所以，一般在高峰期，為了保證核心功能服務的可用性，都要對某些服務降級處理。比如當雙11活動時，把交易無關的服務統統降級，如查看螞蟻深林，查看歷史訂單等等。
服務降級主要用於什么場景呢？當整個微服務架構整體的負載超出了預設的上限閾值或即將到來的流量預計將會超過預設的閾值時，為了保證重要或基本的服務能正常運行，可以將一些 不重要 或 不緊急 的服務或任務進行服務的 延遲使用 或 暫停使用。
降級的方式可以根據業務來，可以延遲服務，比如延遲給用戶增加積分，只是放到一個緩存中，等服務平穩之后再執行 ；或者在粒度范圍內關閉服務，比如關閉相關文章的推薦。
實現服務降級需要考慮幾個問題
1）那些服務是核心服務，哪些服務是非核心服務
2）那些服務可以支持降級，那些服務不能支持降級，降級策略是什么
3）除服務降級之外是否存在更復雜的業務放通場景，策略是什么？
自動降級分類
1）超時降級：主要配置好超時時間和超時重試次數和機制，並使用異步機制探測回復情況
2）失敗次數降級：主要是一些不穩定的api，當失敗調用次數達到一定閥值自動降級，同樣要使用異步機制探測回復情況
3）故障降級：比如要調用的遠程服務掛掉了（網絡故障、DNS故障、http服務返回錯誤的狀態碼、rpc服務拋出異常），則可以直接降級。降級后的處理方案有：默認值（比如庫存服務掛了，返回默認現貨）、兜底數據（比如廣告掛了，返回提前准備好的一些靜態頁面）、緩存（之前暫存的一些緩存數據）
4）限流降級：秒殺或者搶購一些限購商品時，此時可能會因為訪問量太大而導致系統崩潰，此時會使用限流來進行限制訪問量，當達到限流閥值，后續請求會被降級；降級后的處理方案可以是：排隊頁面（將用戶導流到排隊頁面等一會重試）、無貨（直接告知用戶沒貨了）、錯誤頁（如活動太火爆了，稍后重試）。
服務熔斷和服務降級的區別
觸發原因不太一樣，服務熔斷一般是某個服務（下游服務）故障引起，而服務降級一般是從整體負荷考慮；
管理目標的層次不太一樣，熔斷其實是一個框架級的處理，每個微服務都需要（無層級之分），而降級一般需要對業務有層級之分（比如降級一般是從最外圍服務開始）
實現方式不太一樣，服務降級具有代碼侵入性(由控制器完成/或自動降級)，熔斷一般稱為自我熔斷。
限流：限制並發的請求訪問量，超過閾值則拒絕；
降級：服務分優先級，犧牲非核心服務（不可用），保證核心服務穩定；從整體負荷考慮；
熔斷：依賴的下游服務故障觸發熔斷，避免引發本系統崩潰；系統自動執行和恢復