迁移

切换服务商时可能遇到的速率限制差异

各服务商的速率限制差异不仅在于允许的请求数量本身,只检查表面上限的迁移可能会遗漏结构上的差异,而这些差异在实践中往往比数字本身更重要。

对于您要迁入或迁出的任何服务商,有几个结构维度值得专门检查:

限制按什么计算。有些服务商只按 API 密钥限制,有些则按 IP 地址、按账户或按某种组合限制。My Geocode 的结构按网络计算免费配额,即 IPv4 按 /24、IPv6 按 /48 计算,并且来自同一网络的无密钥和有密钥使用共享这一配额。这与纯粹按密钥计算限制的模式有实质区别,对于运行在共享 IP 段之后的应用尤其重要,例如企业网络,或者许多实例共享同一地址块的云环境。

限制如何重置。按天、按月或滚动窗口都是常见做法,其差异会影响您如何考虑批量任务的节奏或如何应对流量高峰。在固定的每日边界重置的限制,面对突发流量时的表现与基于滚动窗口的限制不同。

限制信息是在每个响应中公开,还是需要单独检查。这决定了您的应用能否主动自我限流,还是只能在请求失败时才发现自己已达上限。My Geocode 直接公开这些信息:每个响应都以响应头形式携带 X-Quota-LimitX-Quota-UsedX-Quota-Free-RemainingX-Quota-Network-UsedX-Credits-RemainingX-Key-IPs-UsedX-Key-IPs-LimitX-Quota-Reset,文档见 /docs/rate-limits/。这意味着重试和节奏控制逻辑可以直接从刚收到的响应中读取当前状态,而无需轮询单独的端点或控制台。

超出限制后会发生什么。服务商是硬性停止请求、降级为较慢的响应,还是自动对超额部分计费?超出每日免费配额后,My Geocode 的模式是按每次请求 €0.0001 使用预付额度,或使用每月 €50 的 Unlimited 密钥,所有端点价格相同。值得将其与您当前服务商的超额计费或限流行为直接比较,因为在流量高峰当下如何实际影响应用的行为,这些做法可能有实质差异。

在切换之前,值得专门重写任何引用了与当前服务商绑定的特定响应头名称、状态码或数值阈值的重试或退避逻辑,而不是假设同样的逻辑可以直接适用于另一家服务商的速率限制信号。在大多数应用中这只是一小段代码,但正是这种细节,如果不专门审查,就会在迁移过程中悄无声息地出错,因为处理不当的速率限制错误往往会让真实的流量高峰变得更糟,而不是更好。