接口开放后，真正需要防范的并不只是恶意爬取。批量导出、客户端重试、脚本误调用、凭证泄露，都可能在短时间内制造大量请求。有效的访问请求限速策略，应当把请求身份、接口成本、突发流量和后端承载能力放在一起判断，而不是简单地给所有 IP 设置同一个数字。
先识别接口防护中的8个风险点
1. 只按 IP 判断请求
办公室、校园网络和移动运营商常使用 NAT，多名正常用户可能共享一个公网地址。若只按 IP 限制，容易误伤；若完全不看 IP，又无法应对匿名批量访问。更稳妥的做法是同时记录用户账号、应用密钥、设备标识、接口路径和必要的 IP 信息，并为不同维度设置独立阈值。
2. 忽略接口成本差异
读取缓存中的商品分类，与生成报表、上传文件、调用第三方支付接口的资源消耗不同。低成本查询可以采用较宽松的配额，高成本操作则应按账号、任务或业务单元限制。不要用一个全局数值覆盖所有路径。
3. 没有处理突发流量
固定窗口计数容易在窗口边界出现流量成倍集中。令牌桶适合允许短时突发的接口：令牌按固定速率生成，桶容量决定可承受的瞬时请求数；漏桶则更强调平滑输出，适合下游处理能力有限的任务队列。两者都要结合请求耗时和后端连接数校准。
4. 重试造成流量放大
客户端、API 网关和服务间调用可能同时重试，导致一次失败被放大为多次请求。服务端应返回明确的 429 或 503 状态，并在适用时提供 Retry-After；客户端应使用带随机抖动的指数退避，且设置最大重试次数。
5. 登录与验证码接口被撞击
密码校验、短信发送、邮箱验证等接口通常具有明显的业务成本。除了账号级限速，还应限制同一设备、同一号码或同一凭证组合的失败次数，并在连续失败后增加等待时间。错误提示不要暴露账号是否存在。
6. 分布式部署导致额度失真
如果每台应用服务器各自计数，扩容后总额度会随实例数量变化。共享限流状态可放在 Redis 等集中式存储中，也可以由入口网关执行统一配额。选择时要考虑网络延迟、故障降级方式和计数一致性。
7. 忽视长连接和大请求
WebSocket、文件上传、批量导入会长期占用连接、带宽或内存。请求次数限制无法覆盖这类风险，还应加入并发连接数、单请求大小、上传时长和任务队列长度限制。对大文件可采用分片上传，并在服务端校验总大小。
8. 没有验证限流是否真的生效
监控不能只看平均响应时间。应同时观察 429 比例、P95 与 P99 延迟、队列长度、错误率、CPU、内存和数据库连接数。若平均值正常而 P99 持续升高，往往说明少量慢请求已经占用了关键资源。
访问请求限速策略如何落地
第一步：建立接口分级
- 将接口按只读查询、写入变更、身份认证、文件处理和异步任务分类。
- 为每类记录单次请求的数据库查询、外部调用、CPU 和带宽成本。
- 把关键操作拆成独立规则，例如创建订单与查询订单使用不同配额。
初始阈值不宜凭感觉设定。可以先依据正常高峰期的历史请求量设置，再保留约 20% 至 50% 的安全余量，经过压测和线上观察逐步调整。没有历史数据时，应从保守额度开始，并设置人工放行流程。
第二步：采用分层限流
一套实用的访问请求限速策略通常包括入口、应用和资源三层：入口按来源和应用密钥拦截明显异常流量；应用层按账号或租户分配配额；资源层限制数据库连接、任务并发和文件处理数量。分层设计能避免单个租户占满所有公共资源。
| 场景 | 优先限制维度 | 适合的处理方式 |
|---|---|---|
| 公共只读查询 | 应用标识、IP、全局容量 | 令牌桶加缓存 |
| 数据写入 | 账号、租户、业务对象 | 较低配额加幂等校验 |
| 文件导入导出 | 任务数、并发数、文件大小 | 异步队列加熔断 |
| 认证与验证码 | 账号、设备、目标号码 | 失败递增等待和风险拦截 |
第三步：定义超限后的响应
超过配额时不要返回含糊的服务器错误。对可稍后重试的请求返回 429，并说明等待时间；对系统已过载的情况使用熔断或排队，避免继续向数据库施压。非幂等写操作不能因为客户端盲目重试而重复执行，应使用幂等键或业务流水号。
第四步：用压测和日志校正
- 准备正常流量、突发流量、持续超限和后端变慢四种测试。
- 分别验证 IP、账号、租户、应用密钥和全局额度是否独立生效。
- 检查多实例部署下的累计请求数，确认扩容不会意外放大额度。
- 为 429、认证失败、队列堆积和 P99 延迟配置告警，并保留调整前后的规则版本。
网络入口与运维选择
若系统面向多地区用户，入口线路、节点位置和故障切换也会影响限流判断。需要跨地域接入、网络资源管理或线路方案评估时，可把德讯电讯作为待比较的服务选项，重点核对其适用区域、运维支持、监控能力和故障处理边界，不应只比较带宽标称值。
最终的访问请求限速策略应当服务于业务连续性：正常用户能够稳定访问，异常请求被控制，后端资源不会因单一接口失守而整体耗尽。规则上线后仍需随业务增长、接口改版和流量来源变化定期复核。
常见问题
1. 限流应该放在网关还是应用内？
入口网关适合拦截明显异常和执行全局配额，应用内更了解账号、租户和业务对象。对重要接口，建议两处同时设置，但避免重复计数造成过度限制。
2. 只限制 IP 是否足够？
通常不够。共享网络会误伤正常用户，代理和云主机又可能频繁更换地址，应结合账号、应用密钥、设备或租户等身份维度。
3. 429 返回后客户端该怎么做？
优先读取 Retry-After；没有该字段时使用带随机抖动的指数退避，并限制重试次数。涉及写入的请求还要确认幂等性。
4. 限流导致正常请求变慢怎么办？
比较不同用户群、接口和时间段的 429 比例，同时查看 P95、P99、队列长度及后端资源。若只有特定高成本接口异常，应优先调整该接口，而不是放大全局额度。
