Ograniczenie liczby żądań

Wyświetlasz dokumentację Apigee Edge.
Przejdź do dokumentacji Apigee X.
info

Aby zachować wydajność i dostępność w przypadku różnych aplikacji klienckich, ważne jest aby ruch aplikacji mieścił się w granicach możliwości interfejsów API i usług backendu. Ważne jest też, aby aplikacje nie zużywały więcej zasobów niż jest to dozwolone.

Apigee Edge udostępnia 2 mechanizmy, które umożliwiają optymalizację zarządzania ruchem w celu zminimalizowania opóźnień w aplikacjach przy jednoczesnym zachowaniu kondycji usług backendu. Każdy typ zasady dotyczy innego aspektu zarządzania ruchem. W niektórych przypadkach możesz używać obu typów zasad w jednym serwerze proxy interfejsu API.

Obejrzyj ten film, aby zapoznać się z zasadami zarządzania ruchem interfejsu API.

SpikeArrest

Ta zasada wygładza skoki ruchu, dzieląc zdefiniowany limit na mniejsze interwały. Jeśli na przykład zdefiniujesz limit 100 wiadomości na sekundę, zasada SpikeArrest będzie wymuszać a limit około 1 żądania co 10 milisekund (1000 / 100), a 30 wiadomości na minutę zostanie wygładzone do około 1 żądania co 2 sekundy (60 / 30). Limit SpikeArrest powinien być zbliżony do pojemności obliczonej dla usługi backendu lub samego serwera proxy interfejsu API. Limit należy też skonfigurować dla krótszych interwałów, np. sekund lub minut. Ta zasada powinna być używana do zapobiegania nagłym wzrostom ruchu spowodowanym przez złośliwych atakujących, którzy próbują zakłócić działanie usługi za pomocą ataku typu DoS, lub przez wadliwe aplikacje klienckie.

Zobacz zasadę SpikeArrest.

Quota

Ta zasada wymusza limity zużycia w aplikacjach klienckich, utrzymując rozproszony „licznik” który zlicza przychodzące żądania. Licznik może zliczać wywołania interfejsu API dla dowolnego identyfikowalnego podmiotu, w tym aplikacji, deweloperów, kluczy interfejsu API, tokenów dostępu itp. Do identyfikowania aplikacji klienckich zwykle używa się kluczy interfejsu API. Ta zasada jest kosztowna obliczeniowo, dlatego w przypadku interfejsów API o dużym natężeniu ruchu należy ją skonfigurować na dłuższe interwały, np. dzień lub miesiąc. Ta zasada powinna być używana do egzekwowania umów handlowych lub umów SLA z deweloperami i partnerami, a nie do operacyjnego zarządzania ruchem.

Zobacz zasadę dotyczącą limitu.