摘要
1) 一句话总结 Uber 和 OpenAI 均将其限流系统从基于计数器的单服务硬拦截，重组为基础设施层的自适应软控制平台，以提升系统弹性与用户体验。
2) 关键点
- 架构转变：两家公司均放弃了传统的硬停止（hard stop）限流，转向在基础设施层实施专有的、基于策略的软控制系统（通过概率性丢弃或信用瀑布流管理流量）。
- Uber 的旧系统痛点：过去基于 Redis 令牌桶的单服务限流导致了额外延迟、配置不一致以及需要手动调整阈值等运维低效问题。
- Uber 的新架构 (GRL)：部署了全局限流器（GRL），采用三层反馈循环（数据平面本地客户端、区域聚合器、区域控制器）。
- Uber 的软限制策略：GRL 使用按比例降低流量（例如 10%）的机制取代硬停止，向调用服务施加背压而不直接关闭。
- OpenAI 的核心驱动力：重组主要为了改善 Codex 和 Sora 的用户体验，避免硬性限流打断用户的高价值探索流程。
- OpenAI 的瀑布模型：构建了实时访问引擎，将限流、免费层、信用积分等整合为单一的同步评估路径；超出限额后无缝从信用余额中扣除。
- OpenAI 的异步结算：通过流处理器异步结算信用扣款，并使用稳定的幂等键防止重复收费，确保交易可审计且维持低延迟。
- Uber 实施成果：GRL 现覆盖 1100 个服务，每秒处理超 8000 万个请求，消除了外部 Redis 依赖，并成功吸收了 15 倍的流量激增及缓解了 DDoS 攻击。
- OpenAI 实施成果：成功将信用系统集成到访问路径中，实现了实时、准确的计费，同时保持了交互式 AI 所需的低延迟性能。
3) 风险/不足
- Uber 旧系统的维护与安全风险：旧系统配置不一致增加了维护风险，导致保护不均衡（部分较小的服务没有任何限制）；此外，分散的可观测性使得难以准确定位由限流引发的问题。
- 传统计费系统的延迟缺陷：OpenAI 明确指出，传统的异步计费系统容易因延迟问题而受到影响，无法满足实时同步决策的需求。
正文
在最近的博客文章中，优步（ Uber的限流系统 ）和 OpenAI（ 超越限流：扩展对Codex和Sora的访问 ）都讨论了他们对限流方法的转变：从基于计数器的、每个服务的限流转向适应性、基于策略的系统。两家公司都开发了专有的限流平台，并在基础设施层实施。这些系统具有软控制功能，通过向客户端施加压力而不是使用硬停止来管理流量——无论是通过概率性丢弃还是基于信用的瀑布流——确保系统弹性而不牺牲用户动力。
以前，优步工程师为每个服务实施限流，通常使用由 Redis 支持的 令牌桶 。这导致了操作效率低下，例如额外的延迟，以及部署时需要调整阈值。不一致的配置增加了维护风险，并导致保护不均衡，一些较小的服务没有任何限制。此外，可观测性是分散的，使得很难准确指出由限流引起的问题。
优步用新的全球限流器（GRL）替换了这些遗留限流器。GRL 架构由一个三层反馈循环组成：优步服务网格数据平面中的限流客户端在本地执行决策，区域聚合器收集指标，区域控制器计算全局限制并将其推送回客户端。
GRL 还用一个降低可配置流量百分比（例如 10%）的系统取代了硬停止桶。这个策略作为一个软限制，对调用者服务施加压力，允许它们继续运行，而不会因配额耗尽而关闭。
OpenAI 以类似的架构实施了其新的限流器；然而，主要驱动力是 Codex 和 Sora 应用程序的用户体验，而不是运维弹性。随着越来越多的采用，OpenAI 看到了一个一致的模式：用户发现这些工具具有很大的价值，但被限流中断。虽然这些界限确保了公平的访问和系统的稳定性，但它们经常让参与的用户感到沮丧。OpenAI 寻求一种方法，通过即时基于使用量的计费，在不阻碍探索的情况下保持动力。
工程团队设计了一种综合方法，允许用户在一定限额内访问系统，超过限额后系统将从信用余额中扣除。团队将这个决策过程描述为“瀑布式”：
这个模型反映了用户对产品的实际体验。限流、免费层、信用、促销和企业权益都只是同一个决策堆栈中的层。从用户的角度来看，他们不会“切换系统”——他们只是继续使用 Codex 和 Sora。这就是为什么信用感觉不可见：它们只是瀑布中的另一个元素。
为确保这种过渡是无缝的，OpenAI 构建了一个专用的实时访问引擎，将使用跟踪、限流窗口和信用余额整合到单一评估路径中。与传统的异步计费系统不同，这些系统因延迟而受到影响，这个引擎同步地做出可证明正确的决策：每个请求在立即检查信用余额之前，都会识别出限流层的可用容量。
为保持低延迟，系统通过一个流处理器异步结算信用借记，使用稳定的 幂等键 防止双重收费。这种架构依赖于三个紧密耦合的数据流——产品使用事件、货币化事件和余额更新——确保每笔交易都是可审计和可对账的，而不会中断用户的创作流程。
优步和 OpenAI 都报告说，这些架构转变成功地实现了他们各自的操作和产品目标。在优步，全球限流器的实施已经扩展到每秒处理超过 8000 万个请求，覆盖 1100 个服务，显著降低了尾部延迟，消除了外部 Redis 依赖。该系统在生产中证明了其有效性，吸收了 15 倍的流量激增而没有退化，并在 DDoS 攻击到达内部系统之前减轻了它们。
同样，OpenAI 已经将信用系统集成到 Codex 和 Sora 的访问路径中，用连续的瀑布模型替换了硬停止。平台提供实时、准确的计费，同时保持交互式 AI 应用程序所需的低延迟性能。对于这两家公司来说，转向内部、基础设施级别的平台已经用自动化、适应性控制取代了手动配置，允许他们各自的集群在最小的人为干预下处理大规模问题。
原文链接：
https://www.infoq.com/news/2026/02/uber-openai-rate-limiting/