Lo esencial
Un limitador de velocidad distribuido correctamente implementado (recuento atómico, caché de respaldo local) generalmente agrega menos de un milisegundo por solicitud, según varias fuentes especializadas. La puerta de enlace de Aurabase sigue exactamente este patrón: la caja governor para anti-DoS local, un script atómico Lua Redis para el conteo distribuido entre instancias, un caché moka alternativo si Redis no está disponible. El circuito disyuntor reduce la latencia percibida en caso de una falla en lugar de agregarla: cortocircuita la espera de un tiempo de espera completo. Hasta la fecha no se han publicado cifras de latencia de Aurabase: he aquí por qué y cómo funciona realmente el mecanismo.
Fallo anti-DoS y anti-cascada, dos problemas distintos
La limitación de velocidad protege su backend del tráfico excesivo, legítimo o no; responde a la pregunta "¿Esta persona que llama tiene derecho a enviar esta solicitud ahora?" ". El disyuntor protege su backend de un servicio descendente que ya se encuentra en etapa descendente; responde a "¿Alguna vez se ha demostrado que este servicio no responde? ¿Deberíamos siquiera intentarlo?" ". Confundirlos lleva a subestimar uno u otro.
En la puerta de enlace de Aurabase, ambos viven en la misma pila de middleware pero en pisos diferentes: la limitación de la velocidad de IP se ejecuta antes de la autenticación (puro anti-DoS, sin consultas SQL de facturación emitidas para tráfico no autenticado), mientras que el disyuntor protege las llamadas salientes a servicios internos o proveedores de LLM.
El costo depende enteramente de la implementación, no del principio.
Según Tyk y las guías del ecosistema APISIX, el conteo distribuido bien diseñado en Redis (operaciones atómicas, script Lua, TTL nativo) generalmente agrega entre 1 y 3 ms de latencia, con un impacto p99 de menos de milisegundos en los casos mejor optimizados. Por el contrario, Zuplo documenta que un limitador de velocidad centralizado mal ubicado puede agregar decenas de milisegundos a cada solicitud; esta discrepancia se refleja directamente en su p99.
Estos rangos provienen de guías técnicas públicas (Tyk, Zuplo, ecosistema Apache APISIX), no de un protocolo de medición común. Indican un orden de magnitud y un principio arquitectónico (conteo atómico y local en lugar de sincrónico y centralizado), no una cifra que pueda reproducirse tal como está en una infraestructura diferente.
Cómo funciona realmente la limitación de velocidad en aura-gateway
La puerta de enlace de Aurabase utiliza la caja governor (algoritmo de depósito de tokens) como limitador de respaldo local, junto con el recuento distribuido a través de Redis para compartir el estado entre varias instancias de la puerta de enlace. El conteo distribuido pasa por un script Lua ejecutado atómicamente en el lado de Redis (INCRBY + EXPIRE en una única operación de red), no a través de un viaje de ida y vuelta de lectura y escritura que introduciría una ventana de concurrencia.
Si Redis deja de estar disponible, la puerta de enlace cambia automáticamente al limitador local governor, con un caché moka (máximo 1.000.000 de entradas, vencimiento a los 300 segundos de inactividad) para evitar volver a crear un limitador en cada solicitud. Este retroceso es observable: cada cambio incrementa un contador de Prometheus dedicado, de modo que el equipo sabe cuándo el límite efectivo vuelve a ser N instancias × límite (de lo contrario, se degrada silenciosamente el aislamiento entre instancias).
La puerta de enlace distingue la limitación de velocidad anti-DoS por IP (antes de la autenticación) de la limitación de velocidad por proyecto/clave API/cuota de usuario (después de la autenticación, con reclamaciones JWT disponibles): dos middlewares separados en la pila, cada uno con su propia granularidad.
El disyuntor: tres estados, una ventana corredera
El circuito disyuntor de Aurabase (aura_core::circuit_breaker, compartido entre la puerta de enlace y aura-ai para respaldo entre proveedores de LLM) sigue tres estados clásicos ( Closed, Open, HalfOpen ) con un recuento de fallas durante una ventana de tiempo variable en lugar de un contador que nunca se reinicia.
Un detalle de implementación que importa en producción: cambiar a HalfOpen solo permite una solicitud de sondeo a la vez (anti-thundering-herd); sin esta protección, todas las solicitudes pendientes se apresurarían simultáneamente al servicio que acaba de reabrirse, recreando inmediatamente la falla que estábamos tratando de evitar.
Dónde se ejecutan estos middlewares en la puerta de enlace
La pila de middleware de puerta de enlace de Aurabase sigue un orden preciso, verificado en el código: identificador de solicitud → registro de acceso → limitación de velocidad por IP → autenticación → limitación de velocidad por actor/cuota → disyuntor → proxy para el servicio de destino. Cada etapa rechaza el tráfico no deseado lo antes posible, antes de incurrir en un mayor costo de procesamiento posterior.
Leer el artículo completo: plano de datos vs plano de gestión en el gateway de Aurabase
Por qué no se publican aquí las cifras de Aurabase
La implementación se verifica línea por línea en el código fuente de la puerta de enlace. Pero aún no se ha ejecutado ni publicado ningún protocolo de medición reproducible en esta infraestructura específica: publicar una cifra no medida sería repetir el error de cifras de marketing sin fuente que nos negamos a reproducir. Consulte nuestra metodología de referencia completa para conocer lo que requerimos antes de publicar una cifra de rendimiento.