RLAAS（Rate Limiting As A Service）：现代系统中的速率限制
Source: Dev.to
请提供您希望翻译的完整文本内容，我将为您翻译成简体中文并保留原始的格式、Markdown 语法以及技术术语。谢谢！
没有人谈论的问题
每个工程团队都知道他们需要限流，但大多数方案只保护一层——API 网关。
其他所有地方会怎样？
| 痛点 | 描述 |
|---|---|
| 日志洪流 | 一个 bug 向你的可观测性堆栈发送数百万条错误日志。费用飙升，仪表盘崩溃，值班工程师被噪音淹没。 |
| 指标风暴 | 一个话唠服务在部署期间发出 50 倍于正常的 Datadog 指标。你的账单在一夜之间翻了三倍。 |
| Kafka 级联 | 一个慢速消费者落后。重试堆积。一个服务就能把整个事件管道拖垮。 |
| Sidecar 盲点 | 网格内部服务之间的流量从不经过你的网关，因而没有任何限流措施。 |
| 复制粘贴式限流 | 每个团队在自己的服务中重新实现限流逻辑，带着各自的 bug、边缘情况，且没有共享的策略。 |
根本原因在所有案例中都是相同的：限流被视为网关功能，而不是平台能力。
这正是我想要解决的问题。
介绍 RLAAS
RLAAS 是一个用 Go 编写的开源、基于策略的平台。它使用统一的引擎，在多个领域——HTTP、gRPC、遥测、事件和 sidecar——中应用一致的限流决策。
不再需要在每个服务中散落的限流代码，只需一次定义策略，即可在所有地方强制执行。
核心理念： 一个策略引擎，多种提供者，多种部署模型。
Source: …
今日支持的算法
RLAAS 并不会把你锁定在单一算法上。每个策略会独立选择最适合其流量模式的算法：
- Token Bucket – 桶以固定速率补充令牌。请求消耗令牌；当令牌耗尽时，请求被限流。适用于希望平滑突发流量而不进行硬阻断的场景。示例： 每分钟最多允许 100 次 API 调用，且允许短时间的突发。
- Sliding Window – 在持续滚动的时间窗口内跟踪请求。消除“边界峰值”问题，即客户端跨越两个固定窗口边缘时会触发双倍限制的情况。最适合精确的用户和租户配额强制。
- Fixed Window – 在硬性的时间段（例如 0–60 秒）内计数请求。简单、成本低且可预测。当粗粒度的限制比精确度更重要时使用。
- Leaky Bucket – 无论输入多么突发，都强制保持严格、稳定的输出速率。用于保护下游服务，即使总流量在限制范围内，也无法承受突发流量。
- Concurrent Request Limiter – 限制任意时刻正在进行的请求数量。对于防止慢速上游依赖被并行调用者压垮至关重要。
单个 RLAAS 部署可以在不同的策略和资源之间同时运行所有这些算法。
RLAAS 集成了哪些
一个策略引擎，多个集成点：
决策 — 不仅仅是允许或拒绝
大多数速率限制器只返回两种答案：pass 或 reject。RLAAS 则返回五种：
Shadow mode 在发布过程中尤其强大。你可以在开启强制执行之前，准确观察本应被限流的请求——没有意外，也没有事故。
每个策略都会声明自己的动作，因此一个策略可以 DENY 滥用的调用者，另一个可以 DROP 噪声遥测，而第三个在 SHADOW 模式下运行，团队则在验证阈值。
三种部署方式
- 嵌入式 SDK – 将库直接导入到您的服务中。零网络跳转，完全控制。支持 Go、Python、Java 和 TypeScript。
- 集中式服务 – 将
rlaas-server部署为共享微服务。所有服务通过 gRPC 或 HTTP 调用它以获取允许/拒绝决策。统一管理所有策略。 - Sidecar / Agent – 将
rlaas-agent作为 sidecar 与工作负载并行运行。无需代码更改。在基础设施层拦截流量。兼容 Kubernetes、服务网格和裸金属。
策略如何工作
策略是声明式且受版本控制的。您需要定义策略适用的对象、使用的算法、限制值、时间窗口以及当达到限制时的处理方式。
{
"id": "nw-payments-logs",
"org_id": "northwind",
"resource": "payments.logs",
"algorithm": "sliding_window",
"limit": 5000,
"window_seconds": 60,
"action": "drop"
}无需代码更改。 无需重新部署。 策略更新会立即生效。
为什么开源？
速率限制逻辑并不是你的竞争优势。它是基础设施——一种共享、可重用的能力，应该是透明的、可审计的，并由社区驱动。开源 RLAAS 让团队能够协作开发一个稳健、经受实战考验的解决方案，同时让每个服务专注于其核心业务逻辑。
RLAAS – 强化学习即服务
就像负载均衡器或消息队列是基础设施一样，RLAAS 应该是共享的、可组合的、基于策略的，而不是在每个微服务内部手工实现。
RLAAS 是 MIT‑许可证。每个算法、每个适配器以及每个 SDK 都是开源的，并且可以被扩展。
Try It
Docs:
GitHub:
如果这能解决你正在面对的问题，欢迎：
- 提交 issue
- 贡献适配器
- 与团队分享