Auf dieser Seite wird beschrieben, wie Sie mithilfe von Service Infrastructure die Ratenbegrenzung für verwaltete Dienste implementieren, die in die Service Management API integriert sind.
Ein verwalteter Dienst kann viele Dienstnutzer versorgen. Zum Schutz der Systemkapazität und zur Gewährleistung einer fairen Nutzung bedient sich ein verwalteter Dienst häufig der Ratenbegrenzung, um seine Kapazität auf die Dienstnutzer zu verteilen. Die Ratenbegrenzung kann mit der Service Management API und der Service Control API verwaltet und erzwungen werden.
Ratenlimits konfigurieren
Um die Ratenbegrenzungsfunktion zu verwenden, konfigurieren Sie _quota metrics_ und _quota limits_ in der Dienstkonfiguration für Ihr Diensterstellerprojekt.
Derzeit ist die unterstützte Ratenbegrenzung die Anzahl der Anfragen pro Minute pro Dienstnutzer, wobei der Dienstnutzer ein Google Cloud-Projekt ist, das durch einen API-Schlüssel, eine Projekt-ID oder eine Projektnummer bestimmt wird. Der Begriff "Anfrage" ist in Bezug auf die Ratenbegrenzung nicht klar definiert. Ein Dienst kann eine HTTP-Anfrage oder ein Nutzlastbyte als Anfrage verwenden. Die Ratenbegrenzungsfunktion ist von der Semantik einer Anfrage unabhängig.
Kontingentmesswerte
Ein Messwert ist ein benannter Zähler zum Messen eines bestimmten Werts über einen Zeitraum. Beispielsweise ist die Anzahl der HTTP-Anfragen, die ein Dienst empfängt, ein Messwert. Ein Kontingentmesswert ist ein Messwert zur Kontingent- und Ratenbegrenzung. Eine Aktivität in Zusammenhang mit einem Dienst kann einen oder mehrere Kontingentmesswerte erhöhen. Wenn der Messwert die vordefinierte Kontingentgrenze erreicht, sollte der Dienst die Aktivität mit dem Fehler 429 ablehnen.
Kontingentlimits
Ein Kontingentlimit ist ein durchsetzbares Limit für einen Kontingentmesswert. Zum Beispiel ist die Anzahl der Anfragen pro Dienstnutzer und Minute ein Kontingentlimit. Derzeit wird nur der Kontingentlimittyp "pro Minute und Nutzer" unterstützt, nämlich 1/min/{project}.
Das tatsächliche Ratenlimit für ein Paar (Dienst, Nutzer) wird durch drei Einstellungen gesteuert:
- Das für den verwalteten Dienst angegebene Standardlimit
- Die Überschreibung durch den Dienstersteller für den Dienstnutzer
- Die Überschreibung durch den Dienstnutzer für den Dienstnutzer
Das effektive Ratenlimit wird folgendermaßen definiert:
- Das Standardlimit, wenn keine Überschreibung vorhanden ist
- Die Überschreibung durch den Dienstersteller, wenn eine Überschreibung durch den Dienstersteller vorhanden ist, jedoch keine Überschreibung durch den Dienstnutzer
- Das Minimum (Überschreibung durch den Dienstnutzer, Standardlimit), wenn eine Überschreibung durch den Dienstnutzer vorhanden ist, jedoch keine Überschreibung durch den Dienstersteller
- Das Minimum (Überschreibung durch den Dienstnutzer, Überschreibung durch den Dienstersteller), wenn Überschreibungen sowohl durch den Dienstersteller als auch durch den Dienstnutzer vorhanden sind
Ratenbegrenzung durchsetzen
Zur Durchsetzung der Ratenbegrenzung muss jeder Server, der zu einem verwalteten Dienst gehört, regelmäßig die Methode services.allocateQuota der Service Control API aufrufen. Wenn die Antwort der Methode services.allocateQuota angibt, dass die Nutzung das Limit überschreitet, sollte der Server die eingehende Anfrage mit dem Fehler 429 ablehnen. Weitere Informationen finden Sie in der Referenzdokumentation zur Methode services.allocateQuota.
Es wird empfohlen, dass jeder Server Stapelung, Caching und Prognoselogik verwendet, um die Leistung und Zuverlässigkeit des Systems zu verbessern. Im Allgemeinen gilt, dass ein einzelner Server die Methode services.allocateQuota nur einmal pro Sekunde für dasselbe Tupel (Dienst, Nutzer, Messwert) aufrufen sollte.
Das folgende Beispiel zeigt, wie die Methode services.allocateQuota zur Überprüfung der Ratenbegrenzung aufgerufen wird. Die wichtigen Anfrageparameter, die korrekt festgelegt werden müssen, sind der Dienstname, die Nutzer-ID, der Messwert und der Name des Messwerts. Die Methode services.allocateQuota versucht, die Nutzung für das Tupel (Dienst, Nutzer, Messwert) um den angegebenen Betrag zu erhöhen. Wenn die erhöhte Nutzung das Limit überschreitet, wird ein Fehler zurückgegeben. Im folgenden Beispiel wird der Aufruf anhand des Befehls gcurl demonstriert. Informationen zum Einrichten dieses Vorgangs finden Sie unter Erste Schritte mit der 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"
}
Fehlerbehandlung
Wenn der HTTP-Antwortcode 200 lautet und die Antwort RESOURCE_EXHAUSTED
QuotaError enthält, sollte Ihr Server die Anfrage mit einem 429-Fehler ablehnen. Enthält die Antwort keinen Kontingentfehler, sollte der Server eingehende Anfragen weiterhin verarbeiten. Bei allen anderen Kontingentfehlern sollte der Server die Anfrage mit dem Fehler 409 ablehnen. Aufgrund der Sicherheitsrisiken müssen Sie die Informationen, die Sie in die Fehlermeldung aufnehmen, sehr sorgfältig auswählen.
Bei allen anderen HTTP-Antwortcodes ist die Wahrscheinlichkeit groß, dass sie auf Programmierfehler im Server zurückgehen. In einem solchen Fall empfiehlt es sich, den Server die eingehenden Anfragen weiter verarbeiten zu lassen, während gleichzeitig das Problem behoben wird. Falls die Methode services.allocateQuota einen unerwarteten Fehler zurückgibt, sollte Ihr Dienst den Fehler loggen und die eingehenden Anfragen annehmen. Sie können den Fehler zu einem späteren Zeitpunkt beheben.
Fail-open
Die Ratenbegrenzungsfunktion schützt den verwalteten Dienst vor Überlastung und verteilt die Dienstkapazität gleichmäßig auf die Dienstnutzer. Da die meisten Dienstnutzer ihre Ratenlimits während des normalen Betriebs nicht erreichen dürften, sollte Ihr Dienst alle eingehenden Anfragen auch dann annehmen, wenn die Ratenbegrenzungsfunktion nicht verfügbar ist. Dieser Zustand wird auch als fail-open bezeichnet. Damit wird verhindert, dass die Verfügbarkeit Ihres Dienstes durch das Ratenbegrenzungssystem beeinträchtigt wird.
Wenn Sie die Methode services.allocateQuota verwenden, muss Ihr Dienst die Fehler 500, 503 und 504 ohne Wiederholung ignorieren. Damit es zu keiner starken Abhängigkeit von der Ratenbegrenzungsfunktion kommt, gibt die Service Control API regelmäßig eine begrenzte Menge an Fehlerinjektionen aus.