Zasada SpikeArrest

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

Zasada Spike Arrest chroni przed wzrostem natężenia ruchu dzięki elementowi <Rate>. Ten element ogranicza liczbę żądań przetwarzanych przez serwer proxy interfejsu API i wysyłanych do backendu, chroniąc przed opóźnieniami w działaniu i przestojami.

Element <SpikeArrest>

Definiuje zasadę dotyczącą 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ą, w jaki sposób można korzystać z zasady aresztowania agresywnego:

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

<SpikeArrest name="Spike-Arrest-1">
  <Rate>12pm</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'

Odniesienie do elementu podrzędnego

W tej sekcji opisano elementy podrzędne funkcji <SpikeArrest>.

<DisplayName>

Użyj oprócz atrybutu name, aby oznaczyć zasadę w edytorze serwera proxy interfejsu zarządzania inną, bardziej naturalną nazwą.

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

W elemencie <DisplayName> używana jest taka składnia:

<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>

Pozwala wybrać sposób grupowania żądań, aby można było stosować zasadę Spike Arrest zależnie od klienta. Możesz na przykład pogrupować żądania według identyfikatora dewelopera. W takim przypadku żądania każdego dewelopera będą wliczane do jego własnego wskaźnika tymczasowego aresztowania, a nie do wszystkich żądań wysyłanych do serwera proxy.

Aby uzyskać bardziej szczegółową kontrolę nad ograniczaniem żądań, używaj ich w połączeniu z elementem <MessageWeight>.

Jeśli pozostawisz element <Identifier> pusty, dla wszystkich żądań wysyłanych do tego serwera proxy interfejsu API będzie egzekwowany jeden limit liczby żądań.

<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>

Poniższa tabela opisuje atrybuty <Identifier>:

Ten element został również 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ę określoną dla każdej wiadomości. Waga wiadomości zmienia wpływ pojedynczego żądania na obliczanie częstotliwości aresztowania wiadomości. Waga wiadomości może być dowolną zmienną przepływu, taką jak nagłówek HTTP, parametr zapytania, parametr formularza lub treść wiadomości. Możesz też używać zmiennych niestandardowych za pomocą zasad JavaScriptu lub zasady AssignMessage.

Używaj w połączeniu z <Identifier>, aby jeszcze bardziej ograniczać żądania pochodzące od konkretnych klientów lub aplikacji.

Jeśli na przykład wskaźnik Spike Arrest <Rate> ma wartość 10pm, a aplikacja przesyła żądania o wadze 2, to klient może wysłać 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>

Poniższa tabela opisuje atrybuty <MessageWeight>:

<Rate>

Określa częstotliwość, z jaką chcesz ograniczać nagłe skoki (lub impulsy) ruchu, ustawiając liczbę dozwolonych żądań w interwałach na minutę lub sekundę. Tego elementu możesz też używać w połączeniu z elementami <Identifier> i <MessageWeight>, aby płynnie ograniczać ruch w czasie działania przez akceptowanie 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 name="Spike-Arrest-1">
  <Rate>12pm</Rate>
</SpikeArrest>

Poniższa tabela opisuje atrybuty <Rate>:

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

<UseEffectiveCount>

Podczas korzystania z grup autoskalowania rozdziela liczbę węzłów Spike Arrest między procesory wiadomości (MP).

<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ścią domyślną jest false, gdy element jest pominięty w zasadach dotyczących aresztowania Spike’s.

Tabela poniżej zawiera opis atrybutów elementu <UseEffectiveCount>:

Efekt działania funkcji <UseEffectiveCount> zależy od jej wartości:

• true: limit szybkości wzrostu MP to wartość <Rate> podzielona przez aktualną liczbę Mpix w tym samym podzie. Limit zbiorczy to wartość <Rate>. Gdy MP są dodawane (lub usuwane), ich indywidualne limity częstotliwości wzrosną (lub zmaleją), ale łączny limit się nie zmieni.
• false (wartość domyślna, jeśli zostanie pominięta): limit szybkości wzrostu każdego MP to po prostu wartość jego <Rate>. Łączny limit to suma stawek wszystkich cen ofertowych. Po dodaniu (lub usunięciu MP) limity liczby żądań skokowych nie zmienią się, ale łączny limit się zwiększy (lub zmaleje).

W tabeli poniżej pokazujemy wpływ zasady <UseEffectiveCount> na limit efektywnej szybkości transmisji bitów każdego Mpix:

Zwróć uwagę, że w tym przykładzie, gdy liczba Mpix zostanie zmniejszona z 4 do 2, a <UseEffectiveCount> wynosi false, efektywna stawka na Mpix pozostanie taka sama (przy wartości 10). Jednak gdy <UseEffectiveCount> wynosi true, efektywna stawka na Mpx wzrośnie z 10 do 20 po zmniejszeniu liczby Mpix z 4 do 2.

Zmienne przepływu

Po uruchomieniu zasady Spike Arrest wypełniana jest taka zmienna przepływu:

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

Informacje o błędach

W tej sekcji opisujemy kody błędów i komunikaty o błędach, które są zwracane, a także zmienne błędów ustawiane przez Edge, gdy ta zasada aktywuje błąd. Te informacje są ważne, jeśli opracowujesz reguły dotyczące błędów do obsługi takich błędów. Więcej informacji znajdziesz w sekcjach Co musisz wiedzieć o błędach zasad i Postępowanie w przypadku błędów.

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 te zasady.

Zmienne błędów

Te zmienne są ustawiane, gdy wystąpi błąd środowiska wykonawczego. Więcej informacji znajdziesz w artykule Co musisz wiedzieć o błędach związanych z naruszeniem zasad.

Przykładowa odpowiedź na błąd

Poniżej znajduje się przykładowa odpowiedź o błędzie:

{  
   "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 dotycząca błędu w przypadku 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>

Bieżący kod stanu HTTP oznaczający przekroczenie limitu liczby żądań ustawionego przez zasadę limitu lub Spike Arrest to 429 (zbyt wiele żądań). Aby zmienić kod stanu HTTP na 500 (wewnętrzny błąd serwera), ustaw właściwość features.isHTTPStatusTooManyRequestEnabled na false za pomocą interfejsu API 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/myorg -d \
"<Organization type="trial" name="MyOrganization">
    <Properties>
        <Property name="features.isHTTPStatusTooManyRequestEnabled">true</Property>
        . . .
    </Properties>
</Organization>"

Schematy

Każdy typ zasady jest definiowany 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 ruchu w przypadku pojedynczych klientów
• Omówienie ograniczeń liczby żądań
• Porównanie zasad dotyczących limitów i SpikeArrest
• Przykładowe działanie serwerów proxy interfejsów API