熔斷和降級（也叫服務(wù)降級），一般是通過組件實(shí)現(xiàn)的，而不是spring框架內(nèi)。比如spring boot框架做增刪改查，外加引入spring cloud框架的hystrix或spring cloud alibaba框架的sentinel做熔斷和降級，當(dāng)然還可以做限流。

熔斷的本意是，當(dāng)下對某個(gè)api接口發(fā)起的服務(wù)，錯(cuò)誤率太高，或者耗時(shí)過長請求的比例過高，所以就認(rèn)為該api接口當(dāng)下負(fù)載過大，應(yīng)當(dāng)在之后的一段時(shí)間內(nèi)，讓該api停止對外服務(wù)。

和熔斷相關(guān)的有如下的參數(shù)。

1 時(shí)間窗口，比如5秒。

2 最小訪問量，比如100個(gè)。

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

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

比如有個(gè)服務(wù)api是對外提供查詢風(fēng)控信息的，設(shè)置了上述熔斷參數(shù)，遇到如下情況時(shí)會熔斷。

1 時(shí)間窗口5秒內(nèi)，至少收到100個(gè)請求。這個(gè)是先決條件，比如5秒內(nèi)只收到99個(gè)請求，哪怕這99個(gè)請求全都失?。ɑ蚍祷剡^慢），也不會熔斷。

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

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

為什么要引入熔斷機(jī)制呢？因?yàn)檎埱骯pi的線程，是需要耗費(fèi)內(nèi)存等資源的，比如請求風(fēng)控api這個(gè)線程，持續(xù)了5秒，那么服務(wù)器在這5秒以內(nèi)，就得耗費(fèi)一定的資源維護(hù)這個(gè)線程。

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

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

服務(wù)降級的本意是，在高并發(fā)等場景，一些用戶請求難免會得不到預(yù)期的結(jié)果，這種情況下，應(yīng)當(dāng)針對這些請求快速返回，同時(shí)提供一個(gè)用戶尚能接受的結(jié)果。

比如在某電商網(wǎng)站，有時(shí)候去搜索一個(gè)商品，期望的結(jié)果自然是返回搜索列表，但在某個(gè)時(shí)刻，正好服務(wù)器里并發(fā)量太高，或者因?yàn)榉N種原因，搜索商品的請求無法得到期望結(jié)果，這種情況下，較好的處理方法是，快速（而不是等待若干時(shí)間）返回一個(gè)“請稍后再試”的頁面。

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

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