熔斷和降級（也叫服務降級），一般是通過組件實現的，而不是spring框架內。比如spring boot框架做增刪改查，外加引入spring cloud框架的hystrix或spring cloud alibaba框架的sentinel做熔斷和降級，當然還可以做限流。

熔斷的本意是，當下對某個api接口發起的服務，錯誤率太高，或者耗時過長請求的比例過高，所以就認為該api接口當下負載過大，應當在之后的一段時間內，讓該api停止對外服務。

和熔斷相關的有如下的參數。

1 時間窗口，比如5秒。

2 最小訪問量，比如100個。

3 錯誤率或者是慢請求的比例下限，比如是50%。

4 熔斷后的等待時間，比如是2秒。

比如有個服務api是對外提供查詢風控信息的，設置了上述熔斷參數，遇到如下情況時會熔斷。

1 時間窗口5秒內，至少收到100個請求。這個是先決條件，比如5秒內只收到99個請求，哪怕這99個請求全都失敗（或返回過慢），也不會熔斷。

2 如果5秒內收到100個請求后，再去看里面失效請求或慢查詢請求的比例，如果高于50%，即該接口熔斷2秒，這個過程中，發到該風控接口的請求全都立即返回失敗。

3 在2秒以后，（hystrix或sentinel等）支持熔斷的組件再去采樣，如果依然是5秒內請求個數大于等于100，并且失敗或慢查詢的比例高于50%，繼續熔斷2秒。否則恢復正常。

為什么要引入熔斷機制呢？因為請求api的線程，是需要耗費內存等資源的，比如請求風控api這個線程，持續了5秒，那么服務器在這5秒以內，就得耗費一定的資源維護這個線程。

對服務器來說，能容納的請求線程個數是有上限的，具體要看服務器的配置，假設是1000個。如果不引入熔斷機制，而并發量又高，一秒會新增1000個訪問風控API接口的線程，那么每個線程都得被維持5秒，而且由于風控接口可能出現故障，不少線程（或者說大多數線程）又拿不到期望結果。這種情況下，與其線程在5秒后因失敗而被終止，那么還不如立即啟動熔斷機制，讓一些線程在發起請求后立即得到錯誤的結果。

否則的話，大量堆積的線程，就會耗盡服務器的內存等資源，甚至可能還耗盡數據庫連接對象，最終導致部署在這臺服務器上的所有服務都不可用。所以，熔斷其實是種保護機制，尤其在高并發場景下，真得預先設置好熔斷策略。

服務降級的本意是，在高并發等場景，一些用戶請求難免會得不到預期的結果，這種情況下，應當針對這些請求快速返回，同時提供一個用戶尚能接受的結果。

比如在某電商網站，有時候去搜索一個商品，期望的結果自然是返回搜索列表，但在某個時刻，正好服務器里并發量太高，或者因為種種原因，搜索商品的請求無法得到期望結果，這種情況下，較好的處理方法是，快速（而不是等待若干時間）返回一個“請稍后再試”的頁面。

如果不引入服務降級，那么用戶真可能會直接看到一個只有資深程序員才能看懂的異常提示，比如哪號內存出問題，或者xx組件的xx行出問題。與其這樣，還不如返回個能讓用戶看得懂的界面。

在一些事件場景，熔斷和服務降級一般是整合一起使用的，比如查詢商品的接口方法出現熔斷，需要等待2秒后再采樣，在這2秒內，hystrix或sentinel等能實現服務降級功能的組件，會把請求抓發到“請稍后再試”的頁面，從而實現服務降級。