De essentie
Een correct geïmplementeerde gedistribueerde snelheidsbegrenzer (atoomtelling, lokale fallback-cache) voegt volgens verschillende gespecialiseerde bronnen doorgaans minder dan een milliseconde per verzoek toe. De Aurabase-gateway volgt precies dit patroon: de governor-krat voor lokale anti-DoS, een atomair Lua Redis-script voor gedistribueerd tellen tussen instanties, een fallback moka-cache als Redis niet beschikbaar is. Het onderbrekercircuit vermindert de waargenomen latentie in het geval van een storing in plaats van deze toe te voegen; het kortsluit het wachten op een volledige time-out. Tot nu toe zijn er geen latentiecijfers van Aurabase gepubliceerd: hier is waarom en hoe het mechanisme daadwerkelijk werkt.
Anti-DoS en anti-cascading falen, twee verschillende problemen
Tariefbeperking beschermt uw backend tegen overmatig verkeer, legitiem of niet. Het beantwoordt de vraag: heeft deze beller het recht om dit verzoek nu te verzenden? ". De stroomonderbreker beschermt uw backend tegen een reeds downstream-service - hij reageert op "is het ooit gebleken dat deze service niet meer reageert, moeten we het zelfs maar proberen?" ". Door ze te verwarren, wordt het een of het ander onderschat.
Op de Aurabase-gateway bevinden beide zich in dezelfde middleware-stack, maar op verschillende verdiepingen: IP-snelheidsbeperking loopt vóór authenticatie (pure anti-DoS, geen facturering van SQL-query's voor niet-geverifieerd verkeer), terwijl de stroomonderbreker uitgaande oproepen naar interne services of LLM-providers beschermt.
De kosten zijn volledig afhankelijk van de implementatie, niet van het principe
Volgens Tyk en de APISIX-ecosysteemgidsen voegt goed ontworpen gedistribueerd rekenen op Redis (atomaire operaties, Lua-script, native TTL) doorgaans 1-3 ms latentie toe, met een p99-impact van minder dan een milliseconde in de best geoptimaliseerde gevallen. Omgekeerd documenteert Zuplo dat een slecht geplaatste gecentraliseerde snelheidsbegrenzer tientallen milliseconden aan elk verzoek kan toevoegen – deze discrepantie wordt direct weerspiegeld in uw p99.
Deze bereiken zijn afkomstig van openbare technische handleidingen (Tyk, Zuplo, Apache APISIX-ecosysteem), niet van een algemeen meetprotocol. Ze geven een orde van grootte en een architectonisch principe aan – atomaire en lokale telling in plaats van synchroon en gecentraliseerd – en niet een figuur die moet worden gereproduceerd zoals op een andere infrastructuur.
Hoe snelheidsbeperking feitelijk werkt in aura-gateway
De Aurabase-gateway gebruikt de governor-crate (token-bucket-algoritme) als lokale fallback-begrenzer, gekoppeld aan gedistribueerd tellen via Redis om de status tussen verschillende exemplaren van de gateway te delen. Gedistribueerd tellen gaat via een Lua-script dat atomair wordt uitgevoerd aan de Redis-kant (INCRBY + EXPIRE in een enkele netwerkbewerking), niet via een lees-en-schrijf-rondreis die een gelijktijdigheidsvenster zou introduceren.
Als Redis niet meer beschikbaar is, schakelt de gateway automatisch over naar de lokale limiter governor, met een cache moka (max. 1.000.000 vermeldingen, vervaldatum bij 300 seconden inactiviteit) om te voorkomen dat er bij elk verzoek opnieuw een limiter wordt aangemaakt. Deze terugval is waarneembaar: elke schakelaar verhoogt een speciale Prometheus-teller, zodat het team weet wanneer de effectieve limiet weer N-instanties × limiet wordt (anders wordt de isolatie tussen instanties stil verslechterd).
De gateway maakt onderscheid tussen anti-DoS-snelheidsbeperking op basis van IP (vóór authenticatie) en snelheidsbeperking op basis van project/API-sleutel/gebruikersquota (na authenticatie, met JWT-claims beschikbaar) – twee afzonderlijke middlewares in de stapel, elk met zijn eigen granulariteit.
De stroomonderbreker: drie standen, een schuifraam
Het Aurabase-onderbrekercircuit (aura_core::circuit_breaker, gedeeld tussen de gateway en aura-ai voor terugval tussen LLM-providers) volgt drie klassieke toestanden — Closed, Open, HalfOpen — met een telling van storingen over een verschuivend tijdvenster in plaats van een teller die nooit wordt gereset.
Een implementatiedetail dat van belang is in de productie: overschakelen naar HalfOpen staat slechts één sondeverzoek per keer toe (anti-donderende kudde) - zonder deze bewaker zouden alle lopende verzoeken tegelijkertijd naar de service snellen die net is heropend, waardoor onmiddellijk de mislukking werd herhaald die we probeerden te vermijden.
Waar deze middlewares in de gateway worden uitgevoerd
De middleware-stack van de Aurabase-gateway volgt een precieze volgorde, geverifieerd in de code: verzoek-ID → toegangslogboek → snelheidsbeperking door IP → authenticatie → snelheidsbeperking door actor/quota → stroomonderbreker → proxy voor de doelservice. In elke fase wordt ongewenst verkeer zo vroeg mogelijk afgewezen, voordat er stroomafwaarts hogere verwerkingskosten ontstaan.
Lees het volledige artikel: datavlak versus beheervlak in de Aurabase-gateway
Waarom hier geen cijfers van Aurabase worden gepubliceerd
De implementatie wordt regel voor regel geverifieerd in de gatewaybroncode. Maar er is nog geen reproduceerbaar meetprotocol uitgevoerd en gepubliceerd op deze specifieke infrastructuur; het publiceren van een niet-gemeten cijfer zou een herhaling zijn van de fout van niet-gesourcede marketingcijfers die we weigeren te reproduceren. Bekijk onze volledige benchmarkmethodologie voor wat we nodig hebben voordat we een prestatiecijfer vrijgeven.