而且現在很多情況我們還需要呼叫第三方介面例如支付等，因此我們還得考慮如果第三方那邊出問題了，返回異常的慢，我們系統該如何處理。
常見的處理方式有三種：降級、熔斷、限流。
降級
降級也就是服務降級，當我們的伺服器壓力劇增為了保證核心功能的可用性 ，而選擇性的降低一些功能的可用性，或者直接關閉該功能。這就是典型的丟車保帥了。 就比如貼吧型別的網站，當伺服器吃不消的時候，可以選擇把發帖功能關閉，註冊功能關閉，改密碼，改頭像這些都關了，為了確保登入和瀏覽帖子這種核心的功能。
一般而言都會建立一個獨立的降級系統，可以靈活且批量的配置伺服器的降級功能。當然也有用程式碼自動降級的，例如介面超時降級、失敗重試多次降級等。具體失敗幾次，超時設定多久，由你們的業務等其他因素決定。開個小會，定個值，扔線上去看看情況。根據情況再調優。
熔斷
降級一般而言指的是我們自身的系統出現了故障而降級。而熔斷一般是指依賴的外部介面出現故障的情況斷絕和外部介面的關係。
例如你的A服務裡面的一個功能依賴B服務，這時候B服務出問題了，返回的很慢。這種情況可能會因為這麼一個功能而拖慢了A服務裡面的所有功能，因此我們這時候就需要熔斷！即當發現A要呼叫這B時就直接返回錯誤(或者返回其他預設值啊啥的)，就不去請求B了。我這還是舉了兩個服務的呼叫，有些那真的是一環扣一環，出問題不熔斷，那真的是會雪崩。
當然也有人認為熔斷不就是降級的一種的，我覺得你非要說熔斷也屬於一種降級我也沒法反駁，但是它們本質上的突出點和想表達的意思還是有一些不同的。
那什麼時候熔斷合適呢？也就是到達哪個閾值進行熔斷，5分鐘內50%的請求都超過1秒？還是啥？參考降級。
限流
上面說的兩個算是請求過來我們都受理了，這個限流就更狠了，直接跟請求說對不起再見！也就是系統規定了多少承受能力，只允許這麼些請求能過來，其他的請求就說再見了。
一般限制的指標有：請求總量或某段時間內請求總量。
請求總量：比如秒殺的，秒殺100份產品，我就放5000名進來，超過的直接拒絕請求了。
某段時間內請求總量：比如規定了每秒請求的峰值是1W，這一秒內多的請求直接拒絕了。我們們下一秒再見。
如有錯誤歡迎指正！
個人公眾號：yes的練級攻略
有相關面試進階(分散式、效能調優、經典書籍pdf)資料等待領取