Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje
Aby utrzymać wydajność i dostępność w różnych bazach aplikacji klienckich, trzeba pilnować, aby ruch do aplikacji nie przekraczał 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 czasu oczekiwania aplikacji oraz utrzymania sprawności 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 film wprowadzający do zasad zarządzania ruchem w interfejsie API.
SpikeArrest
Ta zasada ogranicza gwałtowne skoki natężenia ruchu, dzieląc zdefiniowany przez Ciebie limit na mniejsze przedziały czasu. Jeśli na przykład zdefiniujesz limit 100 wiadomości na sekundę, zasada SpikeArrest wymusza limit wynoszący około 1 żądania na 10 milisekund (1000 / 100), a 30 wiadomości na minutę zostanie przekształcone w około 1 żądanie 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 przedziałów czasu, np. sekund lub minut. Ta zasada powinna służyć do zapobiegania nagłym wzrostom ruchu spowodowanym przez złośliwych ataków usiłujących zakłócić działanie usługi za pomocą ataku typu DoS lub błędów w aplikacjach klienckich.
Zapoznaj się z zasadami SpikeArrest.
Limit
Ta zasada wymusza limity wykorzystania w aplikacjach klienckich przez utrzymywanie rozproszonego „licznika”, który zlicza żądania przychodzące. Licznik może zliczać wywołania interfejsu API dowolnego możliwego do zidentyfikowania podmiotu, m.in. aplikacji, deweloperów, kluczy interfejsu API i tokenów dostępu. Zwykle klucze interfejsu API służą do identyfikowania aplikacji klienckich. Ta zasada jest kosztowna pod względem obliczeń, dlatego w przypadku interfejsów API generujących duży ruch należy skonfigurować ją na dłuższe przedziały czasu, na przykład dzień lub miesiąc. Ta zasada powinna służyć do egzekwowania umów biznesowych lub gwarancji jakości usług z deweloperami i partnerami, a nie do operacyjnego zarządzania ruchem.
Zobacz Zasady dotyczące limitów.