Halaman ini menjelaskan cara menggunakan Infrastruktur Layanan untuk menerapkan pembatasan kapasitas bagi layanan terkelola yang terintegrasi dengan Service Management API.
Layanan terkelola dapat melayani banyak konsumen layanan. Untuk melindungi kapasitas sistem dan memastikan penggunaan yang wajar, layanan terkelola sering kali menggunakan pembatasan kecepatan untuk mendistribusikan kapasitasnya di antara konsumen layanannya. API Service Management dan Service Control memungkinkan Anda mengelola dan menerapkan pembatasan kecepatan.
Mengonfigurasi batas kecepatan
Untuk menggunakan fitur pembatasan kecepatan, konfigurasikan _quota metrics_ dan
_quota limits_ dalam konfigurasi layanan untuk project
produsen layanan Anda.
Saat ini, pembatasan jumlah yang didukung adalah jumlah permintaan per menit per konsumen layanan, dengan konsumen layanan adalah project Google Cloud seperti yang diidentifikasi oleh kunci API, ID project, atau nomor project. Untuk pembatasan kecepatan, konsep permintaan adalah konsep yang tidak transparan. Layanan dapat memilih permintaan HTTP sebagai permintaan, atau byte muatan sebagai permintaan. Fitur pembatasan kapasitas tidak bergantung pada semantik permintaan.
Metrik kuota
Metrik adalah penghitung bernama untuk mengukur nilai tertentu dari waktu ke waktu. Misalnya, jumlah permintaan HTTP yang diterima layanan adalah metrik. Metrik kuota adalah metrik yang digunakan untuk tujuan kuota dan pembatasan kecepatan. Saat
aktivitas terjadi dengan layanan, satu atau beberapa metrik kuota dapat meningkat. Saat nilai metrik mencapai batas kuota yang telah ditentukan sebelumnya, layanan harus menolak aktivitas dengan error 429.
Batas kuota
Batas kuota mewakili batas yang dapat diterapkan pada metrik kuota. Misalnya,
jumlah permintaan per konsumen layanan per menit adalah batas kuota. Saat ini, satu-satunya jenis batas kuota yang didukung adalah per menit per konsumen, khususnya 1/min/{project}.
Batas frekuensi sebenarnya untuk pasangan (layanan, konsumen) dikontrol oleh 3 setelan:
- Batas default yang ditentukan untuk layanan terkelola.
- Penggantian produsen layanan untuk konsumen layanan.
- Penggantian konsumen layanan untuk konsumen layanan.
Batas frekuensi efektif adalah:
- Batas default jika tidak ada penggantian.
- Penggantian produsen layanan jika ada penggantian produsen layanan, tetapi tidak ada penggantian konsumen layanan.
- Minimum(penggantian konsumen layanan, batas default) jika ada penggantian konsumen layanan, tetapi tidak ada penggantian produsen layanan.
- Nilai minimum(penggantian konsumen layanan, penggantian produsen layanan) jika ada penggantian produsen layanan dan konsumen layanan.
Menerapkan pembatasan kapasitas
Untuk menerapkan pembatasan frekuensi, setiap server yang termasuk dalam layanan terkelola perlu memanggil metode services.allocateQuota Service Control API secara rutin. Jika respons metode
services.allocateQuota
menunjukkan bahwa penggunaan melebihi batas, server harus menolak
permintaan masuk dengan error 429. Untuk mengetahui informasi selengkapnya, lihat dokumentasi referensi untuk metode services.allocateQuota.
Setiap server sebaiknya menggunakan batching, caching, dan logika prediktif untuk meningkatkan performa dan keandalan sistem. Secara umum, satu server
hanya boleh memanggil
metode services.allocateQuota
sekali per detik untuk tuple (layanan, konsumen, metrik) yang sama.
Contoh berikut menunjukkan cara memanggil metode
services.allocateQuota
untuk memeriksa pembatasan kecepatan. Parameter permintaan penting yang harus
disetel dengan benar adalah nama layanan, ID konsumen, nama metrik, dan
nilai metrik. Metode
services.allocateQuota
akan mencoba meningkatkan penggunaan sebesar jumlah yang ditentukan untuk tuple (layanan, konsumen, metrik). Jika peningkatan penggunaan melebihi batas, error akan ditampilkan. Contoh berikut menggunakan perintah gcurl untuk mendemonstrasikan
panggilan. Untuk mempelajari cara menyiapkannya, lihat
Mulai Menggunakan Service Control API.
gcurl -d '{
"allocateOperation": {
"operationId": "123e4567-e89b-12d3-a456-426655440000",
"methodName": "google.example.hello.v1.HelloService.GetHello",
"consumerId": "project:endpointsapis-consumer",
"quotaMetrics": [{
"metricName": "endpointsapis.appspot.com/requests",
"metricValues": [{
"int64Value": 1
}]
}],
"quotaMode": "NORMAL"
}
}' https://servicecontrol.googleapis.com/v1/services/endpointsapis.appspot.com:allocateQuota
{
"operationId": "123e4567-e89b-12d3-a456-426655440000",
"quotaMetrics": [
{
"metricName": "serviceruntime.googleapis.com/api/consumer/quota_used_count",
"metricValues": [
{
"labels": {
"/quota_name": "endpointsapis.appspot.com/requests"
},
"int64Value": "1"
}
]
}
],
"serviceConfigId": "2017-09-10r0"
}
Penanganan error
Jika kode respons HTTP adalah 200, dan respons berisi
RESOURCE_EXHAUSTED
QuotaError,
server Anda harus menolak permintaan dengan error 429. Jika respons tidak berisi error kuota, server Anda harus terus melayani permintaan yang masuk. Untuk semua error kuota lainnya, server Anda harus menolak permintaan dengan error 409. Karena risiko keamanan, Anda harus sangat berhati-hati dengan informasi error yang Anda sertakan dalam pesan error.
Untuk semua kode respons HTTP lainnya, kemungkinan server Anda memiliki beberapa bug pemrograman. Sebaiknya server Anda terus melayani permintaan yang masuk saat Anda men-debug masalah. Jika metode
services.allocateQuota
menampilkan error yang tidak terduga, layanan Anda harus mencatat error tersebut dan
menerima permintaan pendapatan. Anda dapat men-debug error tersebut nanti.
Fail Open
Fitur pembatasan laju digunakan untuk melindungi layanan terkelola Anda dari kelebihan beban dan mendistribusikan kapasitas layanan Anda secara adil di antara konsumen layanan. Karena sebagian besar konsumen layanan tidak boleh mencapai batas kecepatan selama operasi normal, layanan terkelola Anda harus menerima semua permintaan masuk jika fitur pembatasan kecepatan tidak tersedia, yang juga dikenal sebagai buka jika gagal. Tindakan ini mencegah ketersediaan layanan Anda terpengaruh oleh sistem pembatasan laju.
Jika Anda menggunakan metode
services.allocateQuota, layanan Anda harus mengabaikan error 500, 503, dan 504 tanpa
mencoba lagi. Untuk mencegah dependensi yang kuat pada fitur pembatasan kapasitas, Service Control API mengeluarkan sejumlah kecil injeksi error secara rutin.