查看 Apigee Edge 說明文件。
前往
Apigee X說明文件。 資訊
結果
使用配額政策來設定 API Proxy 允許的要求訊息數量 一段時間,例如分鐘、小時、日、週或月。您可以將配額設為 同樣適用於存取 API Proxy 的所有應用程式,您也可以根據下列項目設定配額:
- 包含 API Proxy 的產品
- 要求 API 的應用程式
- 應用程式開發人員
- 其他條件
請勿使用配額來防範整體流量遽增的情況。在這方面,請走到「尖銳妙招」 政策。請參閱 Spike Arrest 政策。
影片
以下影片說明如何透過配額政策管理配額:
簡介 (新邊緣)
簡介 (經典邊緣)
動態配額
分散式 &同步
訊息權重
日曆
滾動式時間區間
Flexi
條件配額
流程變數
處理錯誤
範例
這些政策程式碼範例說明如何透過以下方式設定配額週期:
更多動態配額
<Quota name="CheckQuota"> <Interval ref="verifyapikey.verify-api-key.apiproduct.developer.quota.interval">1</Interval> <TimeUnit ref="verifyapikey.verify-api-key.apiproduct.developer.quota.timeunit">hour</TimeUnit> <Allow count="200" countRef="verifyapikey.verify-api-key.apiproduct.developer.quota.limit"/> </Quota>
透過動態配額,您可以設定單一配額政策來強制執行不同的配額 以接收設定帳單配額設定的另一個術語 也就是「服務方案」。動態配額會檢查應用程式「服務方案」下一步 強制執行這些設定。
注意:如果同時指定值和元素的參照, 參照可優先處理如果參照未在執行階段解析,則該值將
舉例來說,建立 API 產品時,您可以選擇設定允許的配額 限制、時間單位和間隔不過,在 API 產品中設定這些值無法 並在 API Proxy 中強制使用 Proxy。您也必須為符合下列條件的 API Proxy 新增配額政策 讀取這些值。請參閱建立 API 產品
在上述範例中,包含配額政策的 API Proxy 會使用 VerifyAPIKey
名為 verify-api-key
的政策,用於驗證要求中傳送的 API 金鑰。
接著,配額政策會從 VerifyAPIKey 政策存取流程變數,以讀取配額
所設定的值。如要進一步瞭解 VerifyAPIKey 流程變數,請參閱驗證 API 金鑰政策。
另一種做法是為個別開發人員或應用程式設定自訂屬性 這些值。舉例來說,如要為每個 Pod 設定不同的配額值 開發人員。在此情況下,您在包含限制的開發人員上設定了自訂屬性。 以及個別時間單位和時間間隔接著,您可以在配額政策中參照這些值,如下所示 如下:
<Quota name="DeveloperQuota"> <Identifier ref="verifyapikey.verify-api-key.client_id"/> <Interval ref="verifyapikey.verify-api-key.developer.timeInterval"/> <TimeUnit ref="verifyapikey.verify-api-key.developer.timeUnit"/> <Allow countRef="verifyapikey.verify-api-key.developer.limit"/> </Quota>
此範例也會使用 VerifyAPIKey 流程變數來參照自訂屬性 實際設定
您可使用任何變數設定配額政策的參數。這些變數可以 來源:
- 流程變數
- API 產品、應用程式或開發人員的屬性
- 鍵/值對應 (KVM)
- 標題、查詢參數、表單參數等
您可以為每個 API Proxy 新增配額政策,並參照與 其他 Proxy 中的其他配額政策,配額政策也可以參照 該政策和 Proxy 的專屬變數。
開始時間
<Quota name="QuotaPolicy" type="calendar"> <StartTime>2017-02-18 10:30:00</StartTime> <Interval>5</Interval> <TimeUnit>hour</TimeUnit> <Allow count="99"/> </Quota>
如果配額的 type
設為 calendar
,您必須定義
明確的 <StartTime>
值。時間值為 GMT 時間,而非當地時間
讓應用程式從可以最快做出回應的位置
回應使用者要求如果無法為類型政策提供 <StartTime>
值
calendar
,Edge 會發生錯誤。
系統會根據 <StartTime>
重新整理各個應用程式的配額計數器。
<Interval>
和 <TimeUnit>
值為此
例如,「配額」會從格林威治標準時間 2017 年 2 月 18 日上午 10:30 開始計算,每
5 小時。因此,下次重新整理時間為格林威治標準時間 2017 年 2 月 18 日下午 3:30。
存取計數器
<Quota name="QuotaPolicy"> <Interval>5</Interval> <TimeUnit>hour</TimeUnit> <Allow count="99"/> </Quota>
API Proxy 可以存取配額政策設定的流程變數。您可以存取 透過 API Proxy 執行這些流程變數以執行條件式處理,請監控政策 超出配額上限時,請將目前的配額計數器退回應用程式 理由。
因為存取政策的流程變數是以政策為基礎
name
屬性,針對上述名為「QuotaPolicy
」的政策
以下列格式存取其流程變數:
ratelimit.QuotaPolicy.allowed.count
:允許的數量。ratelimit.QuotaPolicy.used.count
:目前的計數器值。ratelimit.QuotaPolicy.expiry.time
:計數器重設時間 (世界標準時間)。
您可以使用許多其他流程變數,如下所述。
舉例來說,您可以使用下列 AssignMessage 政策傳回配額值 做為回應標頭的流程變數:
<AssignMessage async="false" continueOnError="false" enabled="true" name="ReturnQuotaVars"> <AssignTo createNew="false" type="response"/> <Set> <Headers> <Header name="QuotaLimit">{ratelimit.QuotaPolicy.allowed.count}</Header> <Header name="QuotaUsed">{ratelimit.QuotaPolicy.used.count}</Header> <Header name="QuotaResetUTC">{ratelimit.QuotaPolicy.expiry.time}</Header> </Headers> </Set> <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables> </AssignMessage>
第一個請求
<Quota name="MyQuota"> <Interval>1</Interval> <TimeUnit>hour</TimeUnit> <Allow count="10000"/> </Quota>
使用此程式碼範例可強制要求每小時 10,000 次呼叫。政策重設 每個小時頂端的配額計數器如果計數器達到 10,000 次呼叫配額 10,000 點之後的呼叫都會遭到拒絕。
舉例來說,如果計數器從 2017-07-08 07:00:00
開始,則會重設為
2017-07-08 08:00:00
為 0 (自開始時間起的 1 小時)。如果第一則訊息
透過 2017-07-08 07:35:28
接收,且訊息計數達到 10,000
在 2017-07-08 08:00:00
前,超過這個數量的呼叫都會遭到拒絕,直到
計數會在一小時內重設。
計數器重設時間是以 <Interval>
和
<TimeUnit>
。舉例來說,如果您將 <Interval>
設為
一小時內 12 <TimeUnit>
,之後計數器每 12 小時重設一次。
你可以將 <TimeUnit>
設為分鐘、小時、天、週或月。
您可以在 API Proxy 中的多個位置參照這項政策。例如,您可以 將其放進 Proxy PreFlow 後,每次要求都會執行或者,您也可以將 並套用至多個流程如果這項政策在網站的多個位置 Proxy,它會維護單一計數器,並由政策的所有執行個體更新。
或者,您也可以在 API Proxy 中定義多項配額政策。每項配額政策
會根據政策的 name
屬性維護自己的計數器。
設定 ID
<Quota name="QuotaPolicy" type="calendar"> <Identifier ref="request.header.clientId"/> <StartTime>2017-02-18 10:00:00</StartTime> <Interval>5</Interval> <TimeUnit>hour</TimeUnit> <Allow count="99"/> </Quota>
根據預設,配額政策會定義 API Proxy 的單一計數器,
特定要求的來源或者,您也可以使用 <Identifier>
屬性
並有配額政策,根據
<Identifier>
屬性。
舉例來說,您可以使用 <Identifier>
標記定義
每個用戶端 ID接著,用戶端應用程式向 Proxy 發出要求時,會傳遞含有
clientID
,如上例所示。
您可以為 <Identifier>
屬性指定任何資料流變數。適用對象
舉例來說,您可以指定 id
這個查詢參數包含
ID:
<Identifier ref="request.queryparam.id"/>
如果您使用 VerifyAPIKey 政策來驗證 API 金鑰或 OAuthV2 政策
,您可以使用 API 金鑰或權杖中的資訊,
計數器。例如,下列
<Identifier>
標記使用 client_id
流程變數
名為 verify-api-key
的 VerifyAPIKey 政策:
<Identifier ref="verifyapikey.verify-api-key.client_id"></Identifier>
現在每個不重複的 client_id
值都會在配額中定義自己的計數器
政策。
類別
<Quota name="QuotaPolicy"> <Interval>1</Interval> <TimeUnit>day</TimeUnit> <Allow> <Class ref="request.header.developer_segment"> <Allow class="platinum" count="10000"/> <Allow class="silver" count="1000" /> </Class> </Allow> </Quota>
您可以使用以類別為基礎的配額數量,動態設定配額限制。在這個例子中
配額限制取決於 developer_segment
的值
與每個要求一起傳遞的標頭。該變數的值可以是 platinum
或 silver
。如果標頭含有無效值,政策會傳回配額
違規錯誤。
關於配額政策
配額是 API Proxy 可在一段時間內處理的要求訊息配額。 ,例如分鐘、小時、天、週或月。政策會維護計數器, API Proxy 收到的要求。這項功能可讓 API 供應商針對以下項目強制執行限制: 應用程式在一段時間內發出的 API 呼叫次數。您可以使用配額政策, 例如,將應用程式限制為每分鐘 1 個要求,或限制每月 10,000 個要求。
舉例來說,如果將配額定義為每月 10,000 則訊息,頻率限制會從以下時間過後開始計算: 第 10,000 則訊息不論第一天是否計算了 10,000 封郵件 該週期的最後一天;在配額計數器之前都不允許其他要求區域 會在指定的時間間隔結束時自動重設,或直到明確列出配額為止 使用重設配額 政策。
針對名為 SpikeArrest 的配額的變化,可避免流量暴增 (或突發), 可能是使用量激增、發生錯誤用戶端或惡意攻擊所致。如要 如要瞭解 SpikeArrest,請參閱《Spike Arrest 政策》。
配額適用於個別 API Proxy,且不會分配到 API Proxy 中。例如: 如果在一項 API 產品中有三個 API Proxy,則一個配額不會供這三個 API 共用 就算這三項都使用相同的配額政策設定也一樣。
配額政策類型
配額政策支援數種不同類型的政策:預設、calendar
、
flexi
和rollingwindow
。每個類型都會定義配額計數器的時機
以及重設時間,如下表所示:
時間單位 | 已重設預設值 (或空值) | 已重設日曆 | Flexi 重設 |
---|---|---|---|
分鐘 | 下一分鐘開始 | <StartTime> 過後 1 分鐘 |
提出第一項要求後一分鐘 |
小時 | 後一小時頂端 | <StartTime> 過後 1 小時 |
首次提出要求後一小時 |
天 | 午夜 (格林威治標準時間) 當天 | <StartTime> 過後 24 小時 |
首次提出要求後 24 小時 |
週 | 星期日的午夜 (格林威治標準時間週日) | <StartTime> 過後 1 週 |
首次提出要求後一週 |
個月 | 午夜 (格林威治標準時間) 當月最後一天 | <StartTime> 過後 1 個月 (28 天) |
首次提出要求後一個月 (28 天) |
如果是 type="calendar"
,您必須指定
<StartTime>
。
資料表不會列出 rollingwindow
類型的值。滾動週期
配額是設定配額「時間範圍」的大小,例如 1 小時或一天的時間範圍。如果
政策會判斷配額在過去是否已超過配額
「視窗」讓應用程式從可以最快做出回應的位置
回應使用者要求
例如,您定義一個小時內允許 1000 個要求的時段。新要求 這項規則會計算過去 2 小時內的配額數量 也就是從下午 2:45 算起的要求數量如果該配額 2 小時,則系統會允許該要求。
一分鐘後,下午 4:46,又收到另一個要求現在政策會計算 配額上限 (自下午 2:46 起算),確認是否超出上限。
如果是 rollingwindow
類型,計數器永遠不會重設,但會
重新計算。
瞭解配額計數器
根據預設,無論要求多少次,配額政策都維持單一計數器
可在 API Proxy 中參照配額計數器的名稱是
政策的 name
屬性。
舉例來說,您可以建立名為 MyQuotaPolicy
的配額政策,上限為 5 項
並放在 API Proxy 的多個流程 (流程 A、B 和 C) 上。雖然
共用的表格會維護單一計數器,該計數器會與
政策:
- 已執行流程 A ->已執行 MyQuotaPolicy,計數器 = 1
- 已執行流程 B ->已執行 MyQuotaPolicy,計數器 = 2
- 已執行流程 A ->已執行 MyQuotaPolicy,計數器 = 3
- 已執行流程 C ->已執行 MyQuotaPolicy,計數器 = 4
- 已執行流程 A ->已執行 MyQuotaPolicy,計數器 = 5
配額計數器已達上限,因此在三個流程中的任何一項要求都會遭到拒絕 對應用程式的限制
在 API Proxy 流程中的多個位置使用同一項配額政策, 不會無意導致配額耗盡的速度超出預期, The Book of Apigee Edge 反面模式。
或者,您也可以在 API Proxy 中定義多項配額政策,
政策。每個配額政策都有自己的計數器,
政策的 name
屬性。
或者,使用
以下位置中的 <Class>
或 <Identifier>
元素:
配額政策,可在單一政策中定義多個不重複的計數器。只要使用這些節點
元素,單一政策可根據發出要求的應用程式維護不同的計數器;
發出請求的應用程式開發人員、用戶端 ID 或其他用戶端 ID 等。詳情請參閱
請參閱上述範例,進一步瞭解如何使用
<Class>
或 <Identifier>
元素。
時間標記法
所有配額時間均設為座標通用 時間 (世界標準時間)。
配額時間標記法採用國際標準日期標記法 標準 ISO 8601。
日期會定義年、月、日,格式如下:YYYY-MM-DD
。
舉例來說,2015-02-04
代表 2015 年 2 月 4 日。
時間是以小時、分鐘和秒鐘的格式定義,
hours:minutes:seconds
。例如,23:59:59
代表時間
請注意,00:00:00
和 24:00:00
這兩個標記
區分可能與某日期相關聯的兩個午夜。因此,2015-02-04
24:00:00
與 2015-02-05 00:00:00
相同。後者是
通常是建議使用的標記法
透過 API 產品設定取得配額設定
您可以在 API 產品設定中指定配額限制。系統不會自動啟用這些限制 強制執行配額但可以參考配額政策中的產品配額設定。以下是一些 設定產品配額,方便參考以下好處:
- 配額政策可以在 API 產品中的所有 API Proxy 中使用統一設定。
- 您可以在執行階段中變更 API 產品的配額設定和配額政策 配額值會自動更新。
若要進一步瞭解如何使用 API 產品的配額設定,請參閱「動態配額」 。
如要瞭解如何設定設有配額限制的 API 產品,請參閱「建立 API 產品」。
元素參照
以下是您可以為這項政策設定的元素和屬性。請注意
互斥或不需要使用。請參閱特定使用範例。
在預設情況下,可使用下列 verifyapikey.VerifyAPIKey.apiproduct.*
變數:
名為「VerifyAPIKey」的 Verification API 金鑰政策用於檢查要求中的應用程式 API 金鑰。
變數值來自與金鑰相關聯的 API 產品配額設定
遵循從 API 產品取得配額設定
設定
<Quota async="false" continueOnError="false" enabled="true" name="Quota-3" type="calendar"> <DisplayName>Quota 3</DisplayName> <Allow count="2000" countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/> <Allow> <Class ref="request.queryparam.time_variable"> <Allow class="peak_time" count="5000"/> <Allow class="off_peak_time" count="1000"/> </Class> </Allow> <Interval ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.interval">1</Interval> <TimeUnit ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.timeunit">month</TimeUnit> <StartTime>2017-7-16 12:00:00</StartTime> <Distributed>false</Distributed> <Synchronous>false</ Synchronous> <AsynchronousConfiguration> <SyncIntervalInSeconds>20</ SyncIntervalInSeconds> <SyncMessageCount>5</ SyncMessageCount> </AsynchronousConfiguration> <Identifier/> <MessageWeight/> </Quota>
<Quota>屬性
<Quota async="false" continueOnError="false" enabled="true" name="Quota-3" type="calendar">
以下是這項政策專用屬性。
屬性 | 說明 | 預設 | 存在必要性 |
---|---|---|---|
類型 |
用於決定配額計數器檢查配額用量的時機和方式。詳情請見 配額政策類型。 如果您省略 有效值包括:
|
日曆 | 選用 |
下表說明所有政策父項元素的共同屬性:
屬性 | 說明 | 預設 | 存在必要性 |
---|---|---|---|
name |
政策的內部名稱。 視需要使用 |
不適用 | 必填 |
continueOnError |
如果設為「 如果設為 |
false | 選用 |
enabled |
如要強制執行政策,請設為 設為 |
true | 選用 |
async |
此屬性已淘汰。 |
false | 已淘汰 |
<DisplayName>元素
除 name
屬性外,一併使用
管理 UI Proxy 編輯器,使用不同的自然語言名稱。
<DisplayName>Policy Display Name</DisplayName>
預設 |
不適用 如果省略這個元素,政策的 |
---|---|
存在必要性 | 選用 |
類型 | 字串 |
<Allow>元素
指定配額的數量限制。如果政策回應次數達到這項限制 值,後續呼叫就會遭到拒絕,直到計數器重設為止。
以下顯示三種 <Allow>
元素的設定方式:
<Allow count="2000"/>
<Allow countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>
<Allow count="2000" countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>
如果同時指定 count
和 countRef
,則 countRef
就會優先處理如果 countRef
未在執行階段解析,則
已使用 count
。
預設: | 不適用 |
所在地: | 選用 |
類型: | 整數 |
屬性
屬性 | 說明 | 預設 | 存在必要性 |
---|---|---|---|
數量 |
用於指定配額的訊息數量。 例如, |
2000 | 選用 |
countRef |
用於指定流程變數,其中包含配額的訊息數量。
|
無 | 選用 |
<Allow>/<Class>元素
<Class>
元素可讓您設定值的條件式
接收 <Allow>
元素的分割要求。適用對象
每個不同的 <Allow>
子標記 <Class>
政策會維護不同的計數器
如要使用 <Class>
元素,請使用
將 ref
屬性設為 <Class>
標記。接著,邊緣會使用
流程變數,選取其中一個 <Allow>
子標記,以決定允許
政策的數量。邊緣比對 Flow 變數的值和 class
<Allow>
標記的屬性,如下所示:
<Allow> <Class ref="request.queryparam.time_variable"> <Allow class="peak_time" count="5000"/> <Allow class="off_peak_time" count="1000"/> </Class> </Allow>
在這個範例中,目前的配額計數器取決於
與每個要求一起傳遞的 time_variable
查詢參數。這個變數可以有值
共 peak_time
或 off_peak_time
。如果查詢參數包含無效值
值,政策會傳回配額違規錯誤。
預設: | 不適用 |
所在地: | 選用 |
類型: | 不適用 |
屬性
屬性 | 說明 | 預設 | 存在必要性 |
---|---|---|---|
參考資料 |
用於指定包含配額配額類別的流程變數。 |
無 | 必填 |
<Allow>/<Class>/<Allow> 元素
<Allow>
元素會指定配額計數器的限制
由 <Class>
元素定義。對於每項
不同的 <Allow>
子標記 (<Class>
的子標記)、
政策維護了不同的計數器。
例如:
<Allow> <Class ref="request.queryparam.time_variable"> <Allow class="peak_time" count="5000"/> <Allow class="off_peak_time" count="1000"/> </Class> </Allow>
在這個範例中,配額政策維護了兩個名為
共 peak_time
和 off_peak_time
。
預設: | 不適用 |
所在地: | 選用 |
類型: | 不適用 |
屬性
屬性 | 說明 | 預設 | 存在必要性 |
---|---|---|---|
類別 |
定義配額計數器的名稱。 |
無 | 必填 |
數量 | 指定計數器的配額限制。 | 無 | 必填 |
<Interval>元素
用於指定與
您透過 TimeUnit
(分鐘、小時、天、週或月) 來決定時間
這段期間內,Edge 會計算配額用量。
例如 24
的 Interval
,且
hour
的 TimeUnit
表示配額將
計算依據為 24 小時的期間
<Interval ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.interval">1</Interval>
預設: | 無 |
所在地: | 必填 |
類型: | 整數 |
屬性
屬性 | 說明 | 預設 | 存在必要性 |
---|---|---|---|
參考資料 |
用於指定流程變數,這個變數包含
配額。 |
無 | 選用 |
<TimeUnit>元素
用於指定配額適用的時間單位。
例如 24
的 Interval
,且
hour
的 TimeUnit
表示配額將
計算依據為 24 小時的期間
<TimeUnit ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.timeunit">month</TimeUnit>
預設: | 無 |
所在地: | 必填 |
類型: |
字串。選項包括: |
屬性
屬性 | 說明 | 預設 | 存在必要性 |
---|---|---|---|
參考資料 | 用於指定包含配額時間單位的流程變數。ref
的優先順序高於明確間隔值。如果 ref 執行
沒有在執行階段解析,系統就會使用該值。 |
無 | 選用 |
<StartTime>元素
將 type
設為 calendar,
時,系統會指定日期
配額計數器開始計算的時間,以及無論要求是否送出要求
接收的影格速率
當 type
已明確設定時,您必須提供明確的 StartTime
將 指向 calendar,
,您就無法使用資料流變數的參照。如果您指定
在沒有設定 type
值的情況下,StartTime
值,則
錯誤。
例如:
<StartTime>2017-7-16 12:00:00</StartTime>
預設: | 無 |
所在地: | 在 type 設為 calendar 時為必要項目。 |
類型: |
ISO 8601 格式的字串 。 |
<已發行>元素
安裝 Edge 時可以使用一或多個訊息處理器來處理要求。設定此項目
將元素設為 true
,指定政策應維持
並持續同步處理所有訊息處理器。訊息處理器
可以跨越可用區和/或區域運作
如果您使用預設值 false
,則可能會超出配額,因為
系統不會共用每個訊息處理器的次數:
<Distributed>true</Distributed>
為確保系統能同步處理計數器,並針對每個要求進行更新,請
<Distributed>
和 <Synchronous>
到 true:
<Distributed>true</Distributed> <Synchronous>true</Synchronous>
預設: | false |
所在地: | 選用 |
類型: | 布林值 |
<Synchronous>元素
如要同步更新分散式配額計數器,請設為 true
。這個
這表示系統會同時檢查計數器的更新,並同時檢查要求配額
至 API如果您必須不允許任何 API,請設為 true
配額。
如要以非同步方式更新配額,請設為 false
。也就是說
部分 API 呼叫可能會超過配額,實際情況取決於
中央存放區中的配額計數器會非同步更新。不過您不一定會面對
同步更新潛在的效能影響。
預設的非同步更新間隔為 10 秒。使用
AsynchronousConfiguration
元素來設定此非同步行為。
<Synchronous>false</Synchronous>
預設: | false |
所在地: | 選用 |
類型: | 布林值 |
<AsynchronousConfiguration>元素
當政策生效時,設定分散式配額計數器之間的同步處理間隔
設定元素 <Synchronous>
不存在或存在,且已設定
至 false
。
您可以使用
SyncIntervalInSeconds
或 SyncMessageCount
子元素。
而且互斥。例如:
<AsynchronousConfiguration> <SyncIntervalInSeconds>20</SyncIntervalInSeconds> </AsynchronousConfiguration>
或
<AsynchronousConfiguration> <SyncMessageCount>5</SyncMessageCount> </AsynchronousConfiguration>
預設: | SyncIntervalInSeconds = 10 秒 |
所在地: | 選用;當 <Synchronous> 設為
true 。 |
類型: |
建築 |
<AsynchronousConfiguration>/<SyncIntervalInSeconds> 元素
這可以覆寫預設行為,也就是在出現非同步更新後 間隔為 10 秒
<AsynchronousConfiguration> <SyncIntervalInSeconds>20</SyncIntervalInSeconds> </AsynchronousConfiguration>
同步間隔必須 >= 10 秒,如 限制主題。
預設: | 10 |
所在地: | 選用 |
類型: |
整數 |
<AsynchronousConfiguration>/<SyncMessageCount>元素
指定在配額之間,所有 Apigee 訊息處理器的要求數量 更新。
<AsynchronousConfiguration> <SyncMessageCount>5</SyncMessageCount> </AsynchronousConfiguration>
這個範例會指定每個 Apigee 中的配額,每 5 個要求會更新一次 邊緣訊息處理器。
預設: | 不適用 |
所在地: | 選用 |
類型: |
整數 |
<Identifier>元素
使用 <Identifier>
元素設定要建立不重複的政策
處理了流量的計數器
如果您不使用這個元素,政策就會使用要套用的單一計數器 配額。
這個 Apigee 社群貼文也會介紹這個元素: http://community.apigee.com/questions/2807/how-does-the-edge-quota-policy-work-when-no-identi.html.
<Identifier ref="verifyapikey.verify-api-key.client_id"/>
預設: | 不適用 |
所在地: | 選用 |
類型: |
字串 |
屬性
屬性 | 說明 | 預設 | 存在必要性 |
---|---|---|---|
參考資料 |
指定流程變數,識別用於要求的計數器。 ID 可以是 HTTP 標頭、查詢參數、表單參數或訊息內容 是每個應用程式、應用程式使用者、應用程式開發人員、API 產品或其他項目的專屬 ID 以及特性 最常用來識別應用程式的 在某些情況下,必須擷取配額設定,
可使用 |
不適用 | 選用 |
<MessageWeight>元素
用於指定指派給每則訊息的權重。使用訊息權重來增加 要求訊息,例如消耗更多運算資源。
舉例來說,您想要將 POST 訊息計為「重型」的兩倍或價格較高
訊息。因此,您需要將 POST 的 MessageWeight
設為 2,並將
。您甚至可以將 MessageWeight
設為 0,這樣要求就不會
會影響計數器。在此範例中,如果配額為每分鐘 10 則訊息,
POST 要求的 MessageWeight
為 2
,那麼配額會
在每 10 分鐘的時間間隔內,允許 5 個 POST 要求。任何其他要求、POST 或 GET
,否則計數器重設程序將遭到拒絕
必須以資料流指定代表 MessageWeight
的值
變數,且可以從 HTTP 標頭、查詢參數、XML 或 JSON 要求中擷取
或其他流程變數。舉例來說,您將資源設定在名為
weight
:
<MessageWeight ref="message_weight"/>
預設: | 不適用 |
所在地: | 選用 |
類型: |
整數 |
流程變數
系統會在配額政策時自動填入下列預先定義的流程變數 執行作業。如要進一步瞭解流程變數,請參閱變數參考資料。
變數 | 類型 | 權限 | 說明 |
---|---|---|---|
ratelimit.{policy_name}.allowed.count | 長 | 唯讀 | 傳回允許的配額數量 |
ratelimit.{policy_name}.used.count | 長 | 唯讀 | 傳回目前在配額間隔內使用的配額 |
ratelimit.{policy_name}.available.count | 長 | 唯讀 | 傳回配額間隔內的可用配額數量 |
ratelimit.{policy_name}.exceed.count | 長 | 唯讀 | 如果超過配額,系統會傳回 1。 |
ratelimit.{policy_name}.total.exceed.count | 長 | 唯讀 | 如果超過配額,系統會傳回 1。 |
ratelimit.{policy_name}.expiry.time | 長 | 唯讀 |
傳回以毫秒為單位的世界標準時間,決定配額的到期時間和新的 開始計算配額間隔 如果配額政策類型為 |
ratelimit.{policy_name}.identifier | 字串 | 唯讀 | 傳回附加至政策的 (用戶端) ID 參照 |
ratelimit.{policy_name}.class | 字串 | 唯讀 | 傳回與用戶端 ID 相關聯的類別 |
ratelimit.{policy_name}.class.allowed.count | 長 | 唯讀 | 傳回類別中定義的允許的配額數量 |
ratelimit.{policy_name}.class.used.count | 長 | 唯讀 | 傳回類別中已使用的配額 |
ratelimit.{policy_name}.class.available.count | 長 | 唯讀 | 傳回類別中的可用配額數量 |
ratelimit.{policy_name}.class.exceed.count | 長 | 唯讀 | 傳回超過類別內限制的要求數量 目前配額間隔 |
ratelimit.{policy_name}.class.total.exceed.count | 長 | 唯讀 | 傳回所有類別內超出該類別限制的要求總數
因此,這個數值的總和即為全部的 class.exceed.count
|
ratelimit.{policy_name}.failed | 布林值 | 唯讀 |
指出政策是否失敗 (true 或 false)。 |
錯誤參考資料
本節說明在這項政策觸發錯誤時,所傳回的錯誤代碼和錯誤訊息,以及 Edge 所設定的錯誤變數。 請務必瞭解這份資訊,以便瞭解您是否要擬定錯誤規則, 處理錯誤詳情請參閱這篇文章 瞭解政策錯誤和處理方式 發生錯誤
執行階段錯誤
執行政策時,可能會發生這些錯誤。
錯誤程式碼 | HTTP 狀態 | 原因 | 修正 |
---|---|---|---|
policies.ratelimit.FailedToResolveQuotaIntervalReference |
500 | 如果未在配額政策中定義 <Interval> 元素,就會發生這個錯誤。這個元素
是必要項目,用於指定配額適用的時間間隔。時間間隔
可以是分鐘、小時、天、週或月 (與 <TimeUnit> 元素中定義的)。 |
build |
policies.ratelimit.FailedToResolveQuotaIntervalTimeUnitReference |
500 | 如果未在配額政策中定義 <TimeUnit> 元素,就會發生這個錯誤。這個元素
為必要項目,用於指定配額適用的時間單位。時間間隔
可以是分鐘、小時、天、週或月。 |
build |
policies.ratelimit.InvalidMessageWeight |
500 | 如果透過資料流變數指定的 <MessageWeight> 元素值發生,就會發生這類情況
無效 (非整數值)。 |
build |
policies.ratelimit.QuotaViolation |
500 | 超過配額上限。 | 不適用 |
部署錯誤
錯誤名稱 | 原因 | 修正 |
---|---|---|
InvalidQuotaInterval |
如未在 <Interval> 元素中指定的配額間隔
整數,則 API Proxy 的部署作業將會失敗。舉例來說
在 <Interval> 元素中指定的是 0.1,那麼
API Proxy 故障。
|
build |
InvalidQuotaTimeUnit |
如果 <TimeUnit> 元素中指定的時間單位不受支援,
那麼 API Proxy 的部署作業就會失敗支援的時間單位為 minute 。
hour 、day 、week 和month 。
|
build |
InvalidQuotaType |
如果 <Quota> 中 type 屬性指定的配額類型
元素無效,即可部署 API Proxy。
支援的配額類型為 default 、calendar 、flexi 和 rollingwindow 。
|
build |
InvalidStartTime |
如果 <StartTime> 元素中指定的時間格式是
無效,API Proxy 的部署作業就會失敗。有效格式為 yyyy-MM-dd HH:mm:ss 。
採用 ISO 8601 日期和時間格式。適用對象
舉例來說,如果 <StartTime> 元素中指定的時間為
7-16-2017 12:00:00 ,則 API Proxy 的部署作業失敗。
|
build |
StartTimeNotSupported |
如果指定 <StartTime> 元素的配額類型並非
calendar 類型,即表示 API Proxy 的部署作業失敗。<StartTime> 元素是
僅支援「calendar 」配額類型。舉例來說,如果設定 type 屬性
設為 flexi 或 rolling window ,然後<Quota>
API Proxy 部署作業失敗。
|
build |
InvalidTimeUnitForDistributedQuota |
如果 <Distributed> 元素設為 true ,且 <TimeUnit> 元素設為
second ,則 API Proxy 的部署作業會失敗。「second 」的時間單位無效
分散式配額 |
build |
InvalidSynchronizeIntervalForAsyncConfiguration |
如果<SyncIntervalInSeconds>
配額政策中的 <AsynchronousConfiguration> 元素小於 0,
API Proxy 部署作業失敗。 |
build |
InvalidAsynchronizeConfigurationForSynchronousQuota |
如果在配額政策中將 <AsynchronousConfiguration> 元素的值設為 true ,
已使用 <AsynchronousConfiguration> 元素定義非同步設定,然後
API Proxy 部署作業失敗 |
build |
錯誤變數
當這項政策觸發錯誤時,系統會設定這些變數。詳情請參閱重要須知 政策錯誤。
錯誤回應範例
{ "fault":{ "detail":{ "errorcode":"policies.ratelimit.QuotaViolation" }, "faultstring":"Rate limit quota violation. Quota limit exceeded. Identifier : _default" } }
錯誤規則範例
<FaultRules> <FaultRule name="Quota Errors"> <Step> <Name>JavaScript-1</Name> <Condition>(fault.name Matches "QuotaViolation") </Condition> </Step> <Condition>ratelimit.Quota-1.failed=true</Condition> </FaultRule> </FaultRules>