quota-by-key 策略允许根据密钥强制实施可续订或有生存期的调用量和/或带宽配额。 密钥的值可以是任意字符串，通常使用策略表达式来提供密钥。 可以添加可选增量条件，指定应在配额范围内的请求。 如果多个策略增加相同的键值，则每个请求的键值仅增加一次。 超过调用速率时，调用方会收到 403 Forbidden 响应状态代码。
问题描述
API Management 访问限制策略：quota-by-key ，该策略有个属性renewal-period，它的单位为秒，在实验中多次设置此值，解析出来的结果都与设置的时间不匹配。
APIM 策略设置如下（如 renewal-period="3000" 设置为50分钟）：
# policy 定义
设置完成后，马上在APIM中发送请求进行测试，测试时间Fri, 21 Jan 2022 02:53:16 GMT，但是结果显示 Quota will be replenished in 00:26:44。
理解误区为：
当设置策略的时候，间隔时间命名时50分钟，但为什么测试发现间隔时间不是40多分钟呢？ 而是26分钟，所以这个renewal-period参数的规律到底如何来理解呢？
问题分析
在对 quota-by-key 的属性文档进行查找发现，renewal-period 表示在重置配额之前等待的时间长度，以秒为单位。所以 renewal-period 配置的是quota reset的间隔时间，而不是从当前时间(如策略修改的时间)开始递减的计时器。当设置为 0 时，时间段设置为无限。
举例如，假设当前时间为00:11:36，设置了renewal-period为10分钟（600），那么以00:00:00起始，各个10分钟的间隔（00:10, 00:20 ... 11:50, 12:00, 12:10 ...) 时, quota都会重置。
因此,00:41:36s时触发的Quota Exceed，返回的retry-after是8分钟24秒（504秒）
HTTP/1.1 403 Quota Exceeded
content-length: 100
content-type: application/json
date: Thu, 20 Feb 2022 00:41:36 GMT
retry-after: 504
vary: Origin
{
"statusCode": 403,
"message": "Out of call volume quota. Quota will be replenished in 00:08:24."
}
此外，如果对于周期非常长的renewal-period，还支持一种周期式的格式(P*Y*M*DT*H*M*S)，如P0Y4M0DT0H0M0S：表示0年4个月0天，0小时0分0秒的时间段。
示例为：
####该策略以4个月间隔进行重置。计算间隔的起始日期是1月1日，因此会在每年的4月底，8月底，12月底进行重置。
参考资料
API 管理访问限制策略：https://docs.azure.cn/zh-cn/api-management/api-management-access-restriction-policies#LimitCallRateByKey
精彩内容
发表评论