要点
根据几个专门的来源，正确实现的分布式速率限制器（原子计数、本地回退缓存）通常会为每个请求增加不到一毫秒的时间。 Aurabase 网关完全遵循此模式：用于本地反 DoS 的 governor 箱、用于实例之间分布式计数的原子 Lua Redis 脚本、Redis 不可用时的后备 moka 缓存。断路器电路减少了发生故障时的感知延迟，而不是增加延迟——它缩短了完全超时的等待时间。迄今为止，尚未发布 Aurabase 延迟数据：原因如下，以及该机制的实际工作原理。
抗 DoS 和抗级联故障，两个不同的问题
速率限制可以保护您的后端免受过多流量（无论合法与否）的影响 - 它回答了“此调用者现在是否有权发送此请求？”的问题。 ”。断路器保护您的后端免受已经下游服务的影响 - 它响应“此服务是否曾经表现出无响应，我们是否应该尝试？” ”。混淆它们会导致缩小其中之一的规模。
在 Aurabase 网关上，两者位于相同的中间件堆栈中，但位于不同的楼层：IP 速率限制在身份验证之前运行（纯粹的反 DoS，不会针对未经身份验证的流量发出计费 SQL 查询），而断路器则保护对内部服务或 LLM 提供商的传出呼叫。
成本完全取决于实施，而不是原则
根据 Tyk 和 APISIX 生态系统指南，Redis 上精心设计的分布式计数（原子操作、Lua 脚本、本机 TTL）通常会增加 1-3 毫秒的延迟，在最佳优化的情况下会产生亚毫秒级的 p99 影响。相反，Zuplo 文档表明，放置不当的集中式速率限制器可能会为每个请求增加数十毫秒 - 这种差异直接反映在您的 p99 中。
这些范围来自公共技术指南（Tyk、Zuplo、Apache APISIX 生态系统），而不是来自通用测量协议。它们表明了一个数量级和一个架构原则——原子和本地计数，而不是同步和集中计数——而不是像在不同基础设施上那样复制的数字。
速率限制在 aura-gateway 中的实际工作原理
Aurabase 网关使用 governor crate（令牌桶算法）作为本地回退限制器，并通过 Redis 进行分布式计数，以在网关的多个实例之间共享状态。分布式计数通过在 Redis 端原子执行的 Lua 脚本（单个网络操作中的INCRBY + EXPIRE），而不是通过会引入并发窗口的先读后写往返行程。
如果 Redis 不可用，网关会自动切换到本地限制器 governor，并带有缓存 moka （最多 1,000,000 个条目，不活动 300 秒后过期），以避免在每个请求上重新创建限制器。这种回退是可以观察到的：每次切换都会增加一个专用的 Prometheus 计数器，以便团队知道有效限制何时再次变为 N 个实例 × 限制（否则会导致实例间隔离性能降低）。
网关区分 IP 的反 DoS 速率限制（身份验证之前）和项目/API 密钥/用户配额的速率限制（身份验证后，具有可用的 JWT 声明）——堆栈中的两个独立的中间件，每个中间件都有自己的粒度。
断路器：三种状态，滑动窗口
Aurabase 断路器电路（aura_core::circuit_breaker，在网关和 aura-ai 之间共享，用于 LLM 提供商之间的回退）遵循三种经典状态 — Closed、 Open、 HalfOpen — 在滑动时间窗口内进行故障计数，而不是永不重置的计数器。
在生产中重要的实现细节：切换到 HalfOpen 一次只允许一个探测请求（反雷群）——如果没有这个保护，所有待处理的请求将同时涌向刚刚重新打开的服务，立即重现我们试图避免的故障。
这些中间件在网关中运行的位置
Aurabase 网关中间件堆栈遵循精确的顺序，并在代码中进行验证：请求标识符→访问日志→IP 速率限制→身份验证→参与者/配额速率限制→断路器→代理到目标服务。每个阶段都会尽早拒绝不需要的流量，以免给下游带来更高的处理成本。
为什么这里没有发布 Aurabase 数据
在网关源代码中逐行验证了实现。但在这个特定的基础设施上尚未运行和发布可重复的测量协议——发布未测量的数据将重复我们拒绝重复的无源营销数据的错误。在发布性能数据之前，请参阅我们完整的 基准测试方法 以了解我们的要求。