Zasady dotyczące limitów

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X. informacje.

Co

Użyj zasady dotyczącej limitów, aby skonfigurować liczbę komunikatów żądań, na które zezwala serwer proxy interfejsu API okres, np. minuta, godzina, dzień, tydzień lub miesiąc. Możesz ustawić limit na tak samo w przypadku wszystkich aplikacji korzystających z serwera proxy interfejsu API. Możesz też ustawić limit na podstawie tych kryteriów:

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

Nie używaj limitu w celu zabezpieczenia się przed ogólnym wzrostem natężenia ruchu. Do tego celu użyj Spike Arrest . Zobacz Spike Arest .

Filmy

W tych filmach omówiono zarządzanie limitami za pomocą zasad dotyczących limitów:

Przykłady

Poniższe przykłady kodu zasad pokazują, jak rozpocząć i zakończyć okres obowiązywania limitu 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 zasadzie limitów

Limit to przydział komunikatów dotyczących żądań, które serwer proxy interfejsu API może obsłużyć w danym okresie. takie jak minuta, godzina, dzień, tydzień lub miesiąc. Zasada posiada liczniki, które liczą liczbę żądań odbieranych przez serwer proxy interfejsu API. Ta funkcja pozwala dostawcom interfejsów API egzekwować limity na liczbę wywołań interfejsu API przez aplikacje w określonym przedziale czasu. Za pomocą dostępnych zasad dotyczących limitów możesz na przykład ograniczyć do 1 żądania na minutę lub do 10 tys. żądań miesięcznie.

Jeśli na przykład limit jest zdefiniowany jako 10 000 wiadomości miesięcznie, ograniczenie szybkości rozpoczyna się po dziesiąta tysięczna wiadomość. Nie ma znaczenia,czy 10 000 wiadomości zostało zliczonych dnia albo ostatniego dnia danego okresu; dodatkowe żądania nie są dozwolone do czasu licznika limitów jest automatycznie resetowany po zakończeniu określonego przedziału czasu lub dopóki limit nie zostanie wyraźnie określony resetuj za pomocą opcji Resetuj limit .

Odmiana limitu o nazwie SpikeArrest zapobiega gwałtownym wzrostom natężenia ruchu, które mogą może być spowodowane nagłym wzrostem liczby użytkowników, błędnymi klientami lub złośliwymi atakami. Więcej Więcej informacji na temat SpikeArrest znajdziesz w zasadach dotyczących aresztowania SpikeArrest.

Limity dotyczą poszczególnych serwerów proxy interfejsów API i nie są rozłożone między serwery proxy interfejsu API. Przykład: Jeśli w usłudze API masz 3 serwery proxy interfejsu API, pojedynczy limit nie będzie współużytkowany przez wszystkie 3 z nich nawet jeśli wszystkie 3 korzystają z tej samej konfiguracji zasad limitów.

Typy zasad dotyczących limitów

Zasada limitów obsługuje kilka różnych typów zasad: domyślne, calendar, flexi i rollingwindow. Każdy typ określa, kiedy licznik limitu rozpoczyna się i kiedy jest resetowany, jak w poniższej tabeli:

W polu type="calendar" musisz podać wartość <StartTime>

Tabela nie zawiera wartości typu rollingwindow. Okres obserwacji działają, ustawiając rozmiar „okna” limitu, na przykład na godzinę lub jeden dzień. Gdy pojawi się nowe żądanie, zasada określa, czy limit został przekroczony w przeszłości „okno” czasu.

Na przykład zdefiniujesz 2-godzinne okno, które zezwala na wysłanie 1000 żądań. Nowa prośba przychodzi o 16:45.Zgodnie z zasadami oblicza limit dla okresu 2-godzinnego, czyli liczbę żądań od godziny 14:45. Jeśli limit nie został przekroczony w dwie godziny, wtedy żądanie jest dozwolone.

Minutę później, o 16:46, przychodzi kolejna prośba. Teraz zasada oblicza od godziny 14:46, aby sprawdzić, czy limit został przekroczony.

W przypadku typu rollingwindow licznik nigdy nie jest resetowany, ale jest przeliczane dla każdego żądania.

Omówienie liczników limitów

Domyślnie zasada dotycząca limitów przechowuje jeden licznik niezależnie od tego, ile razy do niego w serwerze proxy interfejsu API. Nazwa licznika limitów jest oparta na danych atrybut name zasady.

Możesz na przykład utworzyć zasadę limitów o nazwie MyQuotaPolicy z limitem wynoszącym 5 i umieszczać ją w kilku przepływach (Przepływ A, B i C) na serwerze proxy API. Mimo że jest to jest używany 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 wynosi 1
• Wykonywany jest przepływ B -> Wykonywana jest zasada MyLimitPolicy, a jej licznik wynosi 2
• Przepływ A jest wykonywany -> Wykonywana jest zasada MyLimitPolicy, a jej licznik wynosi 3
• Proces C jest wykonywany -> Wykonywana jest zasada MyLimitPolicy, a jej licznik wynosi 4
• Przepływ A jest wykonywany -> Wykonywana jest zasada MyLimitPolicy, a jej licznik wynosi 5

Następne żądanie do dowolnego z 3 przepływów zostało odrzucone, ponieważ osiągnięto limit jej granicach.

Ta sama zasada dotycząca limitów w więcej niż jednym miejscu w procesie serwera proxy interfejsu API, która może nieumyślnie powoduje wyczerpanie limitu szybciej niż oczekiwano, to antywzorzec opisany w The Book of Apigee Edge Antipatterns (Książka o antywzorcach Apigee Edge).

Możesz też zdefiniować wiele zasad dotyczących limitów na serwerze proxy interfejsu API i użyć zasady obowiązują w przypadku każdego procesu. Każda zasada dotycząca limitów zachowuje własny licznik, atrybut name zasady.

Możesz też skorzystać z Elementy <Class> lub <Identifier> w zasady limitów do definiowania wielu unikalnych liczników w ramach jednej zasady. Za pomocą tych elementów, jedna zasada może utrzymywać różne liczniki w zależności od aplikacji wysyłającej żądanie. identyfikator klienta lub inny identyfikator klienta, który przesłał żądanie aplikacji, oraz inne dane. Zobacz powyższych przykładów. Elementy <Class> lub <Identifier>.

Zapis czasu

Wszystkie limity czasu są ustawione na uniwersalny limit koordynowany Czas (UTC).

Format czasu przydziału jest zgodny z międzynarodowym, standardowym zapisem daty określonym w językach międzynarodowych Standardowy ISO 8601.

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

Pora dnia jest określana jako godziny, minuty i sekundy w takim formacie: hours:minutes:seconds Na przykład 23:59:59 oznacza godzinę, sekundę przed północą.

Pamiętaj, że dla00:00:0024:00:00 rozróżnienie dwóch północy, które można powiązać z jedną datą. Dlatego 2015-02-04 24:00:00 to ta sama data i godzina co 2015-02-05 00:00:00. To drugie zwykle jest to preferowany zapis.

Pobieram ustawienia limitów z konfiguracji usługi API

Limity możesz ustawić w konfiguracjach usług API. Limity te nie są automatycznie wyegzekwuj limit. Zamiast tego możesz odwoływać się do ustawień limitów produktów w zasadach dotyczących limitów. Oto kilka zalety ustawienia limitu w usłudze, aby można było się odwoływać do zasad dotyczących limitów:

• Zasady dotyczące limitów mogą stosować jednolite ustawienie dla wszystkich serwerów proxy API w usłudze API.
• Możesz zmieniać ustawienia limitu w usłudze API oraz zasady dotyczące limitów w czasie działania aplikacji które odwołują się do wartości, automatycznie zaktualizowane wartości limitów.

Aby dowiedzieć się więcej o używaniu ustawień limitów z usługi API, zapoznaj się z sekcją „Limit dynamiczny” powyżej.

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 elementy kombinacje wzajemnie się wykluczają lub nie są wymagane. Zapoznaj się z przykładami dotyczącymi konkretnego zastosowania. Poniższe zmienne (verifyapikey.VerifyAPIKey.apiproduct.*) są domyślnie dostępne, gdy zasada weryfikacji klucza interfejsu API o nazwie „VerifyAPIKey” jest używany do sprawdzenia klucza interfejsu API aplikacji w żądaniu. Wartości zmiennych pochodzą z ustawień limitu w usłudze API, z którą powiązany jest klucz zgodnie z opisem w sekcji Pobieranie ustawień limitów z 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>

<Quota> atrybuty

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

Poniższe atrybuty są charakterystyczne dla tej zasady.

W tej tabeli opisano atrybuty wspólne dla wszystkich elementów nadrzędnych zasad:

<DisplayName> element

Używaj oprócz atrybutu name do oznaczania zasady w edytor proxy interfejsu zarządzania z inną nazwą w języku naturalnym.

<DisplayName>Policy Display Name</DisplayName>

<Allow> element

Określa limit liczby elementów. Jeśli licznik dotyczący tej zasady osiągnie ten limit , kolejne wywołania będą odrzucane, dopóki licznik nie zostanie zresetowany.

Poniżej widać 3 sposoby ustawiania 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, countRef otrzymuje priorytet. Jeśli countRef nie rozwiązuje problemu w czasie działania, wartość Używana jest wartość count.

Atrybuty

<Allow>/<Class> element

Element <Class> umożliwia warunkowanie wartości elementu <Allow> na podstawie wartości zmiennej Flow. Dla: każdy tag podrzędny <Allow> tagu <Class>, zasady obsługują inny licznik.

Aby użyć elementu <Class>, określ zmienną przepływu za pomocą atrybutu ref do tagu <Class>. Edge następnie używa wartości atrybutu zmiennej przepływu, aby wybrać jeden z <Allow> tagów podrzędnych i określić dozwolone dla zasady. Krawędź dopasowuje wartość zmiennej przepływu do wartości class w tagu <Allow>, jak widać 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 limitu jest określany na podstawie wartości time_variable parametr zapytania przekazywany z każdym żądaniem. Ta zmienna może mieć wartość z peak_time lub off_peak_time. Jeśli parametr zapytania zawiera nieprawidłową wartość , zasada zwraca błąd naruszenia limitu.

Atrybuty

<Allow>/<Class>/<Allow> element

Element <Allow> określa limit licznika limitów zdefiniowane przez element <Class>. Dla każdej wartości inny tag podrzędny <Allow> tagu <Class>, zachowuje inny 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 dotycząca limitów utrzymuje 2 liczniki limitów o nazwie z peak_time i off_peak_time.

Atrybuty

<Interval> element

Umożliwia określenie liczby całkowitej (na przykład 1, 2, 5, 60 itd.), która zostanie sparowana z TimeUnit (minuta, godzina, dzień, tydzień lub miesiąc) w celu określenia czasu okresu, w którym Edge oblicza wykorzystanie limitu.

Na przykład Interval o wartości 24 z TimeUnit o wartości hour oznacza, że limit będzie obliczonych w ciągu 24 godzin.

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

Atrybuty

<TimeUnit> element

Umożliwia określenie jednostki czasu mającej zastosowanie do limitu.

Na przykład Interval o wartości 24 z TimeUnit o wartości hour oznacza, że limit będzie obliczonych w ciągu 24 godzin.

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

Atrybuty

<StartTime> element

Gdy type ma wartość calendar,, określa datę i godzinę, o której licznik limitów rozpocznie zliczanie, niezależnie od tego, czy zostały wysłane jakieś żądania z aplikacji.

Jeśli ustawiono wartość type, musisz podać atrybut StartTime do calendar, nie można użyć odwołania do zmiennej przepływu, jeśli nie ustawisz żadnej wartości type, otrzymasz wartość StartTime, .

Na przykład:

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

<Rozproszone> element

Instalacja Edge może wymagać użycia jednego lub kilku procesorów wiadomości do przetwarzania żądań. Ustaw do true, aby wskazać, że zasada powinna utrzymywać centralny element i stale synchronizować go przez wszystkie procesory wiadomości. Podmioty przetwarzające wiadomości mogą znajdować się w strefach dostępności lub regionach.

Jeśli używasz wartości domyślnej, która wynosi false, limit może zostać przekroczony, ponieważ liczba dla każdego procesora wiadomości nie jest udostępniana:

<Distributed>true</Distributed>

Aby zagwarantować synchronizację liczników i ich aktualizację przy każdym żądaniu, ustaw <Distributed> i <Synchronous> mają wartość prawda:

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

&lt;Synchronous&gt; element

Ustaw wartość true, aby synchronicznie aktualizować licznik limitu rozproszonego. Ten oznacza, że aktualizacja licznika jest przeprowadzana w tym samym czasie, gdy limit jest sprawdzany w żądaniu do interfejsu API. Ustaw jako true, jeśli nie chcesz zezwalać na używanie żadnego interfejsu API przekracza limit.

Ustaw wartość false, aby asynchronicznie aktualizować licznik limitu. Oznacza to, że że jest możliwe, że niektóre wywołania interfejsu API przekroczone przez limit zostaną zrealizowane w zależności licznik limitów w centralnym repozytorium jest asynchronicznie aktualizowany. Jednak użytkownicy nie spotkają się potencjalnego wpływu na wydajność związanych z aktualizacjami synchronicznymi.

Domyślny interwał aktualizacji asynchronicznej wynosi 10 sekund. Użyj AsynchronousConfiguration, aby skonfigurować to asynchroniczne zachowanie.

<Synchronous>false</Synchronous>

&lt;AsynchronousConfiguration&gt; element

Konfiguruje interwał synchronizacji między rozproszonymi licznikami limitów, gdy zasada Element konfiguracji <Synchronous> nie występuje lub nie występuje i został ustawiony do: false.

Możesz zsynchronizować albo po określonym czasie, albo po liczbie wiadomości, używając Elementy podrzędne: SyncIntervalInSeconds lub SyncMessageCount. wzajemnie się wykluczają. Na przykład

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

lub

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

&lt;AsynchronousConfiguration&gt;/&lt;SyncIntervalInSeconds&gt; element

Służy do zastąpienia domyślnego zachowania, w ramach którego aktualizacje asynchroniczne są wykonywane po co 10 sekund.

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

Interwał synchronizacji musi wynosić >= 10 s, jak opisano w Temat Limity.

&lt;AsynchronousConfiguration&gt;/&lt;SyncMessageCount&gt; element

Określa liczbę żądań do wszystkich procesorów wiadomości Apigee w zakresie limitów aktualizacje.

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

W tym przykładzie liczba limitów jest aktualizowana co 5 żądań w każdym Apigee Procesor obsługi wiadomości na brzegu.

&lt;Identifier&gt; element

Użyj elementu <Identifier>, aby skonfigurować zasadę do tworzenia unikalnych na podstawie zmiennej przepływu.

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

Ten element jest też 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

&lt;MessageWeight&gt; element

Umożliwia określenie wagi przypisanej do każdej wiadomości. Użyj wagi wiadomości, aby zwiększyć wpływ komunikatów, które na przykład zużywają więcej zasobów obliczeniowych niż inne.

Na przykład wiadomości POST mają być liczone jako 2 razy bardziej „ciężkie” lub drogie, tak jak wiadomości. Dlatego ustawiasz MessageWeight na 2 dla żądania POST i 1 dla POBIERZ. Możesz nawet ustawić MessageWeight na 0, aby żądanie nie nie wpływają na licznik. W tym przykładzie, jeśli limit wynosi 10 wiadomości na minutę MessageWeight dla żądań POST wynosi 2, limit będzie zezwala na 5 żądań POST w dowolnym 10-minutowym przedziale czasu. Każde dodatkowe żądanie, POST lub GET, przed odrzuceniem licznika.

Wartość reprezentująca MessageWeight musi być określona przez przepływ zmienną. Można ją wyodrębnić z nagłówków HTTP, parametrów zapytania, żądania XML lub JSON. ładunek danych lub dowolną inną zmienną przepływu. np. w nagłówku o nazwie weight:

<MessageWeight ref="message_weight"/>

Zmienne przepływu

Poniższe wstępnie zdefiniowane zmienne przepływu są automatycznie wypełniane, gdy zasada dotycząca limitów . Więcej informacji o zmiennych Flow znajdziesz w dokumentacji zmiennych.

Informacje o błędzie

W tej sekcji opisano kody błędów i komunikaty o błędach, które są zwracane, oraz zmienne błędów ustawiane przez Edge, gdy ta zasada wyzwala błąd. Warto o tym wiedzieć, jeśli rozwijasz reguły błędów, aby obsługi błędów. Więcej informacji znajdziesz w artykule Co musisz wiedzieć 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

Zmienne błędów

Te zmienne są ustawiane, gdy ta zasada wywołuje błąd. Więcej informacji znajdziesz w artykule Podstawowe informacje 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 resetowania limitów

SpikeArrest

Porównanie Zasady dotyczące limitu, zwiększenia liczby żądań i limitów równoczesnych żądań