Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Door snelheidsbeperking te gebruiken, kunt u het aantal API-aanroepen beperken dat een gebruiker of service in een specifieke periode kan uitvoeren. Snelheidsbeperking helpt u ervoor te zorgen dat er eerlijk gebruik wordt gegarandeerd en voorkomt dat één gebruiker of service de API-resources in beslag kan maken. Azure API Management biedt een handige manier om snelheidsbeperking voor uw API's te implementeren.
Waarom Azure API Management gebruiken?
Azure API Management is een krachtige en veelzijdige cloudservice waarmee organisaties API's kunnen publiceren naar externe, partner- en interne ontwikkelaars. Het biedt hulpprogramma's voor het beveiligen, beheren en schalen van API-aanroepen. Een van de functies is het beheren van snelheidsbeperking, wat handig is voor het onderhouden van de status en betrouwbaarheid van uw API's.
Snelheidsbeperking configureren in Azure API Management
Azure API Management maakt gebruik van beleidsregels om snelheidsbeperking af te dwingen. U kunt deze beleidsregels definiëren op verschillende niveaus: globaal, product, of API-specifiek. Met deze flexibiliteit kunt u de snelheidsbeperking aanpassen aan de vereisten en gebruikspatronen van uw API.
Voordat u begint met het implementeren van frequentielimieten, moet u beslissen over de frequentielimieten. De limieten die u instelt, zijn afhankelijk van de capaciteit van uw API en het verkeer dat u verwacht. Algemene limieten worden ingesteld als het aantal oproepen per seconde, minuut of uur. U kunt bijvoorbeeld 1000 oproepen per minuut per gebruiker toestaan.
Als u snelheidslimieten voor uw API in Azure API Management wilt definiëren, gebruikt u de rate-limit of rate-limit-by-key beleidsregels. Het rate-limit beleid stelt een limiet in voor alle gebruikers. Het rate-limit-by-key beleid staat limieten toe per geïdentificeerde sleutel (zoals een abonnement of een gebruikers-id).
Hier volgt een voorbeeld van een beleid dat de aanroepen beperkt tot 1000 per minuut.
<policies>
<inbound>
<base />
<rate-limit calls="1000" renewal-period="60" />
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>
Wanneer u het opgegeven aantal aanroepen overschrijdt, verzendt Azure API Management een 429 Too Many Requests statuscode, samen met de retry-after antwoordheader en een bericht dat aangeeft wanneer u het opnieuw kunt proberen.
HTTP/1.1 429 Too Many Requests
content-type: application/json
retry-after: 60
{
"statusCode": 429,
"message": "Rate limit is exceeded. Try again in 60 seconds."
}
Frequentielimietinformatie beschikbaar maken voor antwoordheaders
Standaard biedt Azure API Management geen informatie over frequentielimieten voor antwoordheaders. Het niet communiceren van frequentielimieten maakt het moeilijk voor apps om te voorkomen dat de limiet wordt overschreden en aan beperkingen onderhevig worden. Als u informatie over frequentielimieten beschikbaar wilt maken, kunt u het rate-limit beleid uitbreiden met de remaining-calls-header-name en total-calls-header-name eigenschappen.
<policies>
<inbound>
<base />
<rate-limit calls="1000" renewal-period="60" remaining-calls-header-name="ratelimit-remaining" total-calls-header-name="ratelimit-limit" />
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>
Wanneer u uw API nu aanroept, bevat elk antwoord de ratelimit-remaining en ratelimit-limit headers. De headers communiceren hoeveel meer aanroepen de API kan verwerken voordat deze de limiet overschrijdt.
Samenvatting
Het implementeren van snelheidsbeperking in Azure API Management helpt u bij het maken van robuuste en schaalbare API's. Door snelheidsbeperking te gebruiken, kunt u ervoor zorgen dat uw API uw gebruikers betrouwbaar en efficiënt bedient. De sleutel is om het juiste evenwicht te vinden. Als een frequentielimiet te strikt is, kunt u de bruikbaarheid belemmeren. Als een frequentielimiet te soepel is, riskeert u uw API te overbelasten. Met zorgvuldige planning en continue bewaking kunt u dit evenwicht bereiken en een gezonde API-omgeving onderhouden.
Test uw klanten
Nadat u rate limiting voor uw API hebt geïmplementeerd, controleert u of de apps die uw API aanroepen, hier goed mee omgaan. Wanneer een client een limiet overschrijdt die is ingesteld door rate-limit of rate-limit-by-key, retourneert API Management 429 Too Many Requests met een Retry-After header. Clients die het negeren, blijven opnieuw proberen en blijven beperkt in requests.
| Approach | Wat u vindt | Wat u mist |
|---|---|---|
| Wachten op productieomgeving | Werkelijk cliëntgedrag | Elke defecte client, totdat de gebruikers ervan de limiet bereiken |
| Mock API Management in de tests van de klant | Of de opnieuw proberen-vertakking van de clienttoepassing wordt uitgevoerd | Uw werkelijke limieten, headers en resettiming, en de echte HTTP-stack van de client |
| Uw API Management-exemplaar aanroepen totdat deze snelheidsbeperking toepast | Feitelijk gedrag | U hebt een testinstantie nodig en u kunt niet op verzoek de limiet bereiken zonder API-aanroepen te verbruiken |
| Het verkeer van de client onderscheppen en uw limieten simuleren | Uw limiet, venster en headers op de echte API-URL en of de client wacht zo lang als zoals Retry-After aangeeft |
De code van de client op zichzelf. Bewaar unit tests daarvoor. |
Dev Proxy simuleert het snelheidsbeperkingsgedrag dat u hebt geconfigureerd, met dezelfde limiet, tijdvenster en antwoordheaders, terwijl de client-app uw echte API-URL blijft aanroepen. Gebruik de RateLimitingPlugin-functie met rateLimit en resetTimeWindowSeconds ingesteld op de calls en renewal-period van uw beleid, costPerRequest ingesteld op 1 (de standaardwaarde is 2, waardoor uw limiet wordt gehalveerd), en headerLimit en headerRemaining ingesteld op de headernamen uit uw beleid. Voeg RetryAfterPlugin ervoor toe, zodat Dev Proxy u vertelt wanneer een client te vroeg opnieuw een oproep doet. Zie API-reacties voor snelheidslimieten simuleren voor meer informatie. Om Dev Proxy te installeren, raadpleegt u Dev Proxy instellen.
- Rate limiting afhandelen: aanbevolen procedures voor client-apps