Avancerad begränsning av begäranden med Azure API Management
GÄLLER FÖR: Alla API Management-nivåer
Att kunna begränsa inkommande begäranden är en viktig roll för Azure API Management. Antingen genom att kontrollera antalet begäranden eller det totala antalet överförda begäranden/data tillåter API Management API-leverantörer att skydda sina API:er från missbruk och skapa värde för olika API-produktnivåer.
Begränsningar och kvoter
Hastighetsbegränsning och kvoter används för olika syften.
Hastighetsbegränsningar
Hastighetsbegränsning 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 med hög samtalsvolym kan du ange en rate-limit-by-key princip för att inte tillåta hög samtalsvolym med hjälp av den här inställningen.
Varning
På grund av begränsningsarkitekturens distribuerade karaktär är hastighetsbegränsningen aldrig helt korrekt. Skillnaden mellan det konfigurerade och det verkliga antalet tillåtna begäranden varierar beroende på begärandevolymen och hastigheten, svarstiden i serverdelen och andra faktorer.
Säljbudgetar
Kvoter används vanligtvis för att kontrollera anropsfrekvenser 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. För intäktsgenerering av ditt API kan kvoter också anges på olika sätt för nivåbaserade prenumerationer. En prenumeration på Basic-nivå kanske till exempel inte kan göra fler än 10 000 anrop per månad, men en Premium-nivå kan gå upp till 100 000 000 anrop per månad.
Inom Azure API Management sprids hastighetsbegränsningar vanligtvis snabbare över noderna för att skydda mot toppar. Däremot används information om användningskvoter på längre sikt och därför är dess implementering annorlunda.
Kommentar
När underliggande beräkningsresurser startas om på tjänstplattformen kan API Management fortsätta att hantera begäranden under en kort period efter att en kvot har nåtts.
Produktbaserad begränsning
Hastighetsbegränsningsfunktioner som är begränsade till en viss prenumeration är användbara för API-providern att tillämpa gränser för de utvecklare som har registrerat sig för att använda sitt API. Det hjälper dock inte att t.ex. 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 sedan förhindra att andra kunder hos utvecklaren kan använda programmet. Dessutom kan flera kunder som kan generera en stor mängd begäranden begränsa åtkomsten till tillfälliga användare.
Anpassad nyckelbaserad begränsning
Kommentar
Principerna rate-limit-by-key och quota-by-key är inte tillgängliga när de är på förbrukningsnivån för Azure API Management. Principen quota-by-key är inte heller tillgänglig på v2-nivåerna.
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. Det sätt som detta fungerar på illustreras enklast med ett exempel.
Begränsning av IP-adress
Följande principer begränsar en enskild klient-IP-adress till endast 10 anrop varje minut, med 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ändningen av användaren. Det är dock troligt att flera användare delar en enda offentlig IP-adress på grund av att de har åtkomst till Internet via en NAT-enhet. Trots detta kan det bästa alternativet vara för API:er som tillåter oautentiserad åtkomst IpAddress .
Begränsning av användaridentitet
Om en slutanvändare autentiseras kan en begränsningsnyckel genereras 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 JWT ett objekt och använder ämnet för token för att identifiera användaren och använda den som hastighetsbegränsningsnyckel. Om användaridentiteten lagras i som ett av de andra anspråken JWT kan det värdet användas i dess ställe.
Kombinerade principer
Även om användarbaserade begränsningsprinciper ger mer kontroll än prenumerationsbaserade begränsningsprinciper, finns det fortfarande ett värde som kombinerar båda funktionerna. Begränsning efter produktprenumerationsnyckel (Begränsa anropsfrekvensen per prenumeration och Ange användningskvot per prenumeration) är ett bra sätt att aktivera intäktsgenerering av ett API genom att debitera baserat på användningsnivåer. Den finare detaljerade kontrollen av att kunna begränsa av användaren kompletterar varandra och förhindrar att en användares beteende försämrar upplevelsen av en annan.
Klientdriven begränsning
När begränsningsnyckeln definieras med ett principuttryck är det API-providern som väljer hur begränsningen ska begränsas. En utvecklare kanske dock vill styra hur de betygsätter sina egna kunder. Detta kan aktiveras av API-providern genom att införa ett anpassat huvud 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",""))"/>
På så sätt kan utvecklarens klientprogram välja hur de vill skapa hastighetsbegränsningsnyckeln. Klientutvecklarna kan skapa sina egna prisnivåer genom att allokera uppsättningar nycklar till användare och rotera nyckelanvändningen.
Sammanfattning
Azure API Management tillhandahåller hastighets- och kvotbegränsning för att både skydda och lägga till värde i din API-tjänst. Med de nya begränsningsprinciperna med anpassade omfattningsregler kan du få bättre 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 nya principer genom att tillverka hastighetsbegränsningsnycklar med klientens IP-adresser, användaridentitet och klientgenererade värden. Det finns dock många andra delar av meddelandet som kan användas som användaragent, URL-sökvägsfragment, meddelandestorlek.
Nästa steg
Ge oss din feedback som ett GitHub-problem för det här ämnet. Det skulle vara bra att höra om andra potentiella nyckelvärden som har varit ett logiskt val i dina scenarier.