【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

當在複雜的環境中面臨問題，格物之道需：濁而靜之徐清，安以動之徐生。 雲中，恰是如此!