在實(shí)際業(yè)務(wù)運(yùn)行過(guò)程中，有一種故障影響可能沒(méi)有那么大，但發(fā)生的概率較高，這就是今天聊的接口級(jí)的故障。

接口級(jí)故障的典型表現(xiàn)就是，系統(tǒng)并沒(méi)有宕機(jī)、網(wǎng)絡(luò)也沒(méi)有中斷，但業(yè)務(wù)卻出現(xiàn)問(wèn)題了，例如業(yè)務(wù)響應(yīng)緩慢、大量訪問(wèn)超時(shí)和大量訪問(wèn)出現(xiàn)異常（給用戶彈出提示“無(wú)法連接數(shù)據(jù)庫(kù)”）。

這類問(wèn)題的主要原因在于系統(tǒng)壓力太大、負(fù)載太高，導(dǎo)致無(wú)法快速處理業(yè)務(wù)請(qǐng)求，由此引發(fā)更多的后續(xù)問(wèn)題。最常見(jiàn)的情況就是，數(shù)據(jù)庫(kù)慢查詢將數(shù)據(jù)庫(kù)的服務(wù)器資源耗盡，導(dǎo)致讀寫超時(shí)，業(yè)務(wù)讀寫數(shù)據(jù)庫(kù)時(shí)要么無(wú)法連接數(shù)據(jù)庫(kù)、要么超時(shí)，最終用戶看到的現(xiàn)象就是訪問(wèn)很慢，一會(huì)兒訪問(wèn)拋出異常，一會(huì)兒訪問(wèn)又是正常結(jié)果。

如果進(jìn)一步探究，導(dǎo)致接口級(jí)故障的原因可以分為兩大類：

• 內(nèi)部原因：包括程序bug導(dǎo)致死循環(huán)，某個(gè)接口導(dǎo)致數(shù)據(jù)庫(kù)慢查詢，程序邏輯不完善導(dǎo)致耗盡內(nèi)存等。
• 外部原因：包括黑客攻擊，促銷或者搶購(gòu)引入了超出平時(shí)幾倍甚至幾十倍的用戶，第三方系統(tǒng)大量請(qǐng)求，第三方系統(tǒng)響應(yīng)緩慢等。

解決接口級(jí)故障的核心思想和異地多活基本類似，都是優(yōu)先保證核心業(yè)務(wù)和優(yōu)先保證絕大部分用戶。常見(jiàn)的應(yīng)對(duì)方法有四種，降級(jí)、熔斷、限流和排隊(duì)，下面我會(huì)一一講解。

1. 降級(jí)

降級(jí)指系統(tǒng)將某些業(yè)務(wù)或者接口的功能降低，可以是只提供部分功能，也可以是完全停掉所有功能。

例如，論壇可以降級(jí)為只能看帖子，不能發(fā)帖子；也可以降級(jí)為只能看帖子和評(píng)論，不能發(fā)評(píng)論；而App的日志上傳接口，可以完全停掉一段時(shí)間，這段時(shí)間內(nèi)App都不能上傳日志。

降級(jí)的核心思想就是丟車保帥，優(yōu)先保證核心業(yè)務(wù)。

例如，對(duì)于論壇來(lái)說(shuō)，90%的流量是看帖子，那我們就優(yōu)先保證看帖的功能；對(duì)于一個(gè)App來(lái)說(shuō)，日志上傳接口只是一個(gè)輔助的功能，故障時(shí)完全可以停掉。

常見(jiàn)的實(shí)現(xiàn)降級(jí)的方式有兩種：

1.1 系統(tǒng)后門降級(jí)

簡(jiǎn)單來(lái)說(shuō)，就是系統(tǒng)預(yù)留了后門用于降級(jí)操作。例如，系統(tǒng)提供一個(gè)降級(jí)URL，當(dāng)訪問(wèn)這個(gè)URL時(shí)，就相當(dāng)于執(zhí)行降級(jí)指令，具體的降級(jí)指令通過(guò)URL的參數(shù)傳入即可。這種方案有一定的安全隱患，所以也會(huì)在URL中加入密碼這類安全措施。

系統(tǒng)后門降級(jí)的方式實(shí)現(xiàn)成本低，但主要缺點(diǎn)是如果服務(wù)器數(shù)量多，需要一臺(tái)一臺(tái)去操作，效率比較低，這在故障處理爭(zhēng)分奪秒的場(chǎng)景下是比較浪費(fèi)時(shí)間的。

1.2 獨(dú)立降級(jí)系統(tǒng)

為了解決系統(tǒng)后門降級(jí)方式的缺點(diǎn)，我們可以將降級(jí)操作獨(dú)立到一個(gè)單獨(dú)的系統(tǒng)中，實(shí)現(xiàn)復(fù)雜的權(quán)限管理、批量操作等功能。

其基本架構(gòu)如下：

圖片

2. 熔斷

熔斷是指按照規(guī)則停掉外部接口的訪問(wèn)，防止某些外部接口故障導(dǎo)致自己的系統(tǒng)處理能力急劇下降或者出故障。

圖片

熔斷和降級(jí)是兩個(gè)比較容易混淆的概念，因?yàn)閱渭儚拿稚峡矗孟穸加薪鼓硞€(gè)功能的意思。但它們的內(nèi)涵是不同的，因?yàn)榻导?jí)的目的是應(yīng)對(duì)系統(tǒng)自身的故障，而熔斷的目的是應(yīng)對(duì)依賴的外部系統(tǒng)故障的情況。

假設(shè)一個(gè)這樣的場(chǎng)景：A服務(wù)的X功能依賴B服務(wù)的某個(gè)接口，當(dāng)B服務(wù)的接口響應(yīng)很慢的時(shí)候，A服務(wù)的X功能響應(yīng)肯定也會(huì)被拖慢，進(jìn)一步導(dǎo)致A服務(wù)的線程都被卡在X功能處理上，于是A服務(wù)的其他功能都會(huì)被卡住或者響應(yīng)非常慢。

這時(shí)就需要熔斷機(jī)制了：A服務(wù)不再請(qǐng)求B服務(wù)的這個(gè)接口，A服務(wù)內(nèi)部只要發(fā)現(xiàn)是請(qǐng)求B服務(wù)的這個(gè)接口就立即返回錯(cuò)誤，從而避免A服務(wù)整個(gè)被拖慢甚至拖死。

實(shí)現(xiàn)熔斷機(jī)制有兩個(gè)關(guān)鍵點(diǎn)：

一是需要有一個(gè)統(tǒng)一的API調(diào)用層，由API調(diào)用層來(lái)進(jìn)行采樣或者統(tǒng)計(jì)。如果接口調(diào)用散落在代碼各處，就沒(méi)法進(jìn)行統(tǒng)一處理了。

二是閾值的設(shè)計(jì)，例如1分鐘內(nèi)30%的請(qǐng)求響應(yīng)時(shí)間超過(guò)1秒就熔斷，這個(gè)策略中的“1分鐘”“30%”“1秒”都對(duì)最終的熔斷效果有影響。實(shí)踐中，一般都是先根據(jù)分析確定閾值，然后上線觀察效果，再進(jìn)行調(diào)優(yōu)。

3. 限流

降級(jí)是從系統(tǒng)功能優(yōu)先級(jí)的角度考慮如何應(yīng)對(duì)故障，而限流則是從用戶訪問(wèn)壓力的角度來(lái)考慮如何應(yīng)對(duì)故障。限流指只允許系統(tǒng)能夠承受的訪問(wèn)量進(jìn)來(lái)，超出系統(tǒng)訪問(wèn)能力的請(qǐng)求將被丟棄。

雖然“丟棄”這個(gè)詞聽(tīng)起來(lái)讓人不太舒服，但保證一部分請(qǐng)求能夠正常響應(yīng)，總比全部請(qǐng)求都不能響應(yīng)要好得多。

限流一般都是系統(tǒng)內(nèi)實(shí)現(xiàn)的，常見(jiàn)的限流方式可以分為兩類：基于請(qǐng)求限流和基于資源限流。

3.1 基于請(qǐng)求限流

基于請(qǐng)求限流指從外部訪問(wèn)的請(qǐng)求角度考慮限流，常見(jiàn)的方式有兩種。

第一種是限制總量，也就是限制某個(gè)指標(biāo)的累積上限，常見(jiàn)的是限制當(dāng)前系統(tǒng)服務(wù)的用戶總量，例如：某個(gè)直播間限制總用戶數(shù)上限為100萬(wàn)，超過(guò)100萬(wàn)后新的用戶無(wú)法進(jìn)入；某個(gè)搶購(gòu)活動(dòng)商品數(shù)量只有100個(gè)，限制參與搶購(gòu)的用戶上限為1萬(wàn)個(gè)，1萬(wàn)以后的用戶直接拒絕。

第二種是限制時(shí)間量，也就是限制一段時(shí)間內(nèi)某個(gè)指標(biāo)的上限，例如1分鐘內(nèi)只允許10000個(gè)用戶訪問(wèn)；每秒請(qǐng)求峰值最高為10萬(wàn)。

無(wú)論是限制總量還是限制時(shí)間量，共同的特點(diǎn)都是實(shí)現(xiàn)簡(jiǎn)單，但在實(shí)踐中面臨的主要問(wèn)題是比較難以找到合適的閾值。例如系統(tǒng)設(shè)定了1分鐘10000個(gè)用戶，但實(shí)際上6000個(gè)用戶的時(shí)候系統(tǒng)就扛不住了；或者達(dá)到1分鐘10000用戶后，其實(shí)系統(tǒng)壓力還不大，但此時(shí)已經(jīng)開(kāi)始丟棄用戶訪問(wèn)了。

即使找到了合適的閾值，基于請(qǐng)求限流還面臨硬件相關(guān)的問(wèn)題。例如一臺(tái)32核的機(jī)器和64核的機(jī)器處理能力差別很大，閾值是不同的，可能有的技術(shù)人員以為簡(jiǎn)單根據(jù)硬件指標(biāo)進(jìn)行數(shù)學(xué)運(yùn)算就可以得出來(lái)，實(shí)際上這樣是不可行的，64核的機(jī)器比32核的機(jī)器，業(yè)務(wù)處理性能并不是2倍的關(guān)系，可能是1.5倍，甚至可能是1.1倍。

為了找到合理的閾值，通常情況下可以采用性能壓測(cè)來(lái)確定閾值，但性能壓測(cè)也存在覆蓋場(chǎng)景有限的問(wèn)題，可能出現(xiàn)某個(gè)性能壓測(cè)沒(méi)有覆蓋的功能導(dǎo)致系統(tǒng)壓力很大；另外一種方式是逐步優(yōu)化：先設(shè)定一個(gè)閾值然后上線觀察運(yùn)行情況，發(fā)現(xiàn)不合理就調(diào)整閾值。

基于上述的分析，根據(jù)閾值來(lái)限制訪問(wèn)量的方式更多的適應(yīng)于業(yè)務(wù)功能比較簡(jiǎn)單的系統(tǒng)，例如負(fù)載均衡系統(tǒng)、網(wǎng)關(guān)系統(tǒng)、搶購(gòu)系統(tǒng)等。

3.2 基于資源限流

基于請(qǐng)求限流是從系統(tǒng)外部考慮的，而基于資源限流是從系統(tǒng)內(nèi)部考慮的，也就是找到系統(tǒng)內(nèi)部影響性能的關(guān)鍵資源，對(duì)其使用上限進(jìn)行限制。常見(jiàn)的內(nèi)部資源包括連接數(shù)、文件句柄、線程數(shù)和請(qǐng)求隊(duì)列等。

例如，采用Netty來(lái)實(shí)現(xiàn)服務(wù)器，每個(gè)進(jìn)來(lái)的請(qǐng)求都先放入一個(gè)隊(duì)列，業(yè)務(wù)線程再?gòu)年?duì)列讀取請(qǐng)求進(jìn)行處理，隊(duì)列長(zhǎng)度最大值為10000，隊(duì)列滿了就拒絕后面的請(qǐng)求；也可以根據(jù)CPU的負(fù)載或者占用率進(jìn)行限流，當(dāng)CPU的占用率超過(guò)80%的時(shí)候就開(kāi)始拒絕新的請(qǐng)求。

基于資源限流相比基于請(qǐng)求限流能夠更加有效地反映當(dāng)前系統(tǒng)的壓力，但實(shí)際設(shè)計(jì)時(shí)也面臨兩個(gè)主要的難點(diǎn)：如何確定關(guān)鍵資源，以及如何確定關(guān)鍵資源的閾值。

通常情況下，這也是一個(gè)逐步調(diào)優(yōu)的過(guò)程：設(shè)計(jì)的時(shí)候先根據(jù)推斷選擇某個(gè)關(guān)鍵資源和閾值，然后測(cè)試驗(yàn)證，再上線觀察，如果發(fā)現(xiàn)不合理，再進(jìn)行優(yōu)化。

限流算法

為了更好地實(shí)現(xiàn)前面描述的各種限流方式，通常情況下我們會(huì)基于限流算法來(lái)設(shè)計(jì)方案。常見(jiàn)的限流算法有兩大類四小類，它們的實(shí)現(xiàn)原理和優(yōu)缺點(diǎn)各不相同，在實(shí)際設(shè)計(jì)的時(shí)候需要根據(jù)業(yè)務(wù)場(chǎng)景來(lái)選擇。

（1）時(shí)間窗

第一大類是時(shí)間窗算法，它會(huì)限制一定時(shí)間窗口內(nèi)的請(qǐng)求量或者資源消耗量，根據(jù)實(shí)現(xiàn)方式又可以細(xì)分為“固定時(shí)間窗”和“滑動(dòng)時(shí)間窗”。

• 固定時(shí)間窗

固定時(shí)間窗算法的實(shí)現(xiàn)原理是，統(tǒng)計(jì)固定時(shí)間周期內(nèi)的請(qǐng)求量或者資源消耗量，超過(guò)限額就會(huì)啟動(dòng)限流，如下圖所示：

圖片

它的優(yōu)點(diǎn)是實(shí)現(xiàn)簡(jiǎn)單，缺點(diǎn)是存在臨界點(diǎn)問(wèn)題。例如上圖中的紅藍(lán)兩點(diǎn)只間隔了短短10秒，期間的請(qǐng)求數(shù)卻已經(jīng)達(dá)到200，超過(guò)了算法規(guī)定的限額（1分鐘內(nèi)處理100）。但是因?yàn)檫@些請(qǐng)求分別來(lái)自兩個(gè)統(tǒng)計(jì)窗口，從單個(gè)窗口來(lái)看還沒(méi)有超出限額，所以并不會(huì)啟動(dòng)限流，結(jié)果可能導(dǎo)致系統(tǒng)因?yàn)閴毫^(guò)大而掛掉。

• 滑動(dòng)時(shí)間窗

為了解決臨界點(diǎn)問(wèn)題，滑動(dòng)時(shí)間窗算法應(yīng)運(yùn)而生，它的實(shí)現(xiàn)原理是，兩個(gè)統(tǒng)計(jì)周期部分重疊，從而避免短時(shí)間內(nèi)的兩個(gè)統(tǒng)計(jì)點(diǎn)分屬不同的時(shí)間窗的情況，如下圖所示：

圖片

總體上來(lái)看，滑動(dòng)時(shí)間窗的限流效果要比固定時(shí)間窗更好，但是實(shí)現(xiàn)也會(huì)稍微復(fù)雜一些。

（2）桶算法

第二大類是桶算法，用一個(gè)虛擬的“桶”來(lái)臨時(shí)存儲(chǔ)一些東西。根據(jù)桶里面放的東西，又可以細(xì)分為“漏桶”和“令牌桶”。

• 漏桶

漏桶算法的實(shí)現(xiàn)原理是，將請(qǐng)求放入“桶”（消息隊(duì)列等），業(yè)務(wù)處理單元（線程、進(jìn)程和應(yīng)用等）從桶里拿請(qǐng)求處理，桶滿則丟棄新的請(qǐng)求，如下圖所示：

圖片

我們可以看到漏桶算法的三個(gè)關(guān)鍵實(shí)現(xiàn)點(diǎn)：

• 流入速率不固定：可能瞬間流入非常多的請(qǐng)求，例如0點(diǎn)簽到、整點(diǎn)秒殺。
• 勻速(極速)流出：這是理解漏桶算法的關(guān)鍵，也就是說(shuō)即使大量請(qǐng)求進(jìn)入了漏桶，但是從漏桶流出的速度是勻速的，速度的最大值就是系統(tǒng)的極限處理速度（對(duì)應(yīng)圖中的“極速”）。這樣就保證了系統(tǒng)在收到海量請(qǐng)求的時(shí)候不被壓垮，這是第一層的保護(hù)措施。需要注意的是：如果漏桶沒(méi)有堆積，那么流出速度就等于流入速度，這個(gè)時(shí)候流出速度就不是勻速的。
• 桶滿則丟棄請(qǐng)求：這是第二層保護(hù)措施，也就是說(shuō)漏桶不是無(wú)限容量，而是有限容量，例如漏桶最多存儲(chǔ)100萬(wàn)個(gè)請(qǐng)求，桶滿了則直接丟棄后面的請(qǐng)求。

漏桶算法的技術(shù)本質(zhì)是總量控制，桶大小是設(shè)計(jì)關(guān)鍵，具體的優(yōu)缺點(diǎn)如下：

• 突發(fā)大量流量時(shí)丟棄的請(qǐng)求較少，因?yàn)槁┩氨旧碛芯彺嬲?qǐng)求的作用。
• 桶大小動(dòng)態(tài)調(diào)整比較困難（例如 Java BlockingQueue），需要不斷的嘗試才能找到符合業(yè)務(wù)需求的最佳桶大小。
• 無(wú)法精確控制流出速度，也就是業(yè)務(wù)的處理速度。

漏桶算法主要適用于瞬時(shí)高并發(fā)流量的場(chǎng)景（例如剛才提到的0點(diǎn)簽到、整點(diǎn)秒殺等）。在短短幾分鐘內(nèi)涌入大量請(qǐng)求時(shí)，為了更好的業(yè)務(wù)效果和用戶體驗(yàn)，即使處理慢一些，也要做到盡量不丟棄用戶請(qǐng)求。

• 令牌桶算法

令牌桶算法和漏桶算法的不同之處在于，桶中放入的不是請(qǐng)求，而是“令牌”，這個(gè)令牌就是業(yè)務(wù)處理前需要拿到的“許可證”。也就是說(shuō)，當(dāng)系統(tǒng)收到一個(gè)請(qǐng)求時(shí)，先要到令牌桶里面拿“令牌”，拿到令牌才能進(jìn)一步處理，拿不到就要丟棄請(qǐng)求。

它的實(shí)現(xiàn)原理是如下圖所示：

圖片

我們可以看到令牌桶算法的三個(gè)關(guān)鍵設(shè)計(jì)點(diǎn)：

• 有一個(gè)處理單元往桶里面放令牌，放的速率是可以控制的。
• 桶里面可以累積一定數(shù)量的令牌，當(dāng)突發(fā)流量過(guò)來(lái)的時(shí)候，因?yàn)橥袄锩嬗欣鄯e的令牌，此時(shí)的業(yè)務(wù)處理速度會(huì)超過(guò)令牌放入的速度。
• 如果令牌不足，即使系統(tǒng)有能力處理，也會(huì)丟棄請(qǐng)求。

令牌桶算法的技術(shù)本質(zhì)是速率控制，令牌產(chǎn)生的速率是設(shè)計(jì)關(guān)鍵，具體的優(yōu)缺點(diǎn)如下：

• 可以動(dòng)態(tài)調(diào)整處理速率，實(shí)現(xiàn)更加靈活。
• 突發(fā)大量流量的時(shí)候可能丟棄很多請(qǐng)求，因?yàn)榱钆仆安荒芾鄯e太多令牌。
• 實(shí)現(xiàn)相對(duì)復(fù)雜。

令牌桶算法主要適用于兩種典型的場(chǎng)景，一種是需要控制訪問(wèn)第三方服務(wù)的速度，防止把下游壓垮，例如支付寶需要控制訪問(wèn)銀行接口的速率；另一種是需要控制自己的處理速度，防止過(guò)載，例如壓測(cè)結(jié)果顯示系統(tǒng)最大處理TPS是100，那么就可以用令牌桶來(lái)限制最大的處理速度。

剛才介紹漏桶算法的時(shí)候我提到漏桶算法可以應(yīng)對(duì)瞬時(shí)高并發(fā)流量，現(xiàn)在介紹令牌桶算法的時(shí)候，我又說(shuō)令牌桶允許突發(fā)流量。

你可能會(huì)問(wèn)，這兩種說(shuō)法好像差不多啊，它們到底有什么區(qū)別，到底誰(shuí)更適合做秒殺呢？

其實(shí)，令牌桶的“允許突發(fā)”實(shí)際上只是“允許一定程度的突發(fā)”，比如系統(tǒng)處理能力是每秒100 TPS，突發(fā)到120 TPS是可以的，但如果突發(fā)到1000 TPS的話，系統(tǒng)大概率就被壓垮了。所以處理秒殺時(shí)高并發(fā)流量，還是得用漏桶算法。

令牌桶的算法原本是用于網(wǎng)絡(luò)設(shè)備控制傳輸速度的，而且它控制的目的是保證一段時(shí)間內(nèi)的平均傳輸速度。之所以說(shuō)令牌桶適合突發(fā)流量，是指在網(wǎng)絡(luò)傳輸?shù)臅r(shí)候，可以允許某段時(shí)間內(nèi)（一般就幾秒）超過(guò)平均傳輸速率，這在網(wǎng)絡(luò)環(huán)境下常見(jiàn)的情況就是“網(wǎng)絡(luò)抖動(dòng)”。

但這個(gè)短時(shí)間的突發(fā)流量并不會(huì)導(dǎo)致雪崩效應(yīng)，網(wǎng)絡(luò)設(shè)備也能夠處理得過(guò)來(lái)。對(duì)應(yīng)到令牌桶應(yīng)用到業(yè)務(wù)處理的場(chǎng)景，就要求即使有突發(fā)流量來(lái)了，系統(tǒng)自己或者下游系統(tǒng)要真的能夠處理的過(guò)來(lái)，否則令牌桶允許突發(fā)流量進(jìn)來(lái)，結(jié)果系統(tǒng)或者下游處理不了，那還是會(huì)被壓垮。

因此，令牌桶在實(shí)際設(shè)計(jì)的時(shí)候，桶大小不能像漏桶那樣設(shè)計(jì)很大，需要根據(jù)系統(tǒng)的處理能力來(lái)進(jìn)行仔細(xì)的估算。例如，漏桶算法的桶容量可以設(shè)計(jì)為100萬(wàn)，但是一個(gè)每秒30 TPS的令牌桶，桶的容量可能只能設(shè)計(jì)成40左右。海外有的銀行給移動(dòng)錢包提供的接口TPS上限是30，壓測(cè)到了40就真的掛了。

4. 排隊(duì)

排隊(duì)實(shí)際上是限流的一個(gè)變種，限流是直接拒絕用戶，排隊(duì)是讓用戶等待一段時(shí)間，全世界最有名的排隊(duì)當(dāng)屬12306網(wǎng)站排隊(duì)了。

排隊(duì)雖然沒(méi)有直接拒絕用戶，但用戶等了很長(zhǎng)時(shí)間后進(jìn)入系統(tǒng)，體驗(yàn)并不一定比限流好。

由于排隊(duì)需要臨時(shí)緩存大量的業(yè)務(wù)請(qǐng)求，單個(gè)系統(tǒng)內(nèi)部無(wú)法緩存這么多數(shù)據(jù)，一般情況下，排隊(duì)需要用獨(dú)立的系統(tǒng)去實(shí)現(xiàn)，例如使用Kafka這類消息隊(duì)列來(lái)緩存用戶請(qǐng)求。

下圖是1號(hào)店的“雙11”秒殺排隊(duì)系統(tǒng)架構(gòu)：

圖片

它的基本實(shí)現(xiàn)摘錄如下：

【排隊(duì)模塊】 負(fù)責(zé)接收用戶的搶購(gòu)請(qǐng)求，將請(qǐng)求以先入先出的方式保存下來(lái)。每一個(gè)參加秒殺活動(dòng)的商品保存一個(gè)隊(duì)列，隊(duì)列的大小可以根據(jù)參與秒殺的商品數(shù)量（或加點(diǎn)余量）自行定義。

【調(diào)度模塊】 負(fù)責(zé)排隊(duì)模塊到服務(wù)模塊的動(dòng)態(tài)調(diào)度，不斷檢查服務(wù)模塊，一旦處理能力有空閑，就從排隊(duì)隊(duì)列頭上把用戶訪問(wèn)請(qǐng)求調(diào)入服務(wù)模塊，并負(fù)責(zé)向服務(wù)模塊分發(fā)請(qǐng)求。這里調(diào)度模塊扮演一個(gè)中介的角色，但不只是傳遞請(qǐng)求而已，它還擔(dān)負(fù)著調(diào)節(jié)系統(tǒng)處理能力的重任。我們可以根據(jù)服務(wù)模塊的實(shí)際處理能力，動(dòng)態(tài)調(diào)節(jié)向排隊(duì)系統(tǒng)拉取請(qǐng)求的速度。

【服務(wù)模塊】 負(fù)責(zé)調(diào)用真正業(yè)務(wù)來(lái)處理服務(wù)，并返回處理結(jié)果，調(diào)用排隊(duì)模塊的接口回寫業(yè)務(wù)處理結(jié)果。

小結(jié)

今天我為你講了接口級(jí)故障的四種應(yīng)對(duì)方法，分別是降級(jí)、熔斷、限流和排隊(duì)，希望對(duì)你有所幫助。