3. 安全限速概述
在SLS（Serverless Log Service）这类高吞吐、多租户的日志服务中，限速并不是一个“可有可无”的附加功能，而是保障系统稳定性和租户公平性的核心机制。安全限速（Safe Rate Limiting）是在普通限速基础上，引入安全边界、动态评估和分级处置能力的一类限速策略。它的目标不是简单地“卡住请求”，而是在系统过载、异常流量或恶意行为出现时，以可控、可解释、可恢复的方式保护后端资源，同时尽量不影响正常业务。
3.1 限速的定义与核心目的
限速，是指对单位时间内通过系统的请求数量、数据量或并发连接数进行约束。常见维度包括QPS（每秒请求数）、BPS（每秒字节数）、并发数以及写入分片数。安全限速则进一步强调“安全”二字：它不仅要限制流量，还要判断流量是否处于安全阈值内，是否来自可信来源，是否可能引发级联故障。
安全限速的核心目的可以归纳为四点：
- 保护后端资源：避免存储、索引、计算节点因突发流量被打满，导致整体不可用。
- 保障租户公平：防止单个租户或单个Project占用过多配额，影响其他租户。
- 抑制异常与攻击：对爬虫、重放、恶意刷量等行为进行快速识别和拦截。
- 维持可预测的SLA：在过载时优先保障核心业务，降低长尾延迟和错误率。
3.2 常见触发场景
安全限速的触发通常不是单一条件，而是多个信号叠加后的判断结果。以下是SLS工程中最常见的触发场景：
| 触发场景 | 典型信号 | 安全限速动作 |
|---|---|---|
| 突发写入洪峰 | QPS瞬时超过配额3倍，写入延迟上升 | 令牌桶快速耗尽，超出部分返回429或排队 |
| 单租户异常刷量 | 某Project写入量占集群70%以上 | 按租户维度限流，隔离异常Project |
| 恶意爬取或重放 | 相同AK/SK高频调用，User-Agent异常 | 触发黑名单或挑战机制，临时封禁 |
| 后端存储抖动 | Shard写入失败率升高，P99延迟翻倍 | 动态降低全局写入速率，保护存储 |
| 配额配置错误 | 某Logstore配额被误设为0或极大值 | 配置校验拦截，回退到默认安全值 |
这些场景说明，安全限速必须同时具备“静态配额”和“动态感知”两种能力。静态配额提供基线保护，动态感知则让限速策略能够随系统负载变化而调整。
3.3 业务影响与安全边界
限速一旦触发，业务侧会感受到明显变化。最常见的表现是写入失败、查询变慢、数据延迟增加，甚至部分日志丢失。对于日志服务而言，写入失败可能意味着监控告警延迟、审计数据缺失，进而影响故障定位和安全合规。因此，安全限速不能只考虑“限得住”，还要考虑“限得准”和“限得可恢复”。
安全边界通常由三个参数决定：
- 安全水位：系统可长期稳定运行的最大负载，一般设为峰值容量的60%～70%。
- 硬限阈值：超过该值必须立即拒绝或降级，防止系统崩溃。
- 恢复窗口：限速触发后，系统需要多长时间恢复到正常状态，避免频繁抖动。
3.4 安全限速与普通限速的区别
普通限速通常只关注“速率”本身，例如固定QPS阈值、固定并发数。它实现简单，但缺乏对系统状态和业务优先级的感知。安全限速则是一个更完整的控制闭环，包含采集、判断、执行和恢复四个阶段。
普通限速：
请求 → 计数器 → 超过阈值？ → 拒绝/放行
安全限速：
请求 → 多维采集(QPS/BPS/延迟/错误率/租户)
→ 安全评估(水位/趋势/来源/优先级)
→ 分级执行(放行/排队/降级/拒绝/封禁)
→ 恢复观察(冷却窗口/自动回退)
两者的关键差异可以总结为：普通限速是“静态开关”，安全限速是“动态调节器”。安全限速会考虑租户优先级、请求来源、业务时段和系统健康度，因此在过载时能够优先保障核心业务，而不是一刀切地拒绝所有请求。
3.5 常见误区与复盘要点
在实际工程中，安全限速最容易踩的坑有三个。第一，把限速阈值设得过低，导致正常业务被误伤；第二，只做全局限速，不做租户级隔离，导致“一个租户生病，全体租户吃药”；第三，限速触发后没有恢复机制，系统长期处于降级状态，业务无法自动恢复。
复盘时，应重点关注以下问题：限速触发时，核心业务的成功率是否保持在可接受范围？被拒绝的请求是否有明确的错误码和重试建议？限速解除后，系统是否在预期时间内恢复到正常水位？只有把这些问题回答清楚，安全限速才算真正落地，而不是停留在配置项层面。