Самое необходимое
Согласно нескольким специализированным источникам, правильно реализованный распределенный ограничитель скорости (атомарный подсчет, локальный резервный кеш) обычно добавляет менее миллисекунды на запрос. Шлюз Aurabase следует именно этому шаблону: ящик governor для локальной защиты от DoS, атомарный скрипт Lua Redis для распределенного подсчета между экземплярами, резервный кеш moka на случай, если Redis недоступен. Схема прерывателя уменьшает воспринимаемую задержку в случае сбоя, а не добавляет ее — она сокращает время ожидания полного тайм-аута. На сегодняшний день данные о задержке Aurabase не опубликованы: вот почему и как на самом деле работает этот механизм.
Защита от DoS и защита от каскадных сбоев — две разные проблемы
Ограничение скорости защищает ваш сервер от чрезмерного трафика, законного или нет — оно отвечает на вопрос «имеет ли этот абонент право отправить этот запрос сейчас?» Автоматический выключатель защищает ваш бэкэнд от уже нижестоящей службы — он отвечает на вопрос: «А эта служба когда-нибудь переставала отвечать на запросы, стоит ли нам вообще пытаться?» ". Их путаница приводит к занижению того или иного размера.
На шлюзе Aurabase оба находятся в одном стеке промежуточного программного обеспечения, но на разных этажах: ограничение скорости IP запускается до аутентификации (чистая защита от DoS, никаких SQL-запросов для выставления счетов за неаутентифицированный трафик), а автоматический выключатель защищает исходящие вызовы к внутренним службам или поставщикам LLM.
Стоимость полностью зависит от реализации, а не принципа
По словам Тайка и руководств по экосистеме APISIX, хорошо спроектированный распределенный подсчет на Redis (атомарные операции, скрипт Lua, собственный TTL) обычно добавляет задержку на 1–3 мс, а в наиболее оптимизированных случаях влияние p99 составляет субмиллисекунды. И наоборот, Zuplo документально подтверждает, что неудачно размещенный централизованный ограничитель скорости может добавить десятки миллисекунд к каждому запросу — это несоответствие отражается непосредственно на вашем p99.
Эти диапазоны взяты из общедоступных технических руководств (Tyk, Zuplo, экосистема Apache APISIX), а не из общего протокола измерений. Они указывают порядок величины и архитектурный принцип — атомарный и локальный подсчет, а не синхронный и централизованный — а не фигуру, которую можно воспроизвести в другой инфраструктуре.
Как на самом деле работает ограничение скорости в aura-gateway
Шлюз Aurabase использует ящик governor (алгоритм корзины токенов) в качестве локального резервного ограничителя в сочетании с распределенным подсчетом через Redis для разделения состояния между несколькими экземплярами шлюза. Распределенный подсчет осуществляется посредством Lua-скрипта, выполняемого атомарно на стороне Redis (INCRBY + EXPIRE в одной сетевой операции), а не посредством цикла чтения и записи туда и обратно, который вводит окно параллелизма.
Если Redis становится недоступным, шлюз автоматически переключается на локальный ограничитель governorс кешем moka (максимум 1 000 000 записей, срок действия через 300 секунд бездействия), чтобы избежать повторного создания ограничителя при каждом запросе. Этот запасной вариант можно наблюдать: каждый переключатель увеличивает выделенный счетчик Prometheus, чтобы команда знала, когда эффективный предел снова станет N экземпляров × лимит (в противном случае происходит бесшумное ухудшение изоляции между экземплярами).
Шлюз отличает ограничение скорости защиты от DoS по IP (до аутентификации) от ограничения скорости по проекту/ключу API/квоте пользователя (после аутентификации, с доступными утверждениями JWT) — два отдельных промежуточных программного обеспечения в стеке, каждое со своей степенью детализации.
Автоматический выключатель: три состояния, скользящее окно
Схема выключателя Aurabase (aura_core::circuit_breaker, совместно используемая шлюзом и aura-ai для возврата между поставщиками LLM) следует трем классическим состояниям — Closed, Open, HalfOpen — с подсчетом сбоев в течение скользящего временного окна, а не со счетчиком, который никогда не сбрасывается.
Деталь реализации, которая имеет значение в производстве: переключение на HalfOpen позволяет одновременно выполнять только один зондирующий запрос (анти-громовое стадо) — без этой защиты все ожидающие запросы одновременно устремлялись бы к только что вновь открывшемуся сервису, немедленно воссоздавая сбой, которого мы пытались избежать.
Где это промежуточное ПО работает в шлюзе
Стек промежуточного программного обеспечения шлюза Aurabase следует точному порядку, проверенному в коде: идентификатор запроса → журнал доступа → ограничение скорости по IP → аутентификация → ограничение скорости по субъекту/квоте → автоматический выключатель → прокси-сервер для целевой службы. Каждый этап отклоняет нежелательный трафик как можно раньше, прежде чем повлечет за собой более высокие затраты на обработку в дальнейшем.
Прочитайте статью полностью: плоскость данных и плоскость управления в шлюзе Aurabase
Почему здесь не публикуются цифры Aurabase
Реализация проверяется построчно в исходном коде шлюза. Но ни один воспроизводимый протокол измерений еще не был запущен и опубликован в этой конкретной инфраструктуре — публикация неизмеренных цифр будет означать повторение ошибки необоснованных маркетинговых цифр, которые мы отказываемся воспроизводить. Ознакомьтесь с нашей полной методикой тестирования , чтобы узнать, что нам нужно, прежде чем публиковать показатели производительности.