Questa pagina descrive come utilizzare Service Infrastructure per implementare la limitazione della frequenza per i servizi gestiti integrati con l'API Service Management.
Un servizio gestito può gestire numerosi consumer di servizi. Per proteggere la capacità del sistema e garantire un utilizzo corretto, spesso un servizio gestito utilizza la limitazione della frequenza per distribuire la capacità disponibile tra i relativi consumer di servizi. Le API Service Management e Service Control ti consentono di gestire e applicare limitazione di frequenza.
Configurazione dei limiti di frequenza
Per utilizzare la funzionalità di limitazione di frequenza, configura _quota metrics_ e _quota limits_ nella configurazione del servizio per il progetto del producer di servizi.
Attualmente, la limitazione di frequenza supportata è il numero di richieste al minuto per consumer di servizi, dove il consumer di servizi è un progetto Google Cloud identificato da una chiave API, un ID progetto o un numero di progetto. Per limitazione di frequenza, il concetto di richiesta è opaco. Un servizio può scegliere una richiesta HTTP come richiesta o un byte di payload come richiesta. La funzionalità di limitazione di frequenza è indipendente dalla semantica di una richiesta.
Metriche della quota
Una metrica è un contatore specifico che misura un determinato valore nel tempo. Ad esempio, il numero di richieste HTTP ricevute da un servizio è una metrica. Una metrica della quota è una metrica che viene utilizzata ai fini della limitazione della frequenza e della quota. Quando si verifica un'attività in un servizio, una o più metriche della quota possono aumentare. Quando il valore della metrica raggiunge il limite di quota predefinito, il servizio deve rifiutare l'attività restituendo un errore 429.
Limiti di quota
Un limite di quota rappresenta un limite applicabile a una metrica della quota. Ad esempio, il numero di richieste per consumer di servizi al minuto è un limite di quota. Al momento, l'unico tipo di limite di quota supportato è al minuto per consumer, nello specifico 1/min/{project}.
Il limite di frequenza effettivo per una coppia (servizio, consumer) è controllato da tre impostazioni:
- Il limite predefinito specificato per il servizio gestito.
- L'override del producer di servizi per il consumer di servizi.
- L'override del consumer di servizi per il consumer di servizi.
Il limite di frequenza effettivo è:
- Il limite predefinito se non vi è alcun override.
- L'override del producer di servizi in caso di override del producer di servizi, ma non del consumer di servizi.
- Il valore minimo(override del consumer di servizi, limite predefinito) in caso di override del consumer di servizi, ma non del producer di servizi.
- Il valore minimo(override del consumer di servizi, override del producer di servizi) in caso di override del producer di servizi e del consumer di servizi.
Applicazione della limitazione di frequenza
Per applicare limitazione di frequenza, ogni server che appartiene a un servizio gestito deve chiamare regolarmente il metodo dell'API Service Control services.allocateQuota. Se la risposta del metodo services.allocateQuota indica che l'utilizzo supera il limite, il server deve rifiutare la richiesta in arrivo con un errore 429. Per ulteriori informazioni, consulta la documentazione di riferimento per il metodo services.allocateQuota.
È consigliabile che ogni server utilizzi la logica di creazione batch, memorizzazione nella cache e predittiva per migliorare l'affidabilità e le prestazioni del sistema. In generale, un server deve chiamare il metodo services.allocateQuota solo una volta al secondo per la stessa tupla (servizio, consumer, metrica).
L'esempio seguente mostra come chiamare il metodo services.allocateQuota per verificare la limitazione della frequenza. I parametri della richiesta importanti che devono essere impostati correttamente sono il nome del servizio, l'ID del consumer, il nome della metrica e il valore della metrica. Il metodo services.allocateQuota cercherà di aumentare l'utilizzo in base alla quantità specificata per la tupla (servizio, consumer, metrica). Se l'utilizzo aumentato supera il limite, verrà restituito un errore. L'esempio seguente utilizza il comando gcurl per dimostrare la chiamata. Per informazioni su come eseguire la configurazione, consulta la guida introduttiva all'API Service Control.
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"
}
Gestione degli errori
Se il codice di risposta HTTP è 200 e la risposta contiene
RESOURCE_EXHAUSTED
QuotaError,
il server deve rifiutare la richiesta con un errore 429. Se la risposta non contiene alcun errore relativo alla quota, il server deve continuare a gestire le richieste in entrata. Per tutti gli altri errori di quota, il server deve rifiutare la richiesta con un errore 409. A causa dei rischi per la sicurezza, devi prestare particolare attenzione alle informazioni sull'errore che includi nel messaggio di errore.
Per tutti gli altri codici di risposta HTTP, è probabile che il server presenti alcuni bug di programmazione. È consigliabile che il server continui a gestire le richieste in entrata mentre tu esegui il debug del problema. Se il metodo services.allocateQuota restituisce un errore imprevisto, il servizio deve registrare l'errore e accettare le richieste di reddito. Potrai eseguire il debug dell'errore in un secondo momento.
Fail open
La funzionalità di limitazione della frequenza consente di proteggere il tuo servizio gestito dal sovraccarico e di distribuire la capacità del servizio in modo uniforme tra i consumer di servizi. Poiché la maggior parte dei consumer di servizi non dovrebbe raggiungere i limiti di frequenza durante il normale funzionamento, se la funzionalità di limitazione della frequenza non è disponibile, il servizio gestito deve accettare tutte le richieste in entrata, comportamento noto come fail open. In questo modo, il sistema di limitazione della frequenza non avrà effetti sulla disponibilità del servizio.
Se utilizzi il metodo services.allocateQuota, il servizio deve ignorare gli errori 500, 503 e 504 senza riprovare. Per evitare una dipendenza rigida dalla funzionalità di limitazione della frequenza, l'API Service Control esegue regolarmente un numero limitato di test di fault injection.