速率限制是一种控制机制，云 API 用于调节用户可以在特定时间发出的请求数。 云 API 生成者使用速率限制来确保请求流不会使服务不堪重负。 速率限制设置 API 调用的速度和数量上限。 速率限制通常根据每个时间段的请求来定义。
云 API 为何使用速率限制
- 防止重载。 速率限制通过防止任何单个用户或服务充斥过多的请求，确保 API 服务器保持稳定且响应迅速。
- 确保公平使用。 速率限制通过确保单个用户不垄断 API 资源来强制实施公平使用策略。 速率限制允许对所有用户进行公平访问。
- 提高安全性。 速率限制通过限制来自潜在恶意源的请求数来帮助缓解分布式拒绝服务攻击和其他滥用行为。
- 管理成本。 对于云服务提供商，速率限制有助于通过防止不可预知或过度使用资源来管理运营成本。
- 保持服务质量。 速率限制通过防止流量高峰来确保所有用户的服务质量一致。
如何在应用中遇到速率限制
生成集成云 API 的应用时，请检查其文档以验证它们是否支持速率限制。 如果是，则会收到 RateLimit-... 或 X-RateLimit-... 响应标头，其中包含有关速率限制的信息。 可以在应用程序中使用此信息来确保不超过 API 的速率限制。 例如，标头 RateLimit-Remaining 指示当前窗口中剩余的请求数。 如果收到此标头设置为 0 的响应，则表明已达到速率限制，应在发送另一个请求之前等待下一个窗口。 标头 RateLimit-Reset 指示速率限制重置的时间。 某些 API 仅在达到阈值后才会发送 RateLimit-... 标头。 例如，当你的请求还剩下 10% 时。
超过速率限制时，API 会限制请求并返回 HTTP 429 Too Many Requests 状态代码。 某些 API 可能还会发送标头，以指示在发送另一个 Retry-After 请求之前应等待多长时间。 并非每个 API 都遵循此模式。 例如，GitHub可以回答，403而不是 429。
若要避免限制并确保应用程序保持响应能力，请在应用程序中实现速率限制。 根据技术堆栈，不同的库可以帮助你处理应用程序中的速率限制。 在应用程序中实现速率限制后，测试以查看它是否正确处理速率限制。
速率限制如何影响你的应用？
当 API 开始返回 429 响应时，不处理响应的应用会崩溃，显示一般错误，重试速度如此之快，导致其持续被限流，或静默丢弃数据。 开发时很少看到这一点，因为 API 很快，你是唯一的用户，并且测试数据很小。
如何测试应用处理速率限制
| Approach | 你找到的内容 | 您错过的内容 |
|---|---|---|
| 等待生产环境 | 实际限速 | 一切正常，直到用户触发它 |
| 在测试中模拟 API，或让编码代理编写模拟代码 | 重试分支是否运行 | API 的实际状态代码、速率限制标头和错误正文，以及 SDK 的重试策略。 你的应用还需要一个仅限测试的开关才能访问 mock。 |
| 调用真正的 API，直到它对你进行限流 | 真实行为 | 你不能按需触达该限制，会耗尽你的实际配额，而且某些限制仅在一小时后才会重置 |
| 截获应用的实际流量并模拟该限制 | 实际 URL、实际 SDK、重试策略以及 API 自己的标头，限制可由你自行选择 | 你的代码独立存在。 请把这个留给单元测试处理。 |
在你的应用中试用
开发代理 对你选择的 API 的请求进行计数，向响应添加速率限制标头，并在应用超出限制时返回 429 ，而应用会不断调用实际 URL。 它还会在限制重置之前再次调用 API 时告知你。
下载应用调用的 API 预设，并使用它启动开发代理：
devproxy config get github-rate-limiting
devproxy --config-file "~dataFolder/configs/github-rate-limiting/.devproxy/devproxyrc.json"
若要Microsoft Graph调用OneDrive和SharePoint（/drive，），/shares/sites请使用microsoft-graph-rate-limiting预设。 若要为任何 API 设置自己的限制，请参阅 模拟速率限制 API 响应。 若要安装开发代理，请参阅 “设置开发代理”。
