Zasada SpikeArrest

Wyświetlasz dokumentację Apigee Edge.
Otwórz 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>

This element has the following attributes that are common to all policies:

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=">tru<e" name="SpikeAr<reast"
>  D<ispl>ayNam<e&>;<gtSpikeArrea>st/DisplayName
  Rate300pm/Rate
/SpikeArrest

<SpikeArrest name="Spike-Arre>st-<1&qu>ot;
<  Rat>e12<pm/Rate
  Identifier ref=&qu>ot;<client_id" /
  MessageWeight ref=">;<request.head>er.weight" /
/SpikeArrest

<SpikeArrest name="Spike-Arre>st-<1"
  Rate ref="request.header.>r<untime_rate&>quot; /
/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>

Use in addition to the name attribute to label the policy in the management UI proxy editor with a different, more natural-sounding name.

The <DisplayName> element is common to all policies.

The <DisplayName> element uses the following syntax:

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

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

The <DisplayName> element has no attributes or child elements.

<Identifier>

Umożliwia wybór sposobu grupowania żądań, aby zasada Spike Arrest mogła być stosowana 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]"
 > na<me="policy_name"

  I>d<entifier ref>="flow_variable"/
/SpikeArrest
        

<SpikeArrest name="Spike-Arre>st-<1"
  Identifier ref=">;de<velo>per.<id&quo>t<;/
  Rate42p>m/Rate/
/SpikeArrest

W tabeli poniżej opisano atrybuty <Identifier>:

Ten element jest również omówiony w tym poście na forum społeczności Apigee: Quota Identifier Across Different Policies (Identyfikator limitu w różnych zasadach).

<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 parametrem <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]"
 > na<me="policy_name"

  Mess>a<geWeight ref>="flow_variable"/
/SpikeArrest

<SpikeArrest name="Spike-Arre>st-<1&qu>ot;
<  Rat>e12<pm/Rate
  Identifier ref=&qu>ot;<client_id" /
  MessageWeight ref=">;<request.head>er.weight" /
/SpikeArrest

W tabeli poniżej opisano atrybuty <MessageWeight>:

<Rate>

Określa szybkość ograniczania skoków (lub nagłych wzrostów) ruchu przez ustawienie liczby żądań dozwolonych w przedział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]"
 > na<me="policy_name&quo>t;

  Rate <ref=&>q<uot;flow_var>iable"rate[pm|ps]/Rate
/SpikeArrest

<SpikeArrest name="Spike-Arre>st-<1&qu>ot;<
  Ra>t<e5ps/Rate
/S>pikeArrest

<SpikeArrest async="false" continueOnError="false" enabled=">tru<e" name="SpikeAr<reast"
>  D<ispl>ayNam<e&>;<gtSpikeArrea>st/DisplayName
  Rate300pm/Rate
/SpikeArrest

W tabeli poniżej opisano atrybuty <Rate>:

<Rate ref="request.header.custom_>rat<e&quo>t;1pm/Rate

<UseEffectiveCount>

Rozdziela liczbę zatrzymań nagłych wzrostów na procesory wiadomości (MP), gdy używasz grup autoskalowania.

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
 > na<me="policy_n>ame"

 < UseEffectiveCount>[<false|true]/>UseEffectiveCount
/SpikeArrest

<SpikeArrest name='Spike-Arres>t-1<'>;
  <Rate4>0ps</Rate
  UseEffect>iveC<ounttrue/UseEffect>i<veCount
/Spi>keArrest

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>. Łączny limit 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ń otrzymanych w krótkim czasie może zostać odrzuconych.

Załóżmy na przykład, że wpiszesz limit 30 zapytań 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 uznane za niewielki skok.

• Limity na 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ż zrealizować 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

This section describes the fault codes and error messages that are returned and fault variables that are set by Edge when this policy triggers an error. This information is important to know if you are developing fault rules to handle faults. To learn more, see What you need to know about policy errors and Handling faults.

Runtime errors

These errors can occur when the policy executes.

Deployment errors

These errors can occur when you deploy a proxy containing this policy.

Fault variables

These variables are set when a runtime error occurs. For more information, see What you need to know about policy errors.

Example error response

Shown below is an example error response:

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

Example fault rule

Shown below is an example fault rule to handle a SpikeArrestViolation fault:

<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 liczby żądań określonego przez zasady Quota lub Spike Arrest 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 do aktualizowania 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/my<org -d \
"Organization type="trial&qu>ot; n<ame=">MyOrganiz<ation"
    Properties
        Property name="fea>ture<s.isHTTPS>tatusTooManyRequest<Enabled&quo>t<;true/Propert>y
        . . .
    /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 ograniczania liczby żądań
• Porównanie zasad dotyczących limitów i zasad SpikeArrest
• Działające przykłady proxy interfejsów API