Avancerad begränsning av begäranden med Azure API Management

GÄLLER FÖR: Alla API Management-nivåer

Möjligheten att begränsa inkommande begäranden är en viktig roll för Azure API Management. API Management gör det möjligt för API-leverantörer att skydda sina API:er från missbruk och skapa värde för olika API-produktnivåer genom att styra antingen antalet begäranden eller det totala antalet begäranden/data som överförs. Den här artikeln beskriver hur du skapar och tillämpar kvot- och hastighetsbegränsning.

Begränsningar och kvoter

Hastighetsbegränsning och kvoter används för olika syften.

Hastighetsbegränsningar

Hastighetsgränser används vanligtvis för att skydda mot korta och intensiva volymtoppar. Om du till exempel vet att serverdelstjänsten har en flaskhals i databasen när samtalsvolymerna är höga kan du ange en rate-limit-by-key princip för att inte tillåta höga samtalsvolymer.

Kvoter

Kvoter används vanligtvis för att styra samtalsfrekvensen under en längre tidsperiod. De kan till exempel ange det totala antalet anrop som en viss prenumerant kan göra inom en viss månad. Om du tjänar pengar på ditt API kan du också ange kvoter på olika sätt för nivåbaserade prenumerationer. Till exempel kanske en prenumeration på Basic-nivån inte kan göra fler än 10 000 anrop per månad, men en Premium-nivå kanske kan göra 100 000 000 anrop varje månad.

I API Management sprids hastighetsgränser vanligtvis snabbare över noderna för att skydda mot toppar. Däremot används information om användningskvoter på längre sikt, så implementeringen skiljer sig.

Produktbaserad strypning

API-leverantörer kan använda hastighetsbegränsningsfunktioner som är begränsade till en viss prenumeration för att tillämpa gränser för de utvecklare som har registrerat sig för att använda sitt API. Den här typen av begränsning hjälper dock inte, till exempel, för att begränsa enskilda slutanvändare av API:et. Det är möjligt för en enskild användare av utvecklarprogrammet att använda hela kvoten och förhindra att andra kunder hos utvecklaren kan använda programmet. Dessutom kan flera kunder som genererar en stor mängd begäranden begränsa åtkomsten till tillfälliga användare.

Anpassad nyckelbaserad begränsning

Principerna rate-limit-by-key och quota-by-key ger en mer flexibel lösning för trafikkontroll. Med de här principerna kan du definiera uttryck för att identifiera de nycklar som används för att spåra trafikanvändningen. Den här tekniken illustreras i följande exempel.

Begränsning av IP-adress

Följande principer begränsar en enskild klient-IP-adress till endast 10 anrop varje minut och framtvingar totalt 1 000 000 anrop och 10 000 kilobyte bandbredd per månad:

<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)" />

Om alla klienter på Internet använde en unik IP-adress kan detta vara ett effektivt sätt att begränsa användarens användning. Det är dock troligt att flera användare delar en enda offentlig IP-adress eftersom de har åtkomst till Internet via en NAT-enhet. Men för API:er som tillåter oautentiserad åtkomst kan användning IpAddress vara det bästa alternativet.

Begränsning av användaridentifiering

Om en slutanvändare autentiseras kan du generera en begränsningsnyckel baserat på information som unikt identifierar användaren:

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

Det här exemplet visar hur du extraherar auktoriseringsrubriken, konverterar den till ett JWT objekt och använder ämnet för token för att identifiera användaren. Värdet används sedan som hastighetsbegränsningsnyckel. Om användaridentiteten lagras i JWT som ett av de andra anspråken kan det värdet användas istället.

Kombinerade principer

Även om användarbaserade begränsningsprinciper ger mer kontroll än prenumerationsbaserade begränsningsprinciper finns det fortfarande ett värde i att kombinera båda funktionerna. För monetariserade API:er är begränsning efter produktprenumerationsnyckel (Begränsa samtalsfrekvens per prenumeration och Ange användningskvot per prenumeration) ett bra sätt att implementera avgifter som baseras på användningsnivåer. Den finare kontrollen över förmågan att begränsa användningen per användare är kompletterande och förhindrar användares beteende från att försämra upplevelsen för andra.

Klientdriven reglering

När begränsningsnyckeln definieras via ett principuttryck väljer API-leverantören hur begränsningen ska tillämpas. En utvecklare kanske dock vill styra hur de begränsar sina egna kunder. API-providern kan aktivera den här typen av kontroll genom att införa en anpassad rubrik så att utvecklarens klientprogram kan kommunicera nyckeln till API:et:

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

Med den här tekniken kan utvecklarens klientprogram avgöra hur du skapar hastighetsbegränsningsnyckeln. Klientutvecklarna kan skapa sina egna prisnivåer genom att allokera uppsättningar nycklar till användare och rotera nyckelanvändningen.

Överväganden för flera regioner eller gatewayer

Hastighetsbegränsningsprinciper som rate-limit, rate-limit-by-key, azure-openai-token-limitoch llm-token-limit använda räknare på nivån för API Management-gatewayen. I distributioner i flera regioner av API Management har därför varje regional gateway en separat räknare och hastighetsbegränsningar tillämpas separat för varje region. På samma sätt tillämpas gränser separat för varje arbetsytegateway i API Management-instanser med arbetsytor.

Kvotprinciper som quota och quota-by-key är globala, vilket innebär att en enskild räknare används på nivån för API Management-instansen.

Sammanfattning

API Management tillhandahåller hastighets- och kvotbegränsning för att skydda och lägga till värde i DIN API-tjänst. Begränsningsprinciper som har anpassade omfångsregler ger finare kontroll över dessa principer så att dina kunder kan skapa ännu bättre program. Exemplen i den här artikeln visar användningen av dessa principer genom att skapa hastighetsbegränsningsnycklar med klientens IP-adresser, användaridentitet och klientgenererade värden. Du kan dock använda många andra delar av meddelandet, till exempel användaragent, URL-sökvägsfragment och meddelandestorlek.

Relaterat innehåll

• Principer för hastighetsbegränsning och kvoter