Najważniejsze
Według kilku wyspecjalizowanych źródeł, prawidłowo zaimplementowany rozproszony ogranicznik szybkości (zliczanie atomów, lokalna rezerwowa pamięć podręczna) zazwyczaj dodaje mniej niż milisekundę na żądanie. Brama Aurabase działa dokładnie według tego wzorca: skrzynka governor dla lokalnego zabezpieczenia przed DoS, atomowy skrypt Lua Redis do rozproszonego zliczania między instancjami, rezerwowa pamięć podręczna moka, jeśli Redis jest niedostępny. Obwód wyłącznika zamiast go dodawać, zmniejsza odczuwalne opóźnienie w przypadku awarii — skraca czas oczekiwania na pełny limit czasu. Do tej pory nie opublikowano żadnych danych dotyczących opóźnień Aurabase: oto dlaczego i jak faktycznie działa ten mechanizm.
Awaria Anti-DoS i ochrona przed kaskadowaniem, dwa różne problemy
Ograniczanie szybkości chroni Twój backend przed nadmiernym ruchem, legalnym lub nie – odpowiada na pytanie „czy ten rozmówca ma prawo wysłać teraz to żądanie?” „. Wyłącznik chroni Twój backend przed usługą, która już działa na niższym szczeblu łańcucha dostaw — odpowiada na pytanie: „Czy kiedykolwiek okazało się, że ta usługa przestała odpowiadać, czy w ogóle powinniśmy spróbować?” „. Pomieszanie ich prowadzi do niedowymiarowania jednego lub drugiego.
W bramie Aurabase oba działają w tym samym stosie oprogramowania pośredniego, ale na różnych piętrach: ograniczanie szybkości IP działa przed uwierzytelnieniem (czysta ochrona przed DoS, brak zapytań SQL dotyczących rozliczeń wysyłanych dla nieuwierzytelnionego ruchu), podczas gdy wyłącznik automatyczny chroni połączenia wychodzące do usług wewnętrznych lub dostawców LLM.
Koszt zależy całkowicie od wdrożenia, a nie od zasady
Według Tyk i przewodników po ekosystemie APISIX dobrze zaprojektowane rozproszone zliczanie na Redis (operacje atomowe, skrypt Lua, natywny TTL) zazwyczaj dodaje 1-3 ms opóźnienia, z wpływem p99 poniżej milisekundy w najlepiej zoptymalizowanych przypadkach. Z drugiej strony Zuplo dokumentuje, że źle umiejscowiony, scentralizowany ogranicznik szybkości może dodać dziesiątki milisekund do każdego żądania — ta rozbieżność jest odzwierciedlana bezpośrednio w Twoim p99.
Zakresy te pochodzą z publicznych przewodników technicznych (ekosystem Tyk, Zuplo, Apache APISIX), a nie ze wspólnego protokołu pomiarowego. Wskazują rząd wielkości i zasadę architektoniczną – zliczanie atomowe i lokalne, a nie synchroniczne i scentralizowane – a nie liczbę, którą należy odtworzyć, jak ma to miejsce w innej infrastrukturze.
Jak faktycznie działa ograniczanie szybkości w aura-gateway
Brama Aurabase wykorzystuje skrzynię governor (algorytm wiadra tokenów) jako lokalny ogranicznik rezerwowy, w połączeniu z rozproszonym zliczaniem za pośrednictwem Redis w celu współdzielenia stanu pomiędzy kilkoma instancjami bramy. Zliczanie rozproszone odbywa się poprzez skrypt Lua wykonywany atomowo po stronie Redis (INCRBY + EXPIRE w pojedynczej operacji sieciowej), a nie przez operację odczytu i zapisu, która wprowadziłaby okno współbieżności.
Jeśli Redis stanie się niedostępny, brama automatycznie przełącza się na lokalny ogranicznik governorz pamięcią podręczną moka (maks. 1 000 000 wpisów, wygaśnięcie po 300 sekundach bezczynności), aby uniknąć ponownego tworzenia ogranicznika przy każdym żądaniu. To rozwiązanie awaryjne jest zauważalne: każdy przełącznik zwiększa dedykowany licznik Prometheusa, dzięki czemu zespół wie, kiedy efektywny limit ponownie staje się N wystąpień × limit (w przeciwnym razie cicha degradacja izolacji między instancjami).
Brama odróżnia ograniczanie szybkości anty-DoS przez adres IP (przed uwierzytelnieniem) od ograniczania szybkości przez projekt/klucz API/przydział użytkownika (po uwierzytelnieniu, z dostępnymi oświadczeniami JWT) — dwa oddzielne oprogramowanie pośredniczące w stosie, każde z własną szczegółowością.
Wyłącznik: trzy stany, okno przesuwne
Obwód wyłącznika Aurabase (aura_core::circuit_breaker, współdzielony przez bramkę i aura-ai w przypadku awarii między dostawcami LLM) ma trzy klasyczne stany — Closed, Open, HalfOpen — z liczbą awarii w przesuwającym się oknie czasowym, a nie licznikiem, który nigdy się nie resetuje.
Szczegół implementacji mający znaczenie w środowisku produkcyjnym: przejście na HalfOpen pozwala tylko na jedno żądanie sondy na raz (antygrzmot-stado) — bez tego strażnika wszystkie oczekujące żądania byłyby przesyłane jednocześnie do usługi, która właśnie została ponownie otwarta, natychmiast odtwarzając awarię, której próbowaliśmy uniknąć.
Miejsce, w którym te oprogramowanie pośredniczące działa w bramie
Stos oprogramowania pośredniczącego bramy Aurabase ma precyzyjną kolejność, zweryfikowaną w kodzie: identyfikator żądania → dziennik dostępu → ograniczenie szybkości przez adres IP → uwierzytelnianie → ograniczenie szybkości według aktora/przydziału → wyłącznik → serwer proxy do usługi docelowej. Każdy etap odrzuca niechciany ruch tak wcześnie, jak to możliwe, zanim poniesiesz wyższe koszty przetwarzania na dalszym etapie.
Przeczytaj cały artykuł: płaszczyzna danych a płaszczyzna zarządzania w bramie Aurabase
Dlaczego nie publikowano tutaj żadnych danych Aurabase
Implementacja jest weryfikowana linia po linii w kodzie źródłowym bramki. Jednak dla tej konkretnej infrastruktury nie opracowano i nie opublikowano jeszcze żadnego powtarzalnego protokołu pomiarowego — opublikowanie niezmierzonych wartości oznaczałoby powtórzenie błędu polegającego na nieposiadaniu danych marketingowych, których nie chcemy reprodukować. Zapoznaj się z naszą pełną metodologią testów porównawczych , aby dowiedzieć się, czego wymagamy przed opublikowaniem danych dotyczących wydajności.