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

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

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

如果進一步探究，導致接口級故障的原因可以分為兩大類：

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

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

1. 降級

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

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

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

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

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

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

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

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

1.2 獨立降級系統(tǒng)

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

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

圖片

2. 熔斷

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

圖片

熔斷和降級是兩個比較容易混淆的概念，因為單純從名字上看，好像都有禁止某個功能的意思。但它們的內(nèi)涵是不同的，因為降級的目的是應對系統(tǒng)自身的故障，而熔斷的目的是應對依賴的外部系統(tǒng)故障的情況。

假設一個這樣的場景：A服務的X功能依賴B服務的某個接口，當B服務的接口響應很慢的時候，A服務的X功能響應肯定也會被拖慢，進一步導致A服務的線程都被卡在X功能處理上，于是A服務的其他功能都會被卡住或者響應非常慢。

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

實現(xiàn)熔斷機制有兩個關鍵點：

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

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

3. 限流

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

雖然“丟棄”這個詞聽起來讓人不太舒服，但保證一部分請求能夠正常響應，總比全部請求都不能響應要好得多。

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

3.1 基于請求限流

基于請求限流指從外部訪問的請求角度考慮限流，常見的方式有兩種。

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

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

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

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

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

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

3.2 基于資源限流

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

例如，采用Netty來實現(xiàn)服務器，每個進來的請求都先放入一個隊列，業(yè)務線程再從隊列讀取請求進行處理，隊列長度最大值為10000，隊列滿了就拒絕后面的請求；也可以根據(jù)CPU的負載或者占用率進行限流，當CPU的占用率超過80%的時候就開始拒絕新的請求。

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

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

限流算法

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

（1）時間窗

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

• 固定時間窗

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

圖片

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

• 滑動時間窗

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

圖片

總體上來看，滑動時間窗的限流效果要比固定時間窗更好，但是實現(xiàn)也會稍微復雜一些。

（2）桶算法

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

• 漏桶

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

圖片

我們可以看到漏桶算法的三個關鍵實現(xiàn)點：

1. 流入速率不固定：可能瞬間流入非常多的請求，例如0點簽到、整點秒殺。
2. 勻速(極速)流出：這是理解漏桶算法的關鍵，也就是說即使大量請求進入了漏桶，但是從漏桶流出的速度是勻速的，速度的最大值就是系統(tǒng)的極限處理速度（對應圖中的“極速”）。這樣就保證了系統(tǒng)在收到海量請求的時候不被壓垮，這是第一層的保護措施。需要注意的是：如果漏桶沒有堆積，那么流出速度就等于流入速度，這個時候流出速度就不是勻速的。
3. 桶滿則丟棄請求：這是第二層保護措施，也就是說漏桶不是無限容量，而是有限容量，例如漏桶最多存儲100萬個請求，桶滿了則直接丟棄后面的請求。

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

1. 突發(fā)大量流量時丟棄的請求較少，因為漏桶本身有緩存請求的作用。
2. 桶大小動態(tài)調(diào)整比較困難（例如 Java BlockingQueue），需要不斷的嘗試才能找到符合業(yè)務需求的最佳桶大小。
3. 無法精確控制流出速度，也就是業(yè)務的處理速度。

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

• 令牌桶算法

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

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

圖片

我們可以看到令牌桶算法的三個關鍵設計點：

1. 有一個處理單元往桶里面放令牌，放的速率是可以控制的。
2. 桶里面可以累積一定數(shù)量的令牌，當突發(fā)流量過來的時候，因為桶里面有累積的令牌，此時的業(yè)務處理速度會超過令牌放入的速度。
3. 如果令牌不足，即使系統(tǒng)有能力處理，也會丟棄請求。

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

1. 可以動態(tài)調(diào)整處理速率，實現(xiàn)更加靈活。
2. 突發(fā)大量流量的時候可能丟棄很多請求，因為令牌桶不能累積太多令牌。
3. 實現(xiàn)相對復雜。

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

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

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

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

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

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

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

4. 排隊

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

排隊雖然沒有直接拒絕用戶，但用戶等了很長時間后進入系統(tǒng)，體驗并不一定比限流好。

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

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

圖片

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

【排隊模塊】 負責接收用戶的搶購請求，將請求以先入先出的方式保存下來。每一個參加秒殺活動的商品保存一個隊列，隊列的大小可以根據(jù)參與秒殺的商品數(shù)量（或加點余量）自行定義。

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

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

小結(jié)

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

圖片