quota-by-key策略允许根据密钥强制实施可续订或有生存期的调用量和/或带宽配额。 密钥的值可以是任意字符串，通常使用策略表达式来提供密钥。 可以添加可选增量条件，指定应在配额范围内的请求。 如果多个策略增加相同的键值，则每个请求的键值仅增加一次。 超过调用速率时，调用方会收到403 Forbidden响应状态代码。
问题描述
API Management 访问限制策略：quota-by-key ，该策略有个属性renewal-period，它的单位为秒，在实验中多次设置此值，解析出来的结果都与设置的时间不匹配。
APIM 策略设置如下（如 renewal-period="3000" 设置为50分钟）：
# policy 定义 <inbound>
<base />
<quota-by-key calls="1" renewal-period="3000" counter-key="@(context.Request.IpAddress)" />
</inbound>
设置完成后，马上在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，还支持一种周期式的格式(PYMDTHMS)，如P0Y4M0DT0H0M0S：表示0年4个月0天，0小时0分0秒的时间段。
示例为：
<inbound>
<base />
<quota-by-key calls="1" renewal-period="P0Y4M0DT0H0M0S" counter-key="@(context.Request.IpAddress)" />
</inbound> ####该策略以4个月间隔进行重置。计算间隔的起始日期是1月1日，因此会在每年的4月底，8月底，12月底进行重置。
参考资料
API 管理访问限制策略：https://docs.azure.cn/zh-cn/api-management/api-management-access-restriction-policies#LimitCallRateByKey
当在复杂的环境中面临问题，格物之道需：浊而静之徐清，安以动之徐生。 云中，恰是如此!
分类: 【Azure API 管理】
