Anda sedang melihat dokumentasi Apigee Edge.
Buka dokumentasi
Apigee X. info

Apa
Gunakan kebijakan Kuota untuk mengonfigurasi jumlah pesan permintaan yang diizinkan oleh proxy API selama jangka waktu tertentu, seperti menit, jam, hari, minggu, atau bulan. Anda dapat menetapkan kuota agar sama untuk semua aplikasi yang mengakses proxy API, atau Anda dapat menetapkan kuota berdasarkan:
- Produk yang berisi proxy API
- Aplikasi yang meminta API
- Developer aplikasi
- Banyak kriteria lainnya
Jangan gunakan Kuota untuk melindungi dari lonjakan traffic secara keseluruhan. Untuk melakukannya, gunakan kebijakan Spike Arrest. Lihat kebijakan Penghentian Peningkatan Lalu Lintas.
Video
Video ini memperkenalkan pengelolaan kuota dengan Kebijakan kuota:
Pengantar (Edge Baru)
Pengantar (Edge Klasik)
Kuota Dinamis
Terdistribusi & Sinkron
Bobot Pesan
Kalender
Periode Berjalan
Flexi
Kuota Bersyarat
Variabel Alur
Penanganan Error
Contoh
Contoh kode kebijakan ini menggambarkan cara memulai dan mengakhiri periode kuota dengan:
Kuota Lebih Dinamis
<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>
Kuota dinamis memungkinkan Anda mengonfigurasi satu kebijakan Kuota yang menerapkan setelan Kuota yang berbeda berdasarkan informasi yang diteruskan ke kebijakan Kuota. Istilah lain untuk setelan Kuota dalam konteks ini adalah "Paket Layanan". Kuota dinamis memeriksa "Paket Layanan" aplikasi, lalu menerapkan setelan tersebut.
Catatan: Jika Anda menentukan nilai dan referensi untuk elemen, referensi akan mendapatkan prioritas. Jika referensi tidak di-resolve saat runtime, nilai tersebut akan digunakan.
Misalnya, saat membuat produk API, Anda dapat menetapkan batas kuota, unit waktu, dan interval yang diizinkan secara opsional. Namun, menetapkan nilai ini pada produk API tidak akan menerapkan penggunaannya di proxy API. Anda juga harus menambahkan kebijakan Kuota ke proxy API yang membaca nilai ini. Lihat Membuat produk API untuk mengetahui informasi selengkapnya.
Pada contoh di atas, proxy API yang berisi kebijakan Kuota menggunakan kebijakan VerifyAPIKey, yang bernama verify-api-key
, untuk memvalidasi kunci API yang diteruskan dalam permintaan. Kebijakan kuota kemudian mengakses variabel alur dari kebijakan VerifyAPIKey untuk membaca nilai kuota yang ditetapkan pada produk API. Untuk mengetahui informasi selengkapnya tentang variabel alur VerifyAPIKey, lihat Kebijakan Verify API Key.
Opsi lainnya adalah menetapkan atribut kustom pada setiap developer atau aplikasi, lalu membaca nilai tersebut dalam kebijakan Kuota. Misalnya, Anda ingin menetapkan nilai kuota yang berbeda per developer. Dalam hal ini, Anda menetapkan atribut kustom pada developer yang berisi batas, unit waktu, dan interval. Kemudian, Anda mereferensikan nilai ini dalam kebijakan Kuota seperti yang ditunjukkan di bawah ini:
<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>
Contoh ini juga menggunakan variabel alur VerifyAPIKey untuk mereferensikan atribut kustom yang ditetapkan pada developer.
Anda dapat menggunakan variabel apa pun untuk menetapkan parameter kebijakan Kuota. Variabel tersebut dapat berasal dari:
- Variabel alur
- Properti di produk, aplikasi, atau developer API
- Peta nilai kunci (KVM)
- Header, parameter kueri, parameter formulir, dll.
Untuk setiap proxy API, Anda dapat menambahkan kebijakan Kuota yang mereferensikan variabel yang sama dengan semua kebijakan Kuota lainnya di semua proxy lainnya, atau kebijakan Kuota dapat mereferensikan variabel yang unik untuk kebijakan dan proxy tersebut.
Waktu Mulai
<Quota name="QuotaPolicy" type="calendar"> <StartTime>2017-02-18 10:30:00</StartTime> <Interval>5</Interval> <TimeUnit>hour</TimeUnit> <Allow count="99"/> </Quota>
Untuk Kuota dengan type
ditetapkan ke calendar
, Anda harus menentukan nilai <StartTime>
eksplisit. Nilai waktu adalah waktu GMT, bukan waktu lokal. Jika Anda tidak memberikan nilai <StartTime>
untuk kebijakan jenis
calendar
, Edge akan menampilkan error.
Penghitung Kuota untuk setiap aplikasi diperbarui berdasarkan nilai <StartTime>
,
<Interval>
, dan <TimeUnit>
. Untuk contoh
ini, Kuota mulai dihitung pada pukul 10.30 GMT pada 18 Februari 2017, dan diperbarui setiap
5 jam. Oleh karena itu, pembaruan berikutnya akan dilakukan pada pukul 15.30 GMT pada 18 Februari 2017.
Penghitung Akses
<Quota name="QuotaPolicy"> <Interval>5</Interval> <TimeUnit>hour</TimeUnit> <Allow count="99"/> </Quota>
Proxy API memiliki akses ke variabel alur yang ditetapkan oleh kebijakan Kuota. Anda dapat mengakses variabel alur ini di proxy API untuk melakukan pemrosesan bersyarat, memantau kebijakan saat mendekati batas kuota, menampilkan penghitung kuota saat ini ke aplikasi, atau untuk alasan lainnya.
Karena akses variabel alur untuk kebijakan didasarkan pada atribut
name
kebijakan, untuk kebijakan di atas yang bernama QuotaPolicy
, Anda
mengakses variabel alur dalam bentuk:
ratelimit.QuotaPolicy.allowed.count
: Jumlah yang diizinkan.ratelimit.QuotaPolicy.used.count
: Nilai penghitung saat ini.ratelimit.QuotaPolicy.expiry.time
: Waktu UTC saat penghitung direset.
Ada banyak variabel alur lain yang dapat Anda akses, seperti yang dijelaskan di bawah.
Misalnya, Anda dapat menggunakan kebijakan AssignMessage berikut untuk menampilkan nilai variabel alur kuota sebagai header respons:
<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>
Permintaan Pertama
<Quota name="MyQuota"> <Interval>1</Interval> <TimeUnit>hour</TimeUnit> <Allow count="10000"/> </Quota>
Gunakan kode contoh ini untuk menerapkan kuota 10.000 panggilan per satu jam. Kebijakan ini mereset penghitung kuota di bagian atas setiap jam. Jika penghitung mencapai kuota 10.000 panggilan sebelum akhir jam, panggilan di atas 10.000 akan ditolak.
Misalnya, jika penghitung dimulai pada 2017-07-08 07:00:00
, penghitung akan direset ke
0 pada 2017-07-08 08:00:00
(1 jam dari waktu mulai). Jika pesan pertama
diterima pada 2017-07-08 07:35:28
dan jumlah pesan mencapai 10.000
sebelum 2017-07-08 08:00:00
, panggilan di luar jumlah tersebut akan ditolak hingga
jumlah direset pada awal jam.
Waktu reset penghitung didasarkan pada kombinasi <Interval>
dan
<TimeUnit>
. Misalnya, jika Anda menetapkan <Interval>
ke
12 untuk <TimeUnit>
jam, penghitung akan direset setiap dua belas jam.
Anda dapat menetapkan <TimeUnit>
ke menit, jam, hari, minggu, atau bulan.
Anda dapat mereferensikan kebijakan ini di beberapa tempat di proxy API. Misalnya, Anda dapat menempatkannya di Proxy PreFlow sehingga dieksekusi pada setiap permintaan. Atau, Anda dapat menempatkannya di beberapa alur di proxy API. Jika Anda menggunakan kebijakan ini di beberapa tempat dalam proxy, kebijakan ini akan mempertahankan satu penghitung yang diperbarui oleh semua instance kebijakan.
Atau, Anda dapat menentukan beberapa kebijakan Kuota di proxy API. Setiap kebijakan Kuota
mempertahankan penghitungnya sendiri, berdasarkan atribut name
kebijakan.
Menetapkan 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>
Secara default, kebijakan Kuota menentukan satu penghitung untuk proxy API, terlepas dari
asal permintaan. Atau, Anda dapat menggunakan atribut <Identifier>
dengan kebijakan Kuota untuk mempertahankan penghitung terpisah berdasarkan nilai atribut <Identifier>
.
Misalnya, gunakan tag <Identifier>
untuk menentukan penghitung terpisah untuk setiap client ID. Pada permintaan ke proxy Anda, aplikasi klien kemudian meneruskan header yang berisi
clientID
, seperti yang ditunjukkan pada contoh di atas.
Anda dapat menentukan variabel alur ke atribut <Identifier>
. Misalnya, Anda dapat menentukan bahwa parameter kueri bernama id
berisi ID unik:
<Identifier ref="request.queryparam.id"/>
Jika menggunakan kebijakan VerifyAPIKey untuk memvalidasi kunci API, atau kebijakan OAuthV2 dengan token OAuth, Anda dapat menggunakan informasi dalam kunci atau token API untuk menentukan penghitung individual untuk kebijakan Kuota yang sama. Misalnya, tag <Identifier>
berikut menggunakan variabel alur client_id
dari kebijakan VerifyAPIKey bernama verify-api-key
:
<Identifier ref="verifyapikey.verify-api-key.client_id"></Identifier>
Setiap nilai client_id
unik kini menentukan penghitungnya sendiri dalam kebijakan
Quota.
Kelas
<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>
Anda dapat menetapkan batas Kuota secara dinamis menggunakan jumlah Kuota berbasis class. Dalam contoh ini,
batas kuota ditentukan oleh nilai header developer_segment
yang diteruskan dengan setiap permintaan. Variabel tersebut dapat memiliki nilai platinum
atau silver
. Jika header memiliki nilai yang tidak valid, kebijakan akan menampilkan error pelanggaran kuota.
Tentang Kebijakan kuota
Kuota adalah alokasi pesan permintaan yang dapat ditangani oleh proxy API selama jangka waktu tertentu, seperti menit, jam, hari, minggu, atau bulan. Kebijakan ini mempertahankan penghitung yang menghitung jumlah permintaan yang diterima oleh proxy API. Kemampuan ini memungkinkan penyedia API menerapkan batas pada jumlah panggilan API yang dilakukan oleh aplikasi selama interval waktu tertentu. Dengan menggunakan kebijakan Kuota, Anda dapat, misalnya, membatasi aplikasi hingga 1 permintaan per menit,atau hingga 10.000 permintaan per bulan.
Misalnya, jika Kuota ditentukan sebagai 10.000 pesan per bulan, pembatasan kapasitas akan dimulai setelah pesan ke-10.000. Tidak masalah apakah 10.000 pesan dihitung pada hari pertama atau hari terakhir periode tersebut; tidak ada area permintaan tambahan yang diizinkan hingga penghitung Kuota secara otomatis direset pada akhir interval waktu yang ditentukan, atau hingga Kuota direset secara eksplisit menggunakan kebijakan Reset Kuota.
Variasi pada Kuota yang disebut SpikeArrest mencegah lonjakan traffic (atau burst) yang dapat disebabkan oleh peningkatan penggunaan secara tiba-tiba, klien yang bermasalah, atau serangan berbahaya. Untuk mengetahui informasi selengkapnya tentang SpikeArrest, lihat Kebijakan Spike Arrest.
Kuota berlaku untuk setiap proxy API dan tidak didistribusikan di antara proxy API. Misalnya, jika Anda memiliki tiga proxy API dalam produk API, satu kuota tidak akan dibagikan ke ketiganya meskipun ketiganya menggunakan konfigurasi kebijakan kuota yang sama.
Jenis kebijakan kuota
Kebijakan Kuota mendukung beberapa jenis kebijakan: default, calendar
,
flexi
, dan rollingwindow
. Setiap jenis menentukan kapan penghitung kuota dimulai dan direset, seperti yang ditunjukkan dalam tabel berikut:
Unit Waktu | Reset default (atau null) | reset kalender | reset fleksibel |
---|---|---|---|
menit | Awal menit berikutnya | Satu menit setelah <StartTime> |
Satu menit setelah permintaan pertama |
jam | Awal jam berikutnya | Satu jam setelah <StartTime> |
Satu jam setelah permintaan pertama |
hari | Tengah malam GMT hari ini | 24 jam setelah <StartTime> |
24 jam setelah permintaan pertama |
week | Minggu tengah malam GMT pada akhir minggu | Satu minggu setelah <StartTime> |
Satu minggu setelah permintaan pertama |
bulan | Tengah malam GMT pada hari terakhir setiap bulan | Satu bulan (28 hari) setelah <StartTime> |
Satu bulan (28 hari) setelah permintaan pertama |
Untuk type="calendar"
, Anda harus menentukan nilai
<StartTime>
.
Tabel tidak mencantumkan nilai untuk jenis rollingwindow
. Kuota periode bergulir
berfungsi dengan menetapkan ukuran "periode" kuota, seperti periode satu jam atau satu hari. Saat
permintaan baru masuk, kebijakan akan menentukan apakah kuota telah terlampaui dalam "periode" waktu
sebelumnya.
Misalnya, Anda menentukan periode dua jam yang mengizinkan 1.000 permintaan. Permintaan baru masuk pada pukul 16.45. Kebijakan ini menghitung jumlah kuota untuk periode dua jam terakhir, yang berarti jumlah permintaan sejak pukul 14.45. Jika batas kuota belum terlampaui dalam periode dua jam tersebut, permintaan akan diizinkan.
Satu menit kemudian, pada pukul 16.46, permintaan lain masuk. Sekarang kebijakan menghitung jumlah kuota sejak pukul 14.46 untuk menentukan apakah batas telah terlampaui.
Untuk jenis rollingwindow
, penghitung tidak pernah direset, tetapi
dihitung ulang pada setiap permintaan.
Memahami penghitung kuota
Secara default, kebijakan Kuota mempertahankan satu penghitung, terlepas dari berapa kali Anda
mereferensikannya di proxy API. Nama penghitung kuota didasarkan pada
atribut name
kebijakan.
Misalnya, Anda membuat kebijakan Kuota bernama MyQuotaPolicy
dengan batas 5 permintaan dan menempatkannya di beberapa alur (Alur A, B, dan C) di proxy API. Meskipun digunakan dalam beberapa alur, kebijakan ini mempertahankan satu penghitung yang diperbarui oleh semua instance kebijakan:
- Alur A dieksekusi -> MyQuotaPolicy dieksekusi dan penghitungnya = 1
- Alur kerja B dieksekusi -> MyQuotaPolicy dieksekusi dan penghitungnya = 2
- Alur A dieksekusi -> MyQuotaPolicy dieksekusi dan penghitungnya = 3
- Alur C dieksekusi -> MyQuotaPolicy dieksekusi dan penghitungnya = 4
- Alur A dieksekusi -> MyQuotaPolicy dieksekusi dan penghitungnya = 5
Permintaan berikutnya ke salah satu dari tiga alur akan ditolak karena penghitung kuota telah mencapai batasnya.
Menggunakan kebijakan Kuota yang sama di lebih dari satu tempat dalam alur proxy API, yang dapat secara tidak sengaja menyebabkan Kuota habis lebih cepat dari yang Anda perkirakan, adalah anti-pola yang dijelaskan dalam The Book of Apigee Edge Antipatterns.
Atau, Anda dapat menentukan beberapa kebijakan Kuota di proxy API dan menggunakan kebijakan yang berbeda di setiap alur. Setiap kebijakan Kuota mempertahankan penghitungnya sendiri, berdasarkan
atribut name
kebijakan.
Atau, gunakan elemen <Class>
atau <Identifier>
dalam kebijakan Kuota untuk menentukan beberapa penghitung unik dalam satu kebijakan. Dengan menggunakan elemen
ini, satu kebijakan dapat mempertahankan penghitung yang berbeda berdasarkan aplikasi yang membuat permintaan,
developer aplikasi yang membuat permintaan, client ID atau ID klien lainnya, dan lainnya. Lihat
contoh di atas untuk mengetahui informasi selengkapnya tentang cara menggunakan
elemen <Class>
atau <Identifier>
.
Notasi waktu
Semua waktu Kuota ditetapkan ke zona waktu Coordinated Universal Time (UTC).
Notasi waktu kuota mengikuti notasi tanggal standar internasional yang ditentukan dalam Standar Internasional ISO 8601.
Tanggal ditentukan sebagai tahun, bulan, dan hari, dalam format berikut: YYYY-MM-DD
.
Misalnya, 2015-02-04
mewakili 4 Februari 2015.
Waktu ditentukan sebagai jam, menit, dan detik dalam format berikut:
hours:minutes:seconds
. Misalnya, 23:59:59
mewakili waktu satu
detik sebelum tengah malam.
Perhatikan bahwa dua notasi, 00:00:00
dan 24:00:00
, tersedia untuk
membedakan dua tengah malam yang dapat dikaitkan dengan satu tanggal. Oleh karena itu, 2015-02-04
24:00:00
memiliki tanggal dan waktu yang sama dengan 2015-02-05 00:00:00
. Notasi kedua
biasanya lebih disukai.
Mendapatkan setelan kuota dari konfigurasi produk API
Anda dapat menetapkan batas kuota di konfigurasi produk API. Batas tersebut tidak otomatis menerapkan kuota. Sebagai gantinya, Anda dapat mereferensikan setelan kuota produk dalam kebijakan kuota. Berikut beberapa keuntungan menetapkan kuota pada produk untuk dirujuk oleh kebijakan kuota:
- Kebijakan kuota dapat menggunakan setelan yang seragam di semua proxy API dalam produk API.
- Anda dapat membuat perubahan runtime pada setelan kuota di produk API, dan kebijakan kuota yang mereferensikan nilai akan otomatis memperbarui nilai kuota.
Untuk informasi selengkapnya tentang cara menggunakan setelan kuota dari produk API, lihat contoh "Kuota Dinamis" di atas..
Untuk mengetahui info tentang cara mengonfigurasi produk API dengan batas kuota, lihat Membuat produk API.
Referensi elemen
Berikut adalah elemen dan atribut yang dapat Anda konfigurasi pada kebijakan ini. Perhatikan bahwa beberapa kombinasi elemen bersifat eksklusif atau tidak diperlukan. Lihat contoh untuk penggunaan tertentu. Variabel
verifyapikey.VerifyAPIKey.apiproduct.*
di bawah tersedia secara default saat
kebijakan Verifikasi Kunci API yang disebut "VerifyAPIKey" digunakan untuk memeriksa kunci API aplikasi dalam permintaan.
Nilai variabel berasal dari setelan kuota di produk API yang terkait dengan kunci, seperti yang dijelaskan dalam artikel Mendapatkan setelan kuota dari konfigurasi produk 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>
Atribut <Quota>
<Quota async="false" continueOnError="false" enabled="true" name="Quota-3" type="calendar">
Atribut berikut bersifat khusus untuk kebijakan ini.
Atribut | Deskripsi | Default | Ketersediaan |
---|---|---|---|
jenis |
Gunakan untuk menentukan kapan dan bagaimana penghitung kuota memeriksa penggunaan kuota. Lihat Jenis kebijakan kuota untuk mengetahui informasi selengkapnya. Jika Anda menghilangkan nilai Nilai yang valid mencakup:
|
kalender | Opsional |
Tabel berikut menjelaskan atribut yang umum untuk semua elemen induk kebijakan:
Atribut | Deskripsi | Default | Ketersediaan |
---|---|---|---|
name |
Nama internal kebijakan. Nilai atribut Secara opsional, gunakan elemen |
T/A | Wajib |
continueOnError |
Tetapkan ke Setel ke |
salah | Opsional |
enabled |
Setel ke Setel ke |
true | Opsional |
async |
Atribut ini tidak digunakan lagi. |
salah | Tidak digunakan lagi |
<DisplayName> elemen
Gunakan selain atribut name
untuk memberi label kebijakan di
editor proxy UI dengan nama natural language yang berbeda.
<DisplayName>Policy Display Name</DisplayName>
Default |
T/A Jika Anda menghapus elemen ini, nilai atribut |
---|---|
Ketersediaan | Opsional |
Jenis | String |
Elemen <Allow>
Menentukan batas jumlah untuk kuota. Jika penghitung untuk kebijakan mencapai nilai batas ini, panggilan berikutnya akan ditolak hingga penghitung direset.
Berikut adalah tiga cara untuk menetapkan elemen <Allow>
:
<Allow count="2000"/>
<Allow countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>
<Allow count="2000" countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>
Jika Anda menentukan count
dan countRef
, countRef
akan mendapatkan prioritas. Jika countRef
tidak di-resolve saat runtime, nilai
count
akan digunakan.
Default: | T/A |
Kehadiran: | Opsional |
Jenis: | Bilangan Bulat |
Atribut
Atribut | Deskripsi | Default | Ketersediaan |
---|---|---|---|
jumlah |
Gunakan untuk menentukan jumlah pesan untuk kuota. Misalnya, nilai atribut |
2000 | Opsional |
countRef |
Gunakan untuk menentukan variabel alur yang berisi jumlah pesan untuk kuota.
|
tidak ada | Opsional |
Elemen <Allow>/<Class>
Elemen <Class>
memungkinkan Anda mengondisikan nilai elemen <Allow>
berdasarkan nilai variabel flow. Untuk setiap tag turunan <Allow>
yang berbeda dari <Class>
, kebijakan akan mempertahankan penghitung yang berbeda.
Untuk menggunakan elemen <Class>
, tentukan variabel flow menggunakan
atribut ref
ke tag <Class>
. Edge kemudian menggunakan nilai variabel alur untuk memilih salah satu tag turunan <Allow>
guna menentukan jumlah kebijakan yang diizinkan. Edge mencocokkan nilai variabel alur dengan atribut class
tag <Allow>
, seperti yang ditunjukkan di bawah ini:
<Allow> <Class ref="request.queryparam.time_variable"> <Allow class="peak_time" count="5000"/> <Allow class="off_peak_time" count="1000"/> </Class> </Allow>
Dalam contoh ini, penghitung kuota saat ini ditentukan oleh nilai parameter kueri time_variable
yang diteruskan dengan setiap permintaan. Variabel tersebut dapat memiliki nilai
peak_time
atau off_peak_time
. Jika parameter kueri berisi nilai yang tidak valid, kebijakan akan menampilkan error pelanggaran kuota.
Default: | T/A |
Kehadiran: | Opsional |
Jenis: | T/A |
Atribut
Atribut | Deskripsi | Default | Ketersediaan |
---|---|---|---|
ref |
Gunakan untuk menentukan variabel alur yang berisi class kuota untuk kuota. |
tidak ada | Wajib |
Elemen <Allow>/<Class>/<Allow>
Elemen <Allow>
menentukan batas untuk penghitung kuota
yang ditentukan oleh elemen <Class>
. Untuk setiap tag turunan <Allow>
yang berbeda dari <Class>
, kebijakan akan mempertahankan penghitung yang berbeda.
Contoh:
<Allow> <Class ref="request.queryparam.time_variable"> <Allow class="peak_time" count="5000"/> <Allow class="off_peak_time" count="1000"/> </Class> </Allow>
Dalam contoh ini, kebijakan Kuota mempertahankan dua penghitung kuota bernama
peak_time
dan off_peak_time
.
Default: | T/A |
Kehadiran: | Opsional |
Jenis: | T/A |
Atribut
Atribut | Deskripsi | Default | Ketersediaan |
---|---|---|---|
class |
Menentukan nama penghitung kuota. |
tidak ada | Wajib |
jumlah | Menentukan batas kuota untuk penghitung. | tidak ada | Wajib |
Elemen <Interval>
Gunakan untuk menentukan bilangan bulat (misalnya, 1, 2, 5, 60, dan seterusnya) yang akan disambungkan dengan
TimeUnit
yang Anda tentukan (menit, jam, hari, minggu, atau bulan) untuk menentukan jangka waktu
saat Edge menghitung penggunaan kuota.
Misalnya, Interval
24
dengan
TimeUnit
hour
berarti kuota akan
dihitung selama 24 jam.
<Interval ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.interval">1</Interval>
Default: | tidak ada |
Kehadiran: | Wajib |
Jenis: | Bilangan Bulat |
Atribut
Atribut | Deskripsi | Default | Ketersediaan |
---|---|---|---|
ref |
Gunakan untuk menentukan variabel flow yang berisi interval untuk kuota. |
tidak ada | Opsional |
Elemen <TimeUnit>
Gunakan untuk menentukan satuan waktu yang berlaku untuk kuota.
Misalnya, Interval
24
dengan
TimeUnit
hour
berarti kuota akan
dihitung selama 24 jam.
<TimeUnit ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.timeunit">month</TimeUnit>
Default: | tidak ada |
Kehadiran: | Wajib |
Jenis: |
String. Pilih dari |
Atribut
Atribut | Deskripsi | Default | Ketersediaan |
---|---|---|---|
ref | Gunakan untuk menentukan variabel alur yang berisi unit waktu untuk kuota. ref
lebih diutamakan daripada nilai interval eksplisit. Jika ref tidak
di-resolve saat runtime, nilai tersebut akan digunakan. |
tidak ada | Opsional |
Elemen <StartTime>
Jika type
ditetapkan ke calendar,
, tanggal
dan waktu saat penghitung kuota akan mulai menghitung akan ditentukan, terlepas dari apakah ada permintaan yang
diterima dari aplikasi apa pun.
Contoh:
<StartTime>2017-7-16 12:00:00</StartTime>
Default: | tidak ada |
Kehadiran: | Wajib ada saat type ditetapkan ke calendar . |
Jenis: |
String dalam format tanggal dan waktu ISO 8601. |
Elemen <Distributed>
Penginstalan Edge dapat menggunakan satu atau beberapa Message Processor untuk memproses permintaan. Tetapkan elemen ini ke true
untuk menentukan bahwa kebijakan harus mempertahankan penghitung pusat dan terus menyinkronkannya di semua Message Processor. Pemroses pesan
dapat berada di seluruh zona dan/atau region ketersediaan.
Jika menggunakan nilai default false
, Anda mungkin melebihi kuota karena jumlah untuk setiap Message Processor tidak dibagikan:
<Distributed>true</Distributed>
Untuk memastikan penghitung disinkronkan, dan diperbarui pada setiap permintaan, tetapkan
<Distributed>
dan <Synchronous>
ke benar:
<Distributed>true</Distributed> <Synchronous>true</Synchronous>
Default: | false |
Kehadiran: | Opsional |
Jenis: | Boolean |
Elemen <Synchronous>
Tetapkan ke true
untuk memperbarui penghitung kuota terdistribusi secara sinkron. Hal ini
berarti pembaruan pada penghitung dilakukan bersamaan dengan pemeriksaan kuota pada permintaan
ke API. Tetapkan ke true
jika Anda tidak boleh mengizinkan panggilan API melebihi kuota.
Tetapkan ke false
untuk memperbarui penghitung kuota secara asinkron. Artinya,
beberapa panggilan API yang melebihi kuota mungkin akan berhasil, bergantung pada waktu
penghitung kuota di repositori pusat diperbarui secara asinkron. Namun, Anda tidak akan menghadapi
potensi dampak performa yang terkait dengan update sinkron.
Interval update asinkron default adalah 10 detik. Gunakan elemen
AsynchronousConfiguration
untuk mengonfigurasi perilaku asinkron ini.
<Synchronous>false</Synchronous>
Default: | false |
Kehadiran: | Opsional |
Jenis: | Boolean |
Elemen <AsynchronousConfiguration>
Mengonfigurasi interval sinkronisasi di antara penghitung kuota terdistribusi saat elemen konfigurasi kebijakan <Synchronous>
tidak ada atau ada dan ditetapkan ke false
.
Anda dapat menyinkronkan setelah jangka waktu atau jumlah pesan, menggunakan elemen turunan SyncIntervalInSeconds
atau SyncMessageCount
.
Keduanya bersifat eksklusif. Misalnya,
<AsynchronousConfiguration> <SyncIntervalInSeconds>20</SyncIntervalInSeconds> </AsynchronousConfiguration>
atau
<AsynchronousConfiguration> <SyncMessageCount>5</SyncMessageCount> </AsynchronousConfiguration>
Default: | SyncIntervalInSeconds = 10 detik |
Kehadiran: | Opsional; diabaikan jika <Synchronous> ditetapkan ke
true . |
Jenis: |
Kompleks |
Elemen <AsynchronousConfiguration>/<SyncIntervalInSeconds>
Gunakan ini untuk mengganti perilaku default saat update asinkron dilakukan setelah interval 10 detik.
<AsynchronousConfiguration> <SyncIntervalInSeconds>20</SyncIntervalInSeconds> </AsynchronousConfiguration>
Interval sinkronisasi harus >= 10 detik seperti yang dijelaskan dalam topik Batas.
Default: | 10 |
Kehadiran: | Opsional |
Jenis: |
Bilangan Bulat |
<AsynchronousConfiguration>/<SyncMessageCount> element
Menentukan jumlah permintaan di semua pemroses pesan Apigee di antara update kuota.
<AsynchronousConfiguration> <SyncMessageCount>5</SyncMessageCount> </AsynchronousConfiguration>
Contoh ini menentukan bahwa jumlah kuota diperbarui setiap 5 permintaan di setiap pemroses pesan Apigee Edge.
Default: | t/a |
Kehadiran: | Opsional |
Jenis: |
Bilangan Bulat |
Elemen <Identifier>
Gunakan elemen <Identifier>
untuk mengonfigurasi kebijakan guna membuat penghitung unik berdasarkan variabel alur.
Jika Anda tidak menggunakan elemen ini, kebijakan akan menggunakan satu penghitung yang diterapkan terhadap kuota.
Elemen ini juga dibahas dalam postingan Komunitas Apigee berikut: 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"/>
Default: | T/A |
Kehadiran: | Opsional |
Jenis: |
String |
Atribut
Atribut | Deskripsi | Default | Ketersediaan |
---|---|---|---|
ref |
Menentukan variabel alur yang mengidentifikasi penghitung yang akan digunakan untuk permintaan. ID dapat berupa header HTTP, parameter kueri, parameter formulir, atau konten pesan yang unik untuk setiap aplikasi, pengguna aplikasi, developer aplikasi, produk API, atau karakteristik lainnya.
Dalam beberapa situasi, setelan Kuota harus diambil jika tidak ada
|
T/A | Opsional |
Elemen <MessageWeight>
Gunakan untuk menentukan bobot yang ditetapkan ke setiap pesan. Gunakan bobot pesan untuk meningkatkan dampak pesan permintaan yang, misalnya, menggunakan lebih banyak resource komputasi daripada yang lain.
Misalnya, Anda ingin menghitung pesan POST sebagai dua kali lebih "berat" atau mahal, seperti pesan
GET. Oleh karena itu, Anda menetapkan MessageWeight
ke 2 untuk POST dan 1 untuk
GET. Anda bahkan dapat menetapkan MessageWeight
ke 0 sehingga permintaan tidak
memengaruhi penghitung. Dalam contoh ini, jika kuotanya adalah 10 pesan per menit dan
MessageWeight
untuk permintaan POST adalah 2
, kuota akan
mengizinkan 5 permintaan POST dalam interval 10 menit. Setiap permintaan tambahan, POST atau GET,
sebelum reset penghitung ditolak.
Nilai yang mewakili MessageWeight
harus ditentukan oleh variabel
alur, dan dapat diekstrak dari header HTTP, parameter kueri, payload permintaan XML atau JSON, atau variabel alur lainnya. Misalnya, Anda menetapkannya di header bernama
weight
:
<MessageWeight ref="message_weight"/>
Default: | T/A |
Kehadiran: | Opsional |
Jenis: |
Bilangan Bulat |
Variabel alur
Variabel Flow bawaan berikut diisi secara otomatis saat kebijakan Kuota dijalankan. Untuk informasi selengkapnya tentang variabel Flow, lihat Referensi variabel.
Variabel | Jenis | Izin | Deskripsi |
---|---|---|---|
ratelimit.{policy_name}.allowed.count | Panjang | Hanya Baca | Menampilkan jumlah kuota yang diizinkan |
ratelimit.{policy_name}.used.count | Panjang | Hanya Baca | Menampilkan kuota saat ini yang digunakan dalam interval kuota |
ratelimit.{policy_name}.available.count | Panjang | Hanya Baca | Menampilkan jumlah kuota yang tersedia dalam interval kuota |
ratelimit.{policy_name}.exceed.count | Panjang | Hanya Baca | Menampilkan 1 setelah kuota terlampaui. |
ratelimit.{policy_name}.total.exceed.count | Panjang | Hanya Baca | Menampilkan 1 setelah kuota terlampaui. |
ratelimit.{policy_name}.expiry.time | Panjang | Hanya Baca |
Menampilkan waktu UTC dalam milidetik yang menentukan kapan kuota berakhir dan interval kuota baru dimulai. Jika jenis kebijakan Kuota adalah |
ratelimit.{policy_name}.identifier | String | Hanya Baca | Menampilkan referensi ID (klien) yang dilampirkan ke kebijakan |
ratelimit.{policy_name}.class | String | Hanya Baca | Menampilkan class yang terkait dengan client ID |
ratelimit.{policy_name}.class.allowed.count | Panjang | Hanya Baca | Menampilkan jumlah kuota yang diizinkan yang ditentukan dalam class |
ratelimit.{policy_name}.class.used.count | Panjang | Hanya Baca | Menampilkan kuota yang digunakan dalam class |
ratelimit.{policy_name}.class.available.count | Panjang | Hanya Baca | Menampilkan jumlah kuota yang tersedia di class |
ratelimit.{policy_name}.class.exceed.count | Panjang | Hanya Baca | Menampilkan jumlah permintaan yang melebihi batas di class dalam interval kuota saat ini |
ratelimit.{policy_name}.class.total.exceed.count | Panjang | Hanya Baca | Menampilkan jumlah total permintaan yang melebihi batas di class di semua
interval kuota, sehingga merupakan jumlah class.exceed.count untuk semua
interval kuota. |
ratelimit.{policy_name}.failed | Boolean | Hanya Baca |
Menunjukkan apakah kebijakan gagal atau tidak (benar atau salah). |
Referensi error
Bagian ini menjelaskan kode kesalahan dan pesan kesalahan yang dikembalikan dan variabel kesalahan yang disetel oleh Edge saat kebijakan ini memicu kesalahan. Informasi ini penting untuk diketahui jika Anda mengembangkan aturan kesalahan untuk menangani kesalahan. Untuk mempelajari lebih lanjut, lihat Yang perlu Anda ketahui tentang error kebijakan dan Penanganan kesalahan.
Error runtime
Error ini dapat terjadi saat kebijakan dijalankan.
Kode error | Status HTTP | Penyebab | Perbaiki |
---|---|---|---|
policies.ratelimit.FailedToResolveQuotaIntervalReference |
500 | Terjadi jika elemen <Interval> tidak ditentukan dalam kebijakan Quota. Elemen ini
bersifat wajib dan digunakan untuk menentukan interval waktu yang berlaku untuk kuota. Interval waktu
bisa berupa menit, jam, hari, minggu, atau bulan seperti yang ditentukan dengan elemen <TimeUnit> . |
build |
policies.ratelimit.FailedToResolveQuotaIntervalTimeUnitReference |
500 | Terjadi jika elemen <TimeUnit> tidak ditentukan dalam kebijakan Quota. Elemen ini
bersifat wajib dan digunakan untuk menentukan satuan waktu yang berlaku untuk kuota. Interval waktu
bisa dalam hitungan menit, jam, hari, minggu, atau bulan. |
build |
policies.ratelimit.InvalidMessageWeight |
500 | Terjadi jika nilai elemen <MessageWeight> ditentukan melalui variabel flow
tidak valid (nilai bukan bilangan bulat). |
build |
policies.ratelimit.QuotaViolation |
500 | Batas kuota terlampaui. | T/A |
Error saat deployment
Nama error | Penyebab | Perbaiki |
---|---|---|
InvalidQuotaInterval |
Jika interval kuota yang ditentukan dalam elemen <Interval> tidak
bilangan bulat, maka deployment proxy API akan gagal. Misalnya, jika interval kuota
yang ditentukan adalah 0.1 dalam elemen <Interval> , maka deployment
Proxy API gagal.
|
build |
InvalidQuotaTimeUnit |
Jika satuan waktu yang ditentukan dalam elemen <TimeUnit> tidak didukung,
maka deployment proxy API akan gagal. Satuan waktu yang didukung adalah minute ,
hour , day , week , dan month .
|
build |
InvalidQuotaType |
Jika jenis kuota yang ditentukan oleh atribut type di <Quota>
tidak valid, maka deployment proxy API akan gagal. Tujuan
jenis kuota yang didukung adalah default , calendar , flexi , dan rollingwindow .
|
build |
InvalidStartTime |
Jika format waktu yang ditentukan dalam elemen <StartTime> adalah
tidak valid, berarti deployment proxy API akan gagal. Format yang valid adalah yyyy-MM-dd HH:mm:ss ,
yang merupakan format tanggal dan waktu ISO 8601. Sebagai
contoh, jika waktu yang ditentukan dalam elemen <StartTime>
7-16-2017 12:00:00 , deployment proxy API akan gagal.
|
build |
StartTimeNotSupported |
Jika elemen <StartTime> ditentukan yang jenis kuotanya tidak
calendar , deployment proxy API akan gagal. Elemen <StartTime> merupakan
hanya didukung untuk jenis kuota calendar . Misalnya, jika atribut type ditetapkan
ke flexi atau rolling window dalam elemen <Quota> , lalu
deployment proxy API gagal.
|
build |
InvalidTimeUnitForDistributedQuota |
Jika elemen <Distributed> disetel ke true dan elemen <TimeUnit> disetel ke
second maka deployment proxy API akan gagal. Satuan waktu second tidak valid untuk
kuota terdistribusi. |
build |
InvalidSynchronizeIntervalForAsyncConfiguration |
Jika nilai yang ditentukan untuk elemen <SyncIntervalInSeconds> dalam
Elemen <AsynchronousConfiguration> dalam kebijakan Kuota kurang dari nol, maka
deployment proxy API gagal. |
build |
InvalidAsynchronizeConfigurationForSynchronousQuota |
Jika nilai elemen <AsynchronousConfiguration> disetel ke true dalam kebijakan Kuota, yang juga
memiliki konfigurasi asinkron yang ditentukan menggunakan elemen <AsynchronousConfiguration> , maka
deployment proxy API gagal. |
build |
Variabel kesalahan
Variabel ini ditetapkan saat kebijakan ini memicu error. Untuk informasi selengkapnya, lihat Yang perlu Anda ketahui tentang error kebijakan.
Variabel | Di mana | Contoh |
---|---|---|
fault.name="fault_name" |
fault_name adalah nama kesalahan, seperti yang tercantum dalam tabel Error runtime di atas. Nama kesalahan adalah bagian terakhir dari kode kesalahan. | fault.name Matches "QuotaViolation" |
ratelimit.policy_name.failed |
policy_name adalah nama kebijakan yang ditentukan pengguna yang menampilkan kesalahan. | ratelimit.QT-QuotaPolicy.failed = true |
Contoh respons error
{ "fault":{ "detail":{ "errorcode":"policies.ratelimit.QuotaViolation" }, "faultstring":"Rate limit quota violation. Quota limit exceeded. Identifier : _default" } }
Contoh aturan kesalahan
<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>
Skema
Topik terkait
Membandingkan Kebijakan Kuota, Penghentian Lonjakan, dan Batas Laju Serentak