適用於：所有 API 管理層級
Azure API 管理的關鍵功能之一是調節連入請求的能力。 API 管理可讓 API 提供者藉由控制要求速率或傳輸的總要求/數據，來保護其 API 免於濫用，並為不同的 API 產品層創造價值。 本文說明如何建立及套用配額和速率限制。
備註
閘道容量限速 是一種服務層級限速功能，可回傳 HTTP 429（過多請求）以保護閘道容量。 進階請求節流是用於各個 API 個別節流的獨立功能。
速率限制和配額
速率限制和配額會用於不同的用途。
速率限制
速率限制通常用來防止短時間內大量而密集的流量突增。 例如，如果您知道後端服務在呼叫量很高時，其資料庫會有瓶頸，您可以設定 rate-limit-by-key 原則來限制高呼叫量。
對於語言模型後端，你可以設定 llm-token-limit 政策限制後端每分鐘處理的代幣數量。 此政策有助於防止代幣使用率突然飆升，導致成本增加、資源耗盡或效能下降。
謹慎
由於節流架構的分散式本質，速率限制永遠不會完全準確。 所設定的允許要求數目與實際數目之間的差異，會因要求量和速率、後端延遲及其他因素而有所不同。
經典版本與 v2 層級的速率限制比較
API Management 根據實例是屬於經典還是 v2 服務層級，會以不同方式實作速率限制：
經典階級 使用滑動視窗演算法。
V2 層 級使用更高效的代幣桶演算法，且符合 Azure Resource Manager 的速率限制。
雖然速率限制的整體行為在各 API 管理層級間相似，但實作上的差異影響了速率限制政策的某些使用細節，如 rate-limit-by-keyllm-token-limit和 。
在 v2 層級中，權杖貯體實作會使用等同於原則中指定之呼叫數 (或權杖數) 的初始貯體大小。 對於 rate-limit 政策，該值會被分配給 limit-call 屬性；而對於 llm-token-limit 政策，該值會被分配給 tokens-per-minute 屬性。
以下範例描述一種情境，其中通話次數設為 6 次，rate-limit-by-key 政策的更新週期為 60 秒。
<rate-limit-by-key calls="6" renewal-period="60" counter-key="Counter1"/>
在此情況下，貯體大小是 6 個呼叫，表示閘道會允許初始高載 6 個呼叫。 之後，桶以每 60 秒 6 次呼叫的速度填滿，相當於每秒 0.1 次通話。
Important
在 v2 層級中，所有跨範圍使用相同計數鍵的速率限制政策實例必須使用相同的續期期與呼叫限值，否則政策實例的行為將不可預測。
配額
配額通常用來控制較長時間的通話速率。 例如，他們可對特定訂閱者設定能在指定月份內進行的呼叫總數。 如果您為 API 創造營收，您也可以針對階層式訂用帳戶以不同的方式設定配額。 例如，基本層訂用帳戶可能每月可以撥打不超過 10,000 個通話，但進階層可能每個月可以撥打 100,000,000,000 個通話。
在 API 管理中，速率限制通常會在節點之間傳播得更快，以防止尖峰。 相反地，使用量配額資訊會長期使用，因此其實作不同。
備註
在服務平台上重新啟動基礎計算資源時，API 管理在配額達成後仍可能繼續處理要求一小段時間。
產品型節流
API 提供者可以使用範圍設定為特定訂用帳戶的速率節流功能，對已註冊使用其 API 的開發人員套用限制。 不過，這種類型的節流無法解決例如對 API 個別終端使用者要求節流的情況。 開發人員應用程式的單一使用者可能會取用整個配額，並防止開發人員的其他客戶使用應用程式。 此外，某些大量提出請求的客戶可能會限制偶爾使用者的存取權。
依自訂索引鍵節流
備註
rate-limit-by-key 和 quota-by-key 政策無法在 Azure API 管理的取用層中使用。
依密鑰速率限制和依密鑰配額策略提供更靈活的流量控制解決方案。 這些原則可讓您定義表示式，以識別用來追蹤流量使用量的密鑰。 下列範例說明這項技術。
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位址，這可能是限制使用者使用的有效方式。 不過，多位使用者可能會因為透過NAT裝置存取因特網而共用單一公用IP位址。 不過，對於允許未經驗證存取的 API，使用 IpAddress 可能是最佳選項。
使用者身分識別節流
如果使用者通過驗證，您可以根據可唯一識別使用者的資訊產生節流密鑰：
<rate-limit-by-key calls="10"
renewal-period="60"
counter-key="@(context.Request.Headers.GetValueOrDefault("Authorization","").AsJwt()?.Subject)" />
此範例示範如何擷取 Authorization 標頭，將它轉換成 JWT 物件，以及使用令牌的主體來識別使用者。 然後，它會使用該值作為速率限值鍵。 如果使用者身分識別以其他宣告之一的形式儲存在 JWT 中，則可以使用該值。
結合的原則
雖然以用戶為基礎的節流原則提供比訂用帳戶型節流原則更多的控制，但仍有結合這兩項功能的價值。 針對獲利的 API，依產品訂用帳戶密鑰進行節流（依訂用帳戶限制呼叫率 和 依訂用帳戶設定使用量配額）是實作以使用量層級為基礎的費用的絕佳方式。 能夠依使用者進行節流的更細緻控制是互相補充的，並防止單一使用者的行為對其他使用者的體驗產生不良影響。
用戶端導向的節流
透過 原則表達式定義節流密鑰時，API 提供者會選擇節流的範圍。 不過，開發人員可能想要對其客戶的速率限制進行控制。 API 提供者可以引進自定義標頭，讓開發人員的用戶端應用程式能夠將密鑰傳達給 API，以啟用這種類型的控制項：
<rate-limit-by-key calls="100"
renewal-period="60"
counter-key="@(request.Headers.GetValueOrDefault("Rate-Key",""))"/>
這項技術可讓開發人員的用戶端應用程式判斷如何建立速率限制密鑰。 客戶端開發人員可以藉由將密鑰集配置給使用者，以及輪替密鑰使用量，來建立自己的速率層級。
多個區域或閘道的考量事項
速率限制政策，如 rate-limit、rate-limit-by-key 和 llm-token-limit，在 API 管理閘道層級使用計數器。 因此，在 API 管理 的多區域部署 中，每個區域閘道都有個別的計數器，而且每個區域會個別強制執行速率限制。 同樣地，在具有與工作區閘道資源相關聯之工作區的 API 管理執行個體中，限制會針對每個工作區閘道分別強制執行。 使用該服務預設管理閘道的工作區會與其他工作區及該閘道上的服務層級 API 共享速率限制計數器。
配額原則，例如quota和quota-by-key，是全域的，這表示在 API 管理實例層級使用同一個計數器。
總結
API 管理提供速率和配額節流，以保護和增加 API 服務的價值。 具有自定義範圍規則的節流原則可更精細地控制這些原則，讓您的客戶能夠建置更好的應用程式。 本文中的範例示範如何使用這些原則，方法是使用用戶端 IP 位址、使用者身分識別和客戶端產生的值來建立速率限制密鑰。 不過，您可以使用訊息的其他許多部分，例如使用者代理程式、URL 路徑片段和訊息大小。