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

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

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

什么是速率限制？

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

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

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

實施速率限制

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

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

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

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 生成速率和容量，并記錄最后一次請求時間;然后，我們創建一個 addTokens（） 方法，該方法根據自上次請求以來的時間計算要添加的令牌數量，并額外更新用戶的當前令牌計數。最后，我們定義了一個 allowRequest（） 方法，用于檢查請求是否有足夠的令牌，扣除任何必要的令牌，并返回是否允許請求。

在我們的應用程序中應用此實現將如下所示：

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 個令牌。然后，我們創建一個 handleRequest（） 函數來檢查請求是否被允許并打印適當的消息。我們還使用假設的 getPosts（） 函數測試我們的請求處理程序。

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

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

速率限制替代方案

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

Throttling 節流

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

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

如何實施限制

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

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 實現。

Spike control  峰值控制

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

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

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

Circuit breaking 熔斷

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

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

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

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

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

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

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

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

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

結論

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

原文地址：

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

原文作者：Elijah Asaolu