Das Wesentliche
Laut mehreren spezialisierten Quellen fügt ein ordnungsgemäß implementierter verteilter Ratenbegrenzer (atomare Zählung, lokaler Fallback-Cache) in der Regel weniger als eine Millisekunde pro Anfrage hinzu. Das Aurabase-Gateway folgt genau diesem Muster: die Kiste governor für lokalen Anti-DoS, ein atomares Lua-Redis-Skript für die verteilte Zählung zwischen Instanzen, ein Fallback-Cache moka, wenn Redis nicht verfügbar ist. Der Leistungsschalter reduziert die wahrgenommene Latenz im Fehlerfall, statt sie zu erhöhen – er verkürzt das Warten auf eine vollständige Zeitüberschreitung. Bisher wurden keine Aurabase-Latenzzahlen veröffentlicht. Hier erfahren Sie, warum und wie der Mechanismus tatsächlich funktioniert.
Anti-DoS- und Anti-Cascading-Fehler, zwei unterschiedliche Probleme
Die Ratenbegrenzung schützt Ihr Backend vor übermäßigem Datenverkehr, ob legitim oder nicht – sie beantwortet die Frage „Hat dieser Anrufer jetzt das Recht, diese Anfrage zu senden?“ „Der Schutzschalter schützt Ihr Backend vor einem bereits ausgefallenen Downstream-Dienst – er antwortet auf die Frage „Hat sich gezeigt, dass dieser Dienst jemals nicht mehr reagiert, sollten wir es überhaupt versuchen?“ ". Eine Verwechslung führt zur Unterdimensionierung des einen oder anderen.
Auf dem Aurabase-Gateway befinden sich beide im selben Middleware-Stack, jedoch auf unterschiedlichen Ebenen: Die IP-Ratenbegrenzung wird vor der Authentifizierung ausgeführt (reiner Anti-DoS-Angriff, keine Abrechnungs-SQL-Abfragen für nicht authentifizierten Datenverkehr), während der Leistungsschalter ausgehende Anrufe an interne Dienste oder LLM-Anbieter schützt.
Die Kosten hängen vollständig von der Implementierung ab, nicht vom Prinzip
Laut Tyk und den APISIX-Ökosystemleitfäden führt eine gut konzipierte verteilte Zählung auf Redis (atomare Operationen, Lua-Skript, natives TTL) typischerweise zu einer Latenz von 1–3 ms, wobei die p99-Auswirkung in den am besten optimierten Fällen weniger als eine Millisekunde beträgt. Umgekehrt dokumentiert Zuplo, dass ein schlecht platzierter zentraler Ratenbegrenzer jede Anfrage um mehrere zehn Millisekunden verlängern kann – diese Diskrepanz spiegelt sich direkt in Ihrem p99 wider.
Diese Bereiche stammen aus öffentlichen technischen Leitfäden (Tyk, Zuplo, Apache APISIX-Ökosystem) und nicht aus einem gemeinsamen Messprotokoll. Sie geben eine Größenordnung und ein Architekturprinzip an – atomares und lokales Zählen statt synchrones und zentralisiertes – und keine Zahl, die wie in einer anderen Infrastruktur reproduziert werden kann.
Wie die Ratenbegrenzung im Aura-Gateway tatsächlich funktioniert
Das Aurabase-Gateway verwendet die governor-Kiste (Token-Bucket-Algorithmus) als lokalen Fallback-Limiter, gekoppelt mit verteilter Zählung über Redis, um den Status zwischen mehreren Instanzen des Gateways zu teilen. Die verteilte Zählung erfolgt über ein Lua-Skript, das atomar auf der Redis-Seite ausgeführt wird (INCRBY + EXPIRE in einem einzigen Netzwerkvorgang), nicht über einen Lese- und Schreib-Roundtrip, der ein Parallelitätsfenster einführen würde.
Wenn Redis nicht verfügbar ist, wechselt das Gateway automatisch zum lokalen Begrenzer governormit einem Cache moka (maximal 1.000.000 Einträge, Ablauf nach 300 Sekunden Inaktivität), um zu vermeiden, dass bei jeder Anfrage ein Begrenzer neu erstellt wird. Dieser Rückfall ist beobachtbar: Bei jedem Umschalten wird ein dedizierter Prometheus-Zähler erhöht, sodass das Team weiß, wann das effektive Limit wieder N Instanzen × Limit erreicht (andernfalls stille Verschlechterung der Isolation zwischen Instanzen).
Das Gateway unterscheidet zwischen der Anti-DoS-Ratenbegrenzung nach IP (vor der Authentifizierung) und der Ratenbegrenzung nach Projekt/API-Schlüssel/Benutzerkontingent (nach der Authentifizierung, mit verfügbaren JWT-Ansprüchen) – zwei separate Middlewares im Stapel, jede mit ihrer eigenen Granularität.
Der Leistungsschalter: drei Zustände, ein Schiebefenster
Der Aurabase-Leistungsschalterschaltkreis (aura_core::circuit_breaker, gemeinsam genutzt vom Gateway und aura-ai für den Fallback zwischen LLM-Anbietern) folgt drei klassischen Zuständen – Closed, Open, HalfOpen – mit einer Zählung der Ausfälle über ein gleitendes Zeitfenster und nicht mit einem Zähler, der nie zurückgesetzt wird.
Ein Implementierungsdetail, das in der Produktion von Bedeutung ist: Der Wechsel zu HalfOpen lässt jeweils nur eine Prüfanfrage zu (Anti-Thundering-Herd) – ohne diesen Schutz würden alle ausstehenden Anfragen gleichzeitig an den gerade wieder geöffneten Dienst weitergeleitet, was sofort zu dem Fehler führen würde, den wir vermeiden wollten.
Wo diese Middleware im Gateway läuft
Der Middleware-Stack des Aurabase-Gateways folgt einer genauen Reihenfolge, die im Code verifiziert wird: Anforderungskennung → Zugriffsprotokoll → Ratenbegrenzung nach IP → Authentifizierung → Ratenbegrenzung nach Akteur/Kontingent → Leistungsschalter → Proxy für den Zieldienst. Jede Stufe weist unerwünschten Datenverkehr so früh wie möglich zurück, bevor im weiteren Verlauf höhere Verarbeitungskosten anfallen.
Lesen Sie den vollständigen Artikel: Datenebene vs. Managementebene im Aurabase-Gateway
Warum hier keine Aurabase-Zahlen veröffentlicht werden
Die Implementierung wird Zeile für Zeile im Gateway-Quellcode überprüft. Es wurde jedoch noch kein reproduzierbares Messprotokoll auf dieser speziellen Infrastruktur ausgeführt und veröffentlicht. Die Veröffentlichung einer nicht gemessenen Zahl würde den Fehler wiederholen, dass Marketingzahlen nicht aus Quellen stammen und wir uns weigern, sie zu reproduzieren. Sehen Sie sich unsere vollständige Benchmark-Methodik an, um zu erfahren, was wir benötigen, bevor wir eine Leistungszahl veröffentlichen.