Zasady dotyczące limitów

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

Co

Zasada dotycząca limitu pozwala skonfigurować liczbę wiadomości z żądaniami, na które serwer proxy interfejsu API zezwala w danym okresie, takim jak minuta, godzina, dzień, tydzień lub miesiąc. Możesz ustawić taki sam limit dla wszystkich aplikacji uzyskujących dostęp do serwera proxy interfejsu API lub możesz go ustawić na podstawie:

• Usługa, która zawiera serwer proxy interfejsu API
• Aplikacja żądająca interfejsu API
• Deweloper aplikacji
• Wiele innych kryteriów

Nie używaj limitu do ochrony przed ogólnym wzrostem natężenia ruchu. W tym celu użyj zasady Spike Arrest. Zobacz zasady dotyczące aresztowania nabojów.

Filmy

Te filmy przedstawiają zarządzanie limitami z użyciem zasad dotyczących limitów:

Przykłady

Te przykładowe fragmenty kodu zasad pokazują, jak rozpocząć i zakończyć okresy limitów przez:

<Quota name="CheckQuota"> 
  <Interval ref="verifyapikey.verify-api-key.apiproduct.developer.quota.interval">1</Interval>
  <TimeUnit ref="verifyapikey.verify-api-key.apiproduct.developer.quota.timeunit">hour</TimeUnit>
  <Allow count="200" countRef="verifyapikey.verify-api-key.apiproduct.developer.quota.limit"/>
</Quota>

<Quota name="DeveloperQuota"> 
  <Identifier ref="verifyapikey.verify-api-key.client_id"/> 
  <Interval ref="verifyapikey.verify-api-key.developer.timeInterval"/> 
  <TimeUnit ref="verifyapikey.verify-api-key.developer.timeUnit"/> 
  <Allow countRef="verifyapikey.verify-api-key.developer.limit"/> 
</Quota>

<Quota name="QuotaPolicy" type="calendar">
  <StartTime>2017-02-18 10:30:00</StartTime>
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

<Quota name="QuotaPolicy">
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

<AssignMessage async="false" continueOnError="false" enabled="true" name="ReturnQuotaVars">
    <AssignTo createNew="false" type="response"/>
    <Set>
        <Headers>
            <Header name="QuotaLimit">{ratelimit.QuotaPolicy.allowed.count}</Header>
            <Header name="QuotaUsed">{ratelimit.QuotaPolicy.used.count}</Header>
            <Header name="QuotaResetUTC">{ratelimit.QuotaPolicy.expiry.time}</Header>
        </Headers>
    </Set>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
</AssignMessage>

<Quota name="MyQuota">
  <Interval>1</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="10000"/>
</Quota>

<Quota name="QuotaPolicy" type="calendar">
  <Identifier ref="request.header.clientId"/> 
  <StartTime>2017-02-18 10:00:00</StartTime>
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

<Identifier ref="request.queryparam.id"/>

<Identifier ref="verifyapikey.verify-api-key.client_id"></Identifier>

<Quota name="QuotaPolicy">
  <Interval>1</Interval>
  <TimeUnit>day</TimeUnit>
  <Allow>
    <Class ref="request.header.developer_segment">
      <Allow class="platinum" count="10000"/>
      <Allow class="silver" count="1000" />
    </Class>
  </Allow>
</Quota>

Informacje o zasadach dotyczących limitów

Limit to przydział wiadomości z żądaniami, które może obsłużyć serwer proxy interfejsu API w danym okresie, na przykład minuta, godzina, dzień, tydzień lub miesiąc. Zasada utrzymuje liczniki, które zliczają liczbę żądań otrzymanych przez serwer proxy interfejsu API. Dzięki temu dostawcy interfejsów API mogą egzekwować limity liczby wywołań interfejsu API wysyłanych przez aplikacje w danym okresie. Zasady dotyczące limitów pozwalają na przykład ograniczyć liczbę żądań aplikacji do 1 żądania na minutę lub do 10 000 żądań na miesiąc.

Jeśli na przykład limit jest zdefiniowany jako 10 000 wiadomości na miesiąc, ograniczanie liczby żądań rozpocznie się po 10 000 wiadomości. Nie ma znaczenia,czy 10 000 wiadomości zostało zliczonych pierwszego czy ostatniego dnia tego okresu. Nie jest dozwolony dodatkowy obszar żądań, dopóki licznik limitu nie zostanie automatycznie zresetowany na końcu określonego przedziału czasu lub do momentu wyraźnego zresetowania limitu za pomocą zasady resetowania limitu.

Zmienność limitu o nazwie SpikeArrest zapobiega gwałtownym wzrostom (lub wzrostom) ruchu, które mogą być spowodowane nagłym wzrostem wykorzystania, nieprawidłowymi klientami lub złośliwymi atakami. Więcej informacji o SpikeArrest znajdziesz w zasadach dotyczących aresztowania na papierze.

Limity dotyczą poszczególnych serwerów proxy interfejsów API i nie są rozłożone na serwery proxy tego interfejsu. Jeśli na przykład w usłudze API masz 3 serwery proxy interfejsów API, pojedynczy limit nie będzie wspólny dla tych usług, nawet jeśli wszystkie z nich korzystają z tej samej konfiguracji zasad limitów.

Typy zasad dotyczących limitów

Zasada dotycząca limitu obsługuje kilka różnych typów zasad: domyślny, calendar, flexi i rollingwindow. Każdy typ określa, kiedy uruchamia się licznik limitów, a kiedy resetuje się, jak w tej tabeli:

Jako type="calendar" musisz podać wartość <StartTime>.

W tabeli nie ma wartości typu rollingwindow. Limity okresów zmieniających działają przez ustawienie rozmiaru „okna” limitu, na przykład okna 1 godziny lub 1 dnia. Gdy pojawia się nowe żądanie, zasada określa, czy limit został przekroczony w minionym „okresie”.

Możesz np. zdefiniować dwugodzinny przedział, w którym można przesłać 1000 żądań. Nowe żądanie przychodzi o 16:45.Zasada oblicza limit dla ostatnich 2 godzin, czyli liczbę żądań od 14:45. Jeśli limit nie został przekroczony w tym dwugodzinnym okresie, prośba jest dopuszczana.

Po minucie, o 16:46, przychodzi kolejna prośba. Teraz zasada oblicza limit od godziny 14:46, aby ustalić, czy limit został przekroczony.

W przypadku typu rollingwindow licznik nigdy nie resetuje się, ale jest przeliczany po każdym żądaniu.

Informacje o licznikach limitów

Domyślnie zasada dotycząca limitu utrzymuje 1 licznik niezależnie od tego, ile razy odwołuje się do niego na serwerze proxy interfejsu API. Nazwa licznika limitów zależy od atrybutu name zasady.

Możesz na przykład utworzyć zasadę limitu o nazwie MyQuotaPolicy z limitem 5 żądań i umieścić ją w wielu przepływach (proces A, B i C) w serwerze proxy interfejsu API. Mimo że jest używana w wielu przepływach, utrzymuje jeden licznik, który jest aktualizowany przez wszystkie instancje zasady:

• Przepływ A jest wykonywany -> wykonywana jest zasada MylimitPolicy, a jej licznik = 1
• Przepływ B jest wykonywany -> wykonywana jest zasada MylimitPolicy, a jej licznik = 2
• Przepływ A jest wykonywany -> wykonywana jest zasada MylimitPolicy, a jej licznik = 3
• Przepływ C jest wykonywany -> wykonywana jest zasada MylimitPolicy, a jej licznik = 4
• Przepływ A jest wykonywany -> wykonywana jest zasada MyQuotaPolicy, a jej licznik = 5

Następne żądanie do dowolnego z 3 przepływów zostało odrzucone, ponieważ licznik limitów osiągnął limit.

Używanie tych samych zasad dotyczących limitów w więcej niż 1 miejscu w procesie serwera proxy interfejsu API, które może nieumyślnie powodować szybsze wyczerpanie limitu, jest niezgodne z wzorcem opisanym w artykule The Book of Apigee Edge Antipatterns.

Możesz też zdefiniować wiele zasad dotyczących limitów na serwerze proxy interfejsu API i używać innych zasad w każdym procesie. Każda zasada dotycząca limitów ma własny licznik oparty na atrybucie name zasady.

Możesz też użyć elementów <Class> lub <Identifier> w zasadzie limitu, aby zdefiniować wiele unikalnych liczników w jednej zasadzie. Dzięki tym elementom jedna zasada może zachowywać różne liczniki m.in. m.in. od aplikacji wysyłającej żądanie, od dewelopera aplikacji tworzącego żądanie, identyfikatora klienta lub innego identyfikatora klienta. Więcej informacji o używaniu elementów <Class> i <Identifier> znajdziesz w przykładach powyżej.

Zapis czasu

Wszystkie wartości czasu limitu są ustawione według strefy czasowej uniwersalnego czasu koordynowanego (UTC).

Zapis czasu limitu jest zgodny z międzynarodowym standardem daty zgodnym z normą międzynarodową ISO 8601.

Daty definiuje się jako rok, miesiąc i dzień w tym formacie: YYYY-MM-DD. Na przykład 2015-02-04 oznacza 4 lutego 2015 r.

Pora dnia jest określana jako godziny, minuty i sekundy w tym formacie: hours:minutes:seconds. Na przykład 23:59:59 oznacza czas wynoszący 1 sekundę do północy.

Dostępne są 2 notacje: 00:00:00 i 24:00:00, które pozwalają rozróżnić północ, które można powiązać z jedną datą. Dlatego 2015-02-04 24:00:00 jest tą samą datą i godziną co 2015-02-05 00:00:00. Zazwyczaj jest to preferowany zapis.

Pobieram ustawienia limitu z konfiguracji usługi API

Limity możesz ustawiać w konfiguracjach usług interfejsu API. Te limity nie wymuszają automatycznego przestrzegania limitu. Zamiast tego możesz odwoływać się do ustawień limitów produktów w zasadach limitów. Oto kilka korzyści związanych z ustawieniem limitu w usłudze, do którego można się odnieść dzięki zasadom limitów:

• Zasady limitów mogą używać jednolitych ustawień we wszystkich serwerach proxy API w usłudze API.
• W środowisku wykonawczym możesz zmienić ustawienie limitu usługi API, a zasady limitów, które odwołują się do tej wartości, mają automatycznie zaktualizowane wartości.

Więcej informacji o korzystaniu z ustawień limitu w usłudze API znajdziesz w przykładzie powyżej „Limit dynamiczny”..

Informacje o konfigurowaniu usług API z limitami znajdziesz w artykule Tworzenie usług API.

Odwołanie do elementu

Poniżej znajdziesz elementy i atrybuty, które możesz skonfigurować w tej zasadzie. Pamiętaj, że niektóre kombinacje elementów wzajemnie się wykluczają lub nie są wymagane. Zobacz przykłady poszczególnych zastosowań. Poniższe zmienne verifyapikey.VerifyAPIKey.apiproduct.* są domyślnie dostępne, gdy do sprawdzenia klucza interfejsu API aplikacji w żądaniu jest używana zasada weryfikacji klucza interfejsu API o nazwie „VerifyAPIKey”. Wartości zmiennych pochodzą z ustawień limitów usługi API, z którą jest powiązany klucz, zgodnie z opisem w sekcji Uzyskiwanie ustawień limitu z konfiguracji usługi API.

<Quota async="false" continueOnError="false" enabled="true" name="Quota-3" type="calendar">
   <DisplayName>Quota 3</DisplayName>
   <Allow count="2000" countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>
   <Allow>
      <Class ref="request.queryparam.time_variable">
        <Allow class="peak_time" count="5000"/>
        <Allow class="off_peak_time" count="1000"/>
      </Class>
   </Allow>
   <Interval ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.interval">1</Interval> 
   <TimeUnit ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.timeunit">month</TimeUnit>
   <StartTime>2017-7-16 12:00:00</StartTime> 
   <Distributed>false</Distributed> 
   <Synchronous>false</Synchronous> 
   <AsynchronousConfiguration> 
      <SyncIntervalInSeconds>20</SyncIntervalInSeconds> 
      <SyncMessageCount>5</SyncMessageCount> 
   </AsynchronousConfiguration> 
   <Identifier/> 
   <MessageWeight/> 
</Quota>

Atrybuty <Limit>

<Quota async="false" continueOnError="false" enabled="true" name="Quota-3" type="calendar">

Poniższe atrybuty są specyficzne dla tych zasad.

Tabela poniżej zawiera opis atrybutów wspólnych dla wszystkich elementów nadrzędnych zasad:

Element <DisplayName>

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

<DisplayName>Policy Display Name</DisplayName>

Element <Allow>

Określa limit liczby elementów. Jeśli licznik zasady osiągnie tę wartość, kolejne wywołania będą odrzucane, dopóki licznik się nie zresetuje.

Poniżej przedstawiono 3 sposoby ustawienia elementu <Allow>:

<Allow count="2000"/> 

<Allow countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/> 

<Allow count="2000" countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/> 

Jeśli podasz zarówno count, jak i countRef, priorytet będzie countRef. Jeśli countRef nie jest rozpoznawany w czasie działania, używana jest wartość count.

Atrybuty

Element <Allow>/<Class>

Element <Class> umożliwia warunkowanie wartości elementu <Allow> w zależności od wartości zmiennej przepływu. Dla każdego tagu podrzędnego <Allow> dotyczącego <Class> zasada ma osobny licznik.

Aby użyć elementu <Class>, określ zmienną przepływu za pomocą atrybutu ref w tagu <Class>. Następnie Edge korzysta z wartości zmiennej przepływu, aby wybrać jeden z tagów podrzędnych (<Allow>) w celu określenia dozwolonej liczby zasad. Edge dopasowuje wartość zmiennej przepływu do atrybutu class tagu <Allow>, jak pokazano poniżej:

<Allow>
  <Class ref="request.queryparam.time_variable">
    <Allow class="peak_time" count="5000"/>
    <Allow class="off_peak_time" count="1000"/>
  </Class>
</Allow>

W tym przykładzie bieżący licznik limitów jest określany na podstawie wartości parametru zapytania time_variable przekazanego z każdym żądaniem. Ta zmienna może mieć wartość peak_time lub off_peak_time. Jeśli parametr zapytania zawiera nieprawidłową wartość, zasada zwraca błąd naruszenia limitu.

Atrybuty

Element <Allow>/<Class>/<Allow>

Element <Allow> określa limit licznika limitu zdefiniowany przez element <Class>. Dla każdego tagu podrzędnego <Allow> dotyczącego <Class> zasada ma osobny licznik.

Na przykład:

<Allow>
  <Class ref="request.queryparam.time_variable">
    <Allow class="peak_time" count="5000"/>
    <Allow class="off_peak_time" count="1000"/>
  </Class>
</Allow>

W tym przykładzie zasada limitu zawiera 2 liczniki limitów o nazwach peak_time i off_peak_time.

Atrybuty

Element <Interval>

Służy do określania liczby całkowitej (na przykład 1, 2, 5, 60 itd.), która zostanie sparowana z podaną przez Ciebie wartością TimeUnit (minutę, godzinę, dzień, tydzień lub miesiąc), aby określić okres, w którym Edge oblicza wykorzystanie limitu.

Na przykład Interval równy 24 z TimeUnit o wartości hour oznacza, że limit zostanie obliczony w ciągu 24 godzin.

<Interval ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.interval">1</Interval>

Atrybuty

Element <TimeUnit>

Służy do określania jednostki czasu mającej zastosowanie do limitu.

Na przykład Interval równy 24 z TimeUnit o wartości hour oznacza, że limit zostanie obliczony w ciągu 24 godzin.

<TimeUnit ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.timeunit">month</TimeUnit>

Atrybuty

Element <StartTime>

Jeśli type ma wartość calendar,, określa datę i godzinę, kiedy licznik limitów zacznie zliczać, niezależnie od tego, czy otrzymały jakiekolwiek żądania z aplikacji.

Jeśli parametr type ma jawnie ustawioną wartość calendar,, musisz podać bezpośrednią wartość StartTime. Nie można użyć odwołania do zmiennej przepływu. Jeśli podasz wartość StartTime, gdy nie ustawiono żadnej wartości type, wystąpi błąd.

Na przykład:

<StartTime>2017-7-16 12:00:00</StartTime>

Element <rozproszony>

Instalacja Edge może używać do przetwarzania żądań co najmniej 1 procesora wiadomości. Ustaw ten element na true, aby określić, że zasada powinna utrzymywać centralny licznik i stale synchronizować go między wszystkimi procesorami wiadomości. Procesory wiadomości mogą się znajdować w różnych strefach lub regionach dostępności.

Jeśli używasz domyślnej wartości false, możesz przekroczyć limit, ponieważ liczby procesorów nie są współużytkowane:

<Distributed>true</Distributed>

Aby liczniki czasu były synchronizowane i aktualizowane przy każdym żądaniu, ustaw <Distributed> i <Synchronous> na „true” (prawda):

<Distributed>true</Distributed>
<Synchronous>true</Synchronous>

Element <Synchroniczny>

Ustaw wartość true, aby synchronicznie aktualizować licznik limitów rozproszonych. Oznacza to, że aktualizacja licznika jest przeprowadzana w momencie sprawdzania limitu w żądaniu wysyłanym do interfejsu API. Ustaw jako true, jeśli nie możesz zezwalać na wywołania interfejsu API powyżej limitu.

Ustaw wartość false, aby asynchronicznie aktualizować licznik limitu. Oznacza to, że w zależności od tego, kiedy licznik limitów w centralnym repozytorium będzie aktualizowany asynchronicznie, niektóre wywołania interfejsu API przekraczające limit zostaną zrealizowane. Nie będzie to jednak miało wpływu na wydajność związane z aktualizacjami synchronicznymi.

Domyślny asynchroniczny interwał aktualizacji to 10 sekund. Aby skonfigurować to działanie asynchroniczne, użyj elementu AsynchronousConfiguration.

<Synchronous>false</Synchronous>

Element <AsynchronousConfiguration>

Konfiguruje interwał synchronizacji między licznikami rozproszonego limitu przydziału, gdy element konfiguracji zasad <Synchronous> nie jest obecny lub gdy jest on ustawiony na false.

Elementy podrzędne SyncIntervalInSeconds lub SyncMessageCount umożliwiają synchronizowanie po określonym czasie lub po liczbie wiadomości. wzajemnie się wykluczają. Przykład:

<AsynchronousConfiguration>
   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
</AsynchronousConfiguration>

lub

<AsynchronousConfiguration>
   <SyncMessageCount>5</SyncMessageCount>
</AsynchronousConfiguration>

Element <AsynchronousConfiguration>/<SyncIntervalInSeconds>

Służy do zastąpienia domyślnego działania, w którym aktualizacje asynchroniczne są wykonywane po 10 sekundach.

<AsynchronousConfiguration>
   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
</AsynchronousConfiguration>

Interwał synchronizacji musi wynosić co najmniej 10 sekund, zgodnie z opisem w temacie Limity.

Element <AsynchronousConfiguration>/<SyncMessageCount>

Określa liczbę żądań do wszystkich procesorów wiadomości Apigee między aktualizacjami limitu.

<AsynchronousConfiguration>
   <SyncMessageCount>5</SyncMessageCount>
</AsynchronousConfiguration>

Ten przykład określa, że limit jest aktualizowany co 5 żądań w każdym procesorze wiadomości Apigee Edge.

Element <Identifier>

Za pomocą elementu <Identifier> skonfiguruj zasadę, która tworzy unikalne liczniki na podstawie zmiennej przepływu.

Jeśli nie używasz tego elementu, zasada używa jednego licznika, który jest stosowany do limitu.

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

<Identifier ref="verifyapikey.verify-api-key.client_id"/>

Atrybuty

Element <MessageWeight>

Służy do określania wagi przypisanej do każdej wiadomości. Użyj wagi wiadomości, aby zwiększyć wpływ wiadomości z żądaniami, które na przykład pochłaniają więcej zasobów obliczeniowych niż inne.

Chcesz na przykład, aby wiadomości POST były 2 razy bardziej „ciężkie” lub droższe niż wiadomości GET. Dlatego ustawiasz MessageWeight na 2 dla żądania POST i 1 dla żądania GET. Możesz nawet ustawić MessageWeight na 0, aby żądanie nie miało wpływu na licznik. W tym przykładzie, jeśli limit to 10 wiadomości na minutę, a MessageWeight dla żądań POST wynosi 2, to limit zezwala na 5 żądań POST w dowolnym 10-minutowym przedziale czasu. Wszelkie dodatkowe żądania (POST lub GET) poprzedzające resetowanie licznika będą odrzucane.

Wartość reprezentująca MessageWeight musi być określona przez zmienną przepływu i można ją wyodrębnić z nagłówków HTTP, parametrów zapytania, ładunku żądania XML lub JSON lub dowolnej innej zmiennej przepływu. Możesz na przykład ustawić go w nagłówku o nazwie weight:

<MessageWeight ref="message_weight"/>

Zmienne przepływu

Poniższe wstępnie zdefiniowane zmienne przepływu są wypełniane automatycznie podczas wykonywania zasady dotyczącej limitów. Więcej informacji o zmiennych przepływu znajdziesz w artykule Informacje o zmiennych.

Informacje o błędach

W tej sekcji opisujemy kody błędów i komunikaty o błędach, które są zwracane, oraz zmienne błędów ustawiane przez Edge, gdy ta zasada wywołuje 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

Zmienne błędów

Te zmienne są ustawiane, gdy zasada wywołuje błąd. Więcej informacji znajdziesz w artykule Co musisz wiedzieć o błędach związanych z naruszeniem zasad.

Przykładowa odpowiedź na błąd

{  
   "fault":{  
      "detail":{  
         "errorcode":"policies.ratelimit.QuotaViolation"
      },
      "faultstring":"Rate limit quota violation. Quota limit  exceeded. Identifier : _default"
   }
}

Przykładowa reguła błędu

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

Schematy

Powiązane artykuły

Zasady dotyczące resetowania limitów

Zasady SpikeArrest

Porównanie zasad dotyczących limitów, przyrostu zatrzymania i limitów liczby równoczesnych