【Azure API 管理】API Management 访问限制策略[quota-by-key] 中参数 [renewal-period] 的实验和理解

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,还支持一种周期式的格式(P*Y*M*DT*H*M*S),如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

 

posted @ 2022-03-10 20:21  路边两盏灯  阅读(97)  评论(0编辑  收藏  举报