可以肯定地說，大多數(shù)人了解紅綠燈等基礎設施的工作原理。然而，我們大多低估了基礎設施的重要性。由于普通駕駛員缺乏車道紀律，沒有交通系統(tǒng)的道路將完全混亂，而且在許多城市，道路網絡甚至無法跟上人口增長。

這個類比延伸到 API 設計。正如不守紀律的司機會在道路上造成嚴重破壞一樣，惡意用戶也可以威脅您的應用程序。此外，隨著用戶群的增長，管理流量激增變得至關重要。與道路的紅綠燈一樣，處理此問題的一種有效方法是速率限制。

在本教程中，我們將探討速率限制與限制以及其他 API 流量管理技術。我們將介紹它們的工作原理、如何實施它們、何時使用每種策略，并提供一個比較表來幫助您確定哪種方法最適合您的需求。

什么是速率限制？

速率限制是一種控制 API 上傳入和傳出流量的技術，它通過對 API 用戶在給定時間范圍內可以發(fā)出的請求數(shù)設置預定義限制。這樣，您可以防止單個用戶壟斷您的 API 基礎設施資源，同時防止拒絕服務 （DoS） 和暴力攻擊等惡意攻擊。

在這個場景下，速率限制是通過速率限制器實現(xiàn)的，該速率限制器會不斷檢查每個用戶的請求，以查看其請求是否在其請求限制內或超出：

如上圖所示，如果用戶在其限制范圍內，則會處理請求，并更新其新限制。但是，如果請求已超出其限制，則請求將被拒絕。此外，這些限制的上限和補充頻率取決于組織的首選項，而這些首選項又受系統(tǒng)容量和業(yè)務要求的影響。

實施速率限制

在實踐中，可以使用各種算法實現(xiàn)速率限制，每種算法都有自己的方法來管理請求速率。一些流行的包括：

• Token Bucket ---- 此算法使用具有固定令牌數(shù)量的“桶”。每個請求都會從存儲桶中刪除一個令牌;如果存儲桶為空，則請求被拒絕。
• Leaky Bucket ---- 與令牌桶類似，但在此桶中，令牌（或請求）以恒定速率處理。如果傳入請求速率超過處理速率，則超出的請求將被丟棄或延遲。
• Fixed Window ----  在固定時間窗口（例如，每分鐘或每小時）內對請求進行計數(shù)和限制。如果請求數(shù)超過窗口內的限制，則進一步的請求將被拒絕，直到下一個窗口。
• Sliding Log （滑動日志）---- 此函數(shù)使用時間戳記錄每個請求。為了確定是否允許新請求，該算法會檢查日志中允許的時間范圍內的請求數(shù)，并根據該計數(shù)做出決定。

例如，我們可以利用以下代碼中顯示的模式，通過令牌桶算法實現(xiàn)速率限制：

class TokenBucket {
    constructor(rate, capacity) {
        this.rate = rate;
        this.capacity = capacity;
        this.tokens = capacity;
        this.lastRequestTime = Date.now();
    }

    addTokens() {
        const now = Date.now();
        const elapsed = (now - this.lastRequestTime) / 1000; // Convert to seconds
        const addedTokens = elapsed * this.rate;
        this.tokens = Math.min(this.capacity, this.tokens + addedTokens);
        this.lastRequestTime = now;
    }

    allowRequest(tokensNeeded = 1) {
        this.addTokens();
        if (this.tokens >= tokensNeeded) {
            this.tokens -= tokensNeeded;
            return true;
        } else {
            return false;
        }
    }
}

在這個代碼示例中，我們定義了一個 TokenBucket 類，該類設置 Token 生成速率和容量，并記錄最后一次請求時間;然后，我們創(chuàng)建一個 addTokens（） 方法，該方法根據自上次請求以來的時間計算要添加的令牌數(shù)量，并額外更新用戶的當前令牌計數(shù)。最后，我們定義了一個 allowRequest（） 方法，用于檢查請求是否有足夠的令牌，扣除任何必要的令牌，并返回是否允許請求。

在我們的應用程序中應用此實現(xiàn)將如下所示：

const bucket = new TokenBucket(1, 10); // 1 token per second, max 10 tokens

function handleRequest(userRequest) {
  if (bucket.allowRequest()) {
    // Request allowed
    userRequest();
  } else {
    console.log("Too many requests, please try again later");
  }
}

function getPosts() {
  fetch('/path/to/api')
}

handleRequest(getPosts);

在此使用示例中，我們初始化一個新的 TokenBucket 實例，速率為每秒 1 個令牌，容量為 10 個令牌。然后，我們創(chuàng)建一個 handleRequest（） 函數(shù)來檢查請求是否被允許并打印適當?shù)南?。我們還使用假設的 getPosts（） 函數(shù)測試我們的請求處理程序。

此示例雖然是用 JavaScript 編寫的，但應該能夠幫助您開始以任何語言實現(xiàn)速率限制或使用令牌存儲桶算法。

幾乎所有的語言和框架都有庫，您可以使用這些庫輕松實現(xiàn)速率限制，而無需重新發(fā)明輪子;JavaScript 生態(tài)系統(tǒng)中的一些常用軟件包包括用于 Express.js 的 express-rate-limit 包和用于 NestJS 應用程序的 @nestjs/throttler。

速率限制替代方案

API 流量管理不僅限于限流;還有其他方法可以控制應用程序的使用情況和管理流量激增。讓我們在下面快速探索它們。

Throttling 節(jié)流

限制是另一種控制用戶向 API 發(fā)出請求的速率的技術。與速率限制不同，速率限制會在超出限制時阻止請求，而限制會引入延遲來減慢請求速率：

憑借這種設計性質，限制可以消除流量峰值，而用戶只會遇到更少的拒絕和延遲請求。但是，一個缺點是，這些故意的延遲也會增加延遲并使系統(tǒng)變慢，因為每個請求都在隊列中等待處理。此外，與簡單的速率限制相比，實現(xiàn)限制邏輯可能更復雜，在極端情況下，僅靠限制可能無法保護系統(tǒng)免受過載。

如何實施限制

可以通過保留請求時間戳隊列、計算給定時間段內的請求數(shù)以及在請求速率超過允許的限制時引入延遲來實現(xiàn)限制。示例如下所示：

class Throttler {
    constructor(maxRequests, period) {
        this.maxRequests = maxRequests;
        this.period = period;
        this.requestTimes = [];
    }

    addTokens() {
        // Filter out old request timestamps
    }

    allowRequest() {
        // Check if current requests are below maxRequests
        // If yes, log the current timestamp and allow the request
        // If no, deny the request
    }

    delayRequest() {
        // Calculate delay needed until the next request can be allowed
    }
}

在此偽代碼示例中，Throttler 類通過保留請求時間戳隊列來管理請求速率。然后，addTokens（） 方法會刪除早于設置時間段的請求時間戳。此外，allowRequest（） 方法確定該時間段內的請求量是否小于允許的最大值;如果是這樣，它會記錄當前時間戳并允許請求。否則，它將拒絕請求。最后，delayRequest 方法估計允許下一個請求之前的時間。您還可以在此處查看此示例的完整 JavaScript 實現(xiàn)。

Spike control  峰值控制

峰值控制也叫削峰，是另一種流行的技術，用于管理可能使 API 或服務不堪重負的突然激增的流量。它的工作原理是監(jiān)控短時間間隔內的請求速率，并實施臨時阻止請求、重定向流量或擴展資源等措施以適應增加的負載。

例如，假設 API 通常每分鐘可以處理 100 個請求。使用峰值控制，您可以設置一個閾值來檢測請求數(shù)是否突然躍升至每分鐘 150 個：

如上所述，當檢測到此類峰值時，您可以將系統(tǒng)配置為通過暫時阻止新請求來防止過載，將流量重定向到其他服務器以平衡負載，或快速擴展資源以管理增加的需求。

Circuit breaking 熔斷

熔斷也是管理 API 或服務彈性的有效技術，尤其是在面臨故障或性能下降時。它的工作原理是監(jiān)控服務交互的運行狀況并暫時停止對失敗服務的請求，以防止級聯(lián)故障。這里使用“service”這個詞也應該暗示，與我們之前介紹的技術不同，熔斷在微服務架構中比在整體式或簡單的 API 系統(tǒng)中更受歡迎和有用。

想象一下您的服務與第三方 API 交互的場景。如果第三方 API 開始失敗或響應緩慢，您的系統(tǒng)可以使用斷路器來檢測此問題，并在設定的時間內停止向失敗的服務發(fā)出進一步的請求。

當斷路器檢測到多個連續(xù)故障或超時時，它會 “跳閘” 電路，暫時阻止對有問題的服務的新請求。在此期間，系統(tǒng)可以向用戶返回回退響應或錯誤消息。然后，在指定的超時時間后，斷路器允許有限的測試請求檢查服務是否已恢復。如果服務響應成功，則電路將關閉，并恢復正常操作。如果故障繼續(xù)，電路將保持打開狀態(tài)，并再次阻止請求。

決定使用哪種 API 流量管理技術

決定使用哪種技術主要取決于您的應用領域和要求。但是，考慮到我們到目前為止介紹的所有內容，速率限制更適合需要強制實施嚴格請求配額的應用程序，例如公有 API 或具有分層訪問級別的 API。限制更適合于維護性能和用戶體驗至關重要的應用程序，例如電子商務網站或社交媒體平臺，因為它會引入延遲而不是直接阻止請求，從而消除流量峰值：

對于遇到不可預測的流量激增的應用程序，峰值控制將至關重要，例如，在高需求活動期間向網站提供票務，或在突發(fā)新聞期間向新聞網站提供票務。熔斷對于依賴多個外部服務（如微服務架構或 SaaS 平臺）的應用程序特別有用，因為它通過停止對失敗服務的請求來防止級聯(lián)故障，同時允許系統(tǒng)保持響應。

還可以組合多種策略以實現(xiàn)更有效的流量管理。在某些情況下，您可以進一步應用負載均衡以在服務器之間分配流量。

比較速率限制、限制、尖峰控制和熔斷

下表突出顯示了我們介紹的不同 API 流量管理技術之間的主要差異，以幫助您快速確定哪種技術最適合您。

結論

在本教程中，我們探討了速率限制和其他 API 流量管理技術，例如限制、峰值控制和熔斷。我們介紹了它們的工作原理、基本實現(xiàn)以及理想的應用領域。采取某些流量管理措施來確保您的 API 能夠按預期為用戶提供服務非常重要，本文提供了一個快速指南，可快速幫助您決定如何以及何時使用哪種技術。

原文地址：

https://blog.logrocket.com/advanced-guide-rate-limiting-api-traffic-management/。

原文作者：Elijah Asaolu