以 Azure API 管理進行進階要求節流

適用於:所有 API 管理 層

能夠節流傳入要求是 Azure API 管理的重要角色。 藉由控制要求的速率或傳輸的要求/資料總量,API 管理讓 API 提供者能夠保護其 API 不被濫用,並建立不同 API 產品層級的價值。

速率限制和配額

速率限制和配額會用於不同的用途。

速率限制

速率限制通常用來防止過短和密集的資料量高載。 例如,如果您知道後端服務在其資料庫有高呼叫磁碟區的瓶頸,則可以使用此設定來設定 rate-limit-by-key 原則不允許高呼叫量。

警告

由於節流架構的分散本質,速率限制永遠不會完全精確。 已設定的允許要求數目,與實際允許的要求數目之間的差異,取決於要求的數量和速率、後端延遲和其他因素。

配額

配額通常用來控制較長一段時間的通話速率。 例如,他們可對特定訂閱者設定能在指定月份內進行的呼叫總數。 若要讓您的 API 獲利,也可以針對以階層為基礎的訂用帳戶,以不同的方式設定配額。 例如,基本層訂用帳戶一個月最多可以撥打 10,000 個通話,但進階層一個月最多可以有 100,000,000 個通話。

在 Azure API 管理中,速率限制通常會在節點之間更快傳播,以防止尖峰。 相反地,使用量配額資訊會長期使用,因此其實作不同。

注意

在服務平台中重新啟動基礎計算資源時,APIM 可能會在達到配額後持續處理要求一小段時間。

產品型節流

範圍設定為特定訂用帳戶的速率節流功能,對 API 提供者套用限制給已註冊使用其 API 的開發人員很有幫助。 不過,例如在節流 API 的個別使用者時,這並不會有所幫助。 想讓開發人員的應用程式的單一使用者取用整個配額,並讓開發人員的其他客戶無法使用應用程式,是有可能的。 同樣的,數個產生大量要求的客戶可能會限制偶爾使用者的存取權。

依自訂索引鍵節流

注意

rate-limit-by-keyquota-by-key 原則在 Azure API 管理的取用層中時無法使用。 原則 quota-by-key 目前也無法在 v2 層中使用。

rate-limit-by-keyquota-by-key 原則能提供更有彈性的流量控制解決方案。 這些原則可讓您定義運算式,以識別要用來追蹤流量使用量的索引鍵。 其運作的方式用範例來說明最簡單。

IP 位址節流

下列原則會限制單一用戶端 IP 位址每一分鐘只有 10 個呼叫,等於每個月總數為 1,000,000 個呼叫和 10,000 KB 頻寬。

<rate-limit-by-key  calls="10"
          renewal-period="60"
          counter-key="@(context.Request.IpAddress)" />

<quota-by-key calls="1000000"
          bandwidth="10000"
          renewal-period="2629800"
          counter-key="@(context.Request.IpAddress)" />

如果網際網路上的所有用戶端皆使用唯一 IP 位址,這是可能是限制使用者使用量的有效方式。 不過,可能會有多個使用者共用單一公用 IP 位址,因為他們是透過 NAT 裝置存取網際網路。 儘管如此,對允許未驗證存取的 API 來說, IpAddress 可能是最佳選項。

使用者身分識別節流

如果使用者經過驗證,則可根據該使用者的唯一身分識別產生節流索引鍵。

<rate-limit-by-key calls="10"
    renewal-period="60"
    counter-key="@(context.Request.Headers.GetValueOrDefault("Authorization","").AsJwt()?.Subject)" />

此範例會示範如何擷取授權標頭,將它轉換成 JWT 物件,然後使用權杖的主體來識別使用者,並使用它作為速率限制索引鍵。 如果使用者身分識別儲存於 JWT 以作為其中一個其他宣告,則可使用該值來代替它。

結合的原則

雖然使用者型節流原則比訂用帳戶型節流原則提供更多的控制,但仍會有結合兩種功能的值。 依產品訂用帳戶金鑰 (依訂用帳戶限制呼叫率依訂用帳戶設定使用量配額) 進行節流是一種根據使用量層級收費、讓 API 創造獲利的絕佳方式。 更精細的依使用者控制節流則和其互補,並防止一位使用者的行為降低另一位使用者的體驗。

用戶端導向節流

若使用 原則運算式定義節流索引鍵,則是由 API 提供者選擇如何設定節流的範圍。 不過,開發人員可能想要控制他們對自己的客戶的速率限制。 API 提供者可以藉由導入自訂標頭來做到這一點,以允許開發人員的用戶端應用程式與 API 通訊索引鍵。

<rate-limit-by-key calls="100"
          renewal-period="60"
          counter-key="@(request.Headers.GetValueOrDefault("Rate-Key",""))"/>

這可讓開發人員的用戶端應用程式選擇要如何建立速率限制索引鍵。 用戶端開發人員可以透過將索引鍵組配置給使用者並輪流使用索引鍵,來建立自己的速率層。

摘要

Azure API 管理提供速率和配額節流,不但能保護您的 API 服務,還能為您的 API 服務增加價值。 新的節流原則與自訂範圍規則,可讓您更精細的控制這些原則,進而讓您的客戶建置更好的應用程式。 本文中的範例示範如何使用這些新原則,分別使用用戶端 IP 位址、使用者身分識別及用戶端產生值來製造速率限制索引鍵。 不過,訊息中還有許多其他部份可以利用,例如使用者代理程式、URL 路徑片段、訊息大小。

下一步

請提供意見反應,作為本主題的 GitHub 問題。 我們很想知道其他在您的案例中是合理選擇的可能索引鍵值。