Zasada SpikeArrest

Wyświetlasz dokumentację Apigee Edge.
Zapoznaj się z dokumentacją Apigee X. info

Zasada Spike Arrest chroni przed nagłymi wzrostami ruchu za pomocą elementu <Rate>. Ten element ogranicza liczbę żądań przetwarzanych przez serwer proxy interfejsu API i wysyłanych do backendu, chroniąc przed opóźnieniami i przestojami.

Element <SpikeArrest>

Definiuje zasadę Spike Arrest.

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <DisplayName>display_name</DisplayName>
  <Properties/>
  <Identifier ref="flow_variable"/>
  <MessageWeight ref="flow_variable"/>
  <Rate ref="flow_variable">rate[pm|ps]</Rate>
  <UseEffectiveCount>[false|true]</UseEffectiveCount>
</SpikeArrest>

<SpikeArrest async="false" continueOnError="false" enabled="true" name="Spike-Arrest-1">
  <DisplayName>Spike Arrest-1</DisplayName>
  <Properties/>
  <Identifier ref="request.header.some-header-name"/>
  <MessageWeight ref="request.header.weight"/>
  <Rate>30ps</Rate>
  <UseEffectiveCount>true</UseEffectiveCount>
</SpikeArrest>

Ten element ma te atrybuty, które są wspólne dla wszystkich zasad:

Przykłady

Poniższe przykłady pokazują, jak można używać zasady Spike Arrest:

<SpikeArrest name="Spike-Arrest-1">
  <Rate>5ps</Rate>
</SpikeArrest>

<SpikeArrest async="false" continueOnError="false" enabled="true" name="SpikeArreast">
  <DisplayName>SpikeArreast</DisplayName>
  <Rate>300pm</Rate>
</SpikeArrest>

<SpikeArrest name="Spike-Arrest-1">
  <Rate>12pm</Rate>
  <Identifier ref="client_id" />
  <MessageWeight ref="request.header.weight" />
</SpikeArrest>

<SpikeArrest name="Spike-Arrest-1">
  <Rate ref="request.header.runtime_rate" />
</SpikeArrest>

curl http://myorg-myenv.apigee.net/price -H 'runtime_rate:30ps'

Odwołanie do elementu podrzędnego

W tej sekcji opisujemy elementy podrzędne elementu <SpikeArrest>.

<DisplayName>

Używaj tego atrybutu w połączeniu z atrybutem name, aby oznaczyć zasadę w edytorze proxy interfejsu zarządzania inną, bardziej naturalnie brzmiącą nazwą.

Element <DisplayName> jest wspólny dla wszystkich zasad.

Element <DisplayName> ma tę składnię:

<PolicyElement>
  <DisplayName>policy_display_name</DisplayName>
  ...
</PolicyElement>

<PolicyElement>
  <DisplayName>My Validation Policy</DisplayName>
</PolicyElement>

Element <DisplayName> nie ma atrybutów ani elementów podrzędnych.

<Identifier>

Umożliwia wybór sposobu grupowania żądań, aby można było zastosować zasadę Spike Arrest na podstawie klienta. Możesz na przykład grupować żądania według identyfikatora dewelopera. W takim przypadku żądania każdego dewelopera będą wliczane do jego własnego limitu Spike Arrest, a nie do wszystkich żądań wysyłanych do serwera proxy.

Używaj w połączeniu z elementem <MessageWeight>, aby uzyskać większą kontrolę nad ograniczaniem liczby żądań.

Jeśli pozostawisz element <Identifier> pusty, dla wszystkich żądań do tego serwera proxy interfejsu API będzie obowiązywać jeden limit szybkości.

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <Identifier ref="flow_variable"/>
</SpikeArrest>
        

<SpikeArrest name="Spike-Arrest-1">
  <Identifier ref="developer.id"/>
  <Rate>42pm</Rate/>
</SpikeArrest>

W tabeli poniżej opisano atrybuty <Identifier>:

Ten element został też omówiony w tym poście na forum społeczności Apigee: http://community.apigee.com/questions/2807/how-does-the-edge-quota-policy-work-when-no-identi.html.

<MessageWeight>

Określa wagę zdefiniowaną dla każdego komunikatu. Waga wiadomości modyfikuje wpływ pojedynczego żądania na obliczanie współczynnika zapobiegania nagłym wzrostom. Waga wiadomości może być dowolną zmienną przepływu, np. nagłówkiem HTTP, parametrem zapytania, parametrem formularza lub treścią wiadomości. Możesz też używać zmiennych niestandardowych za pomocą zasady JavaScript lub zasady AssignMessage.

Używaj w połączeniu z <Identifier>, aby dodatkowo ograniczać liczbę żądań od konkretnych klientów lub aplikacji.

Jeśli na przykład limit nagłych wzrostów <Rate> wynosi 10pm, a aplikacja przesyła żądania o wadze 2, to z tego klienta dozwolonych jest tylko 5 wiadomości na minutę, ponieważ każde żądanie liczy się jako 2.

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <MessageWeight ref="flow_variable"/>
</SpikeArrest>

<SpikeArrest name="Spike-Arrest-1">
  <Rate>12pm</Rate>
  <Identifier ref="client_id" />
  <MessageWeight ref="request.header.weight" />
</SpikeArrest>

W tabeli poniżej opisano atrybuty <MessageWeight>:

<Rate>

Określa szybkość, z jaką należy ograniczać skoki (lub nagłe wzrosty) ruchu, ustawiając liczbę żądań dozwolonych w interwałach minutowych lub sekundowych. Możesz też użyć tego elementu w połączeniu z <Identifier> i <MessageWeight>, aby płynnie ograniczać ruch w czasie działania programu, akceptując wartości od klienta.

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <Rate ref="flow_variable">rate[pm|ps]</Rate>
</SpikeArrest>

<SpikeArrest name="Spike-Arrest-1">
  <Rate>5ps</Rate>
</SpikeArrest>

<SpikeArrest async="false" continueOnError="false" enabled="true" name="SpikeArreast">
  <DisplayName>SpikeArreast</DisplayName>
  <Rate>300pm</Rate>
</SpikeArrest>

W tabeli poniżej opisano atrybuty <Rate>:

<Rate ref="request.header.custom_rate">1pm</Rate>

<UseEffectiveCount>

Rozdziela liczbę zatrzymań nagłych wzrostów na procesory wiadomości (MP) w przypadku korzystania z grup autoskalowania.

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <UseEffectiveCount>[false|true]</UseEffectiveCount>
</SpikeArrest>

<SpikeArrest name='Spike-Arrest-1'>
  <Rate>40ps</Rate>
  <UseEffectiveCount>true</UseEffectiveCount>
</SpikeArrest>

Element <UseEffectiveCount> jest opcjonalny. Wartość domyślna to false, gdy element jest pominięty w zasadach ochrony przed nagłymi wzrostami ruchu.

W tej tabeli opisujemy atrybuty elementu <UseEffectiveCount>:

Wpływ wartości <UseEffectiveCount> zależy od jej wartości:

• true: limit częstotliwości skoków MP to <Rate> podzielony przez bieżącą liczbę MP w tym samym podzie. Łączny limit to wartość <Rate>. Gdy moduły MP są dynamicznie dodawane (lub usuwane), ich indywidualne limity szybkości wzrastają (lub maleją), ale łączny limit pozostaje bez zmian.
• false: limit szybkości wzrostu każdego MP to po prostu wartość jego parametru <Rate>. Limit łączny to suma stawek wszystkich MP. Gdy dodasz (lub usuniesz) MP, ich indywidualne limity szybkości pozostaną bez zmian, ale łączny limit wzrośnie (lub zmaleje).

Zasada SpikeArrest korzysta z algorytmu „token bucket”, który wygładza skoki ruchu, dzieląc określony limit szybkości na mniejsze przedziały. Wadą tego podejścia jest to, że wiele prawidłowych żądań przychodzących w krótkim odstępie czasu może zostać odrzuconych.

Załóżmy, że wpiszesz wartość 30pm (30 żądań na minutę). Podczas testowania możesz sądzić, że możesz wysłać 30 żądań w ciągu 1 sekundy, o ile zmieszczą się one w ciągu minuty. Ale zasady nie wymuszają tego ustawienia w ten sposób. 30 żądań w ciągu 1 sekundy może być w niektórych środowiskach uznawane za niewielki skok.

• Stawki za minutę są uśredniane do pełnych żądań dozwolonych w przedziałach sekund.
  

  Na przykład 30 żądań na minutę jest wygładzane w ten sposób:
  60 sekund (1 minuta) / 30 żądań na minutę = interwały 2-sekundowe, czyli 1 żądanie co 2 sekundy. Drugie żądanie w ciągu 2 sekund zostanie odrzucone. 31 żądanie w ciągu minuty również zakończy się niepowodzeniem.

• Stawki na sekundę są uśredniane do pełnych żądań dozwolonych w przedziałach milisekund.

  Na przykład 10ps jest wygładzane w ten sposób:
  1000 milisekund (1 sekunda) / 10ps = odstępy 100 milisekund, czyli 1 żądanie co 100 milisekund. Drugie żądanie w ciągu 100 ms zostanie odrzucone. Nie uda się też wysłać 11 żądania w ciągu sekundy.

W tabeli poniżej przedstawiono wpływ wartości <UseEffectiveCount> na efektywny limit stawek poszczególnych platform handlowych:

Zwróć uwagę, że w tym przykładzie, gdy liczba punktów MP zmniejsza się z 4 do 2, a <UseEffectiveCount> jest równe false, efektywna stawka za punkt MP pozostaje taka sama (10). Gdy jednak <UseEffectiveCount> wynosi true, efektywna stawka za MP wzrasta z 10 do 20, gdy liczba MP zmniejsza się z 4 do 2.

Zmienne przepływu

Gdy zasada Spike Arrest zostanie wykonana, zostanie wypełniona ta zmienna przepływu:

Więcej informacji znajdziesz w dokumentacji zmiennych przepływu.

Odniesienie do błędu

W tej sekcji opisano zwracane kody błędów i komunikaty o błędach oraz zmienne błędów ustawiane przez Edge, gdy ta zasada wywołuje błąd. Warto o tym wiedzieć, jeśli rozwijasz reguły błędów, aby obsługi błędów. Więcej informacji: Niezbędne informacje o błędach związanych z zasadami i postępowaniu z błędami

Błędy w czasie wykonywania

Te błędy mogą wystąpić podczas wykonywania zasady.

Błędy wdrażania

Te błędy mogą wystąpić podczas wdrażania serwera proxy zawierającego tę zasadę.

Zmienne błędów

Te zmienne są ustawiane po wystąpieniu błędu działania. Więcej informacji znajdziesz w artykule Podstawowe informacje o błędach związanych z naruszeniem zasad.

Przykładowa odpowiedź na błąd

Poniżej znajdziesz przykładową odpowiedź na błąd:

{  
   "fault":{  
      "detail":{  
         "errorcode":"policies.ratelimit.SpikeArrestViolation"
      },
      "faultstring":"Spike arrest violation. Allowed rate : 10ps"
   }
}

Przykładowa reguła błędu

Poniżej znajduje się przykładowa reguła błędu obsługi błędu SpikeArrestViolation:

<FaultRules>
    <FaultRule name="Spike Arrest Errors">
        <Step>
            <Name>JavaScript-1</Name>
            <Condition>(fault.name Matches "SpikeArrestViolation") </Condition>
        </Step>
        <Condition>ratelimit.Spike-Arrest-1.failed=true</Condition>
    </FaultRule>
</FaultRules>

Obecny kod stanu HTTP w przypadku przekroczenia limitu szybkości określonego przez zasadę dotyczącą limitu lub ochrony przed nagłymi wzrostami to 429 (Za dużo żądań). Aby zmienić kod stanu HTTP na 500 (wewnętrzny błąd serwera), ustaw wartość właściwości features.isHTTPStatusTooManyRequestEnabled na false za pomocą interfejsu API Aktualizowanie właściwości organizacji.

Na przykład:

curl -u email:password -X POST -H "Content-type:application/xml" http://api.enterprise.apigee.com/v1/organizations/myorg -d \
"<Organization type="trial" name="MyOrganization">
    <Properties>
        <Property name="features.isHTTPStatusTooManyRequestEnabled">true</Property>
        . . .
    </Properties>
</Organization>"

Schematy

Każdy typ zasad jest zdefiniowany przez schemat XML (.xsd). Schematy zasad są dostępne na GitHubie.

Powiązane artykuły

• Zasady dotyczące limitów: zasady dotyczące limitów, które ograniczają ruch na poszczególnych klientach.
• Ograniczanie liczby żądań – omówienie ograniczeń liczby żądań
• Porównanie zasad dotyczących limitów i zasad SpikeArrest
• Działające przykłady serwerów proxy interfejsu API