用通俗的話講講熔斷和服務(wù)降級
熔斷和降級(也叫服務(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ù)降級。