WSO2 APIM ist eine führende Plattform zum Erstellen, Integrieren und Bereitstellen digitaler Dienste als verwaltete APIs. In der digitalen Landschaft fungieren APIs als Brücke zwischen Anwendungen und ermöglichen einen nahtlosen Datenaustausch und ebnen den Weg für die digitale Transformation. WSO2 API Manager übernimmt in diesem Ökosystem eine zentrale Rolle und bietet eine umfassende Reihe von Funktionen und Möglichkeiten für die Verwaltung des gesamten Lebenszyklus von APIs.
Eine der wichtigsten Funktionen von WSO2 APIM ist die Ratenbegrenzung (Rate Limiting). Die Rate Limiting von APIs ist ein kritischer Aspekt des API-Managements, bei dem die Anzahl der Anfragen, die an eine API innerhalb eines bestimmten Zeitraums gestellt werden können, begrenzt wird. Der Hauptzweck der Ratenbegrenzung besteht darin, Missbrauch zu verhindern, Serverressourcen zu schützen, eine faire Nutzung und Monetarisierung zu gewährleisten und die allgemeine Dienstqualität für API-Konsumenten aufrechtzuerhalten.
WSO2 unterstützt verschiedene Arten und Ebenen der Ratenbegrenzung. Mit benutzerdefinierter Ratenbegrenzung (Custom Rate Limiting) können Systemadministratoren dynamische, benutzerdefinierte Richtlinien definieren, um die Regeln für die API-Ratenbegrenzung an bestimmte Anwendungsfälle und Anforderungen anzupassen. Es ist wichtig zu beachten, dass benutzerdefinierte Ratenbegrenzungsrichtlinien global auf alle Mandanten angewendet werden. Benutzerdefinierte Ratenbegrenzungsrichtlinien werden durch die Siddhi-Abfragesprache definiert. Daher können Richtlinien mithilfe von Siddhi-Abfragen geschrieben werden.
Eine benutzerdefinierte Richtlinie besteht aus zwei Hauptteilen: der Schlüsselvorlage und der Siddhi-Abfrage. Es gibt eine Reihe zulässiger Schlüssel, die als Schlüsselvorlagen verwendet werden können. Mehrere Schlüssel können durch einen Doppelpunkt (:) getrennt werden, wobei jeder Schlüssel mit dem Präfix $ beginnen muss. Die zulässigen Schlüssel in der Schlüsselvorlage sind unten aufgeführt.
- $resourceKey
- $userId
- $apiContext
- $apiVersion
- $appTenant
- $apiTenant
- $appId
- $clientIp
In der Siddhi-Abfrage schreiben wir die eigentliche Richtlinie. In der Abfrage müssen wir einen Throttling-Schlüssel setzen. Wenn zwischen dem Throttling-Schlüssel und der Schlüsselvorlage eine Nichtübereinstimmung vorliegt, wird die Anfrage nicht gedrosselt. Daher muss der Throttling-Schlüssel in der Siddhi-Abfrage mit der Schlüsselvorlage übereinstimmen.
Erstellen und Testen einer benutzerdefinierten Throttling-Richtlinie
Dafür verwende ich die neueste Version von WSO2 APIM 4.2 auf meiner lokalen Umgebung. Wenn Sie nicht wissen, wie das geht, lesen Sie einen unserer Blogs unter Die Installation von WSO2-Produkten auf Linux, Windows und Mac, der erklärt, wie Sie WSO2-Produkte unter Linux/Windows/Mac ausführen können.
Sobald der WSO2-Server aktiv ist, können wir auf die Portale über die folgenden URLs zugreifen:
- Publisher portal – https://localhost:9443/pubisher
- Developer portal – https://localhost:9443/devportal
- Admin portal – https://localhost:9443/admin
Bevor Sie eine benutzerdefinierte Throttling-Richtlinie erstellen können, müssen Sie zuerst eine API erstellen und abonnieren. Dies stellt sicher, dass die API gemäß der benutzerdefinierten Throttling-Richtlinie auf Throttling getestet werden kann.
API erstellen
Im Publisher-Portal erstellen wir eine neue API mit den erforderlichen Ressourcen. Anschließend wird diese API bereitgestellt und veröffentlicht. Danach kann eine benutzerdefinierte Throttling-Richtlinie erstellt werden, um die API zu drosseln.
- Gehen Sie zum Publisher portal – https://localhost:9443/pubisher
- Erstellen Sie eine API mit den folgenden Details:
- Gehen Sie zu Ressourcen und löschen Sie die generierten Ressourcen. Fügen Sie dann zwei GET-Ressourcen für Beiträge (Posts) und Aufgaben (Todos) hinzu, wie unten beschrieben:
- Gehen Sie zu Bereitstellungen und stellen Sie die erstellte API bereit
- Gehen Sie zu Lifecycle und veröffentlichen Sie die bereitgestellte API
Abonnieren auf die API
Um ein Token zu generieren und die API-Ressourcen aufzurufen, müssen wir zuerst eine Anwendung im Developer-Portal erstellen und diese für die erstellte API abonnieren.
- Gehen Sie zum Developer portal – https://localhost:9443/devportal
- Erstellen Sie eine Anwendung
- Abonnieren Sie die API
- Generieren Sie ein Token
API aufrufen
Sie können jeden REST-Client oder CURL verwenden, um auf die API zuzugreifen. In diesem Fall verwenden wir Postman, um die API-Ressourcen mit dem generierten Token aufzurufen und zu überprüfen, ob die API-Ressourcen wie erwartet funktionieren.
- Rufen Sie die /posts-API mithilfe des Tokens auf, das Sie im vorherigen Schritt generiert haben.
- Rufen Sie die /todos-API mithilfe des Tokens auf, das Sie im vorherigen Schritt generiert haben.
Beide APIs funktionieren wie erwartet.
Custom Throttling-Richtlinie erstellen
Erstellen wir nun eine benutzerdefinierte Throttling-Richtlinie, um den Posts-Endpunkt zu drosseln, wenn innerhalb einer Minute mehr als 5 Anfragen gestellt werden.
- Gehen Sie zum portal – https://localhost:9443/admin
- Wählen Sie Benutzerdefinierte Richtlinien aus und klicken Sie auf Definieren
- Erstellen Sie eine Richtlinie mit den folgenden Details:
Key Template: $resourceKey
Siddhi Query:
FROM
RequestStream
SELECT
userId,
(resourceKey == '/test/v1/v1/posts:GET') AS isEligible,
resourceKey as throttleKey
INSERT INTO
EligibilityStream;
FROM
EligibilityStream [ isEligible == true ] # throttler: timeBatch(1 min)
SELECT
throttleKey,
(count(userId) >= 5) as isThrottled,
expiryTimeStamp
group by
throttleKey
INSERT
ALL EVENTS into ResultStream;
Gemäß der Richtlinie:
- Hat KeyTemplate den Wert $resourceKey, was bedeutet, dass die Throttling basierend auf dem Ressourcenpfad erfolgen soll.
- In SiddhiQuery,
- resourceKey =
/test/v1/v1/posts:GET
– Throttling soll für den Endpunkt/test/v1/v1/posts` geprüft werden, der eine GET-Ressource ist. - resourceKey as throttleKey – hier ist der Wert von KeyTemplate identisch mit dem Wert von throttleKey
- timeBatch(1 min) — ist der Zeitraum der Throttling-Richtlinie.
- count(userId) >= 5) as isThrottled — ist die Prüfung für die Anzahl der Throttling-Anfragen (5 Anfragen pro Benutzer-ID).
- resourceKey =
Zusammengefasst bedeutet die obige Siddhi-Abfrage, dass diese Richtlinie einem Benutzer erlaubt, nur 5 Anfragen pro Minute für die GET-Ressource /test/v1/v1/posts zu senden. Danach werden die Anfragen gedrosselt.
Testen der benutzerdefinierten Throttling-Richtlinie
Jetzt müssen wir den Posts-Endpunkt mehr als fünfmal aufrufen, um zu überprüfen, ob die Anfrage gedrosselt wird. Wenn der Endpunkt mehr als fünfmal aufgerufen wird, erhalten wir folgende Meldung mit dem Statuscode 429 (zu viele Anfragen):
Wie oben gezeigt, funktioniert die benutzerdefinierte Throttling wie erwartet und hat keinen Einfluss auf den anderen Endpunkt „todos“. Wenn der Endpunkt „todos“ mehr als fünfmal aufgerufen wird, funktioniert er weiterhin, da die benutzerdefinierte Richtlinie nur zum Drosseln der Ressource „posts“ erstellt wurde.
Zusätzliche Richtlinie – Throttling einer bestimmten API-Ressource für einen bestimmten Benutzeruser
Dies ist eine Richtlinie zum Drosseln einer bestimmten API-Ressource, der Ressource „/posts“, für einen bestimmten Benutzer namens „saad“ unter dem Supertenant.
Key Template: $userId:$resourceKey
Siddhi Query:
FROM
RequestStream
SELECT
userId,
(
userId == 'saad@carbon.super'
and resourceKey == '/test/v1/v1/posts:GET'
) AS isEligible,
str: concat('saad@carbon.super', ':', '/test/v1/v1/posts:GET') as throttleKey
INSERT INTO
EligibilityStream;
FROM
EligibilityStream [ isEligible == true ] # throttler: timeBatch(1 min)
SELECT
throttleKey,
(count(throttleKey) >= 5) as isThrottled,
expiryTimeStamp
group by
throttleKey
INSERT
ALL EVENTS into ResultStream;
Gemäß der obigen Abfrage:
- (userId == ‚saad@carbon.super‚ and resourceKey == ‚/test/v1/v1/posts:GET‘ ) AS isEligible – Hier werden die spezifische Benutzer-ID und der Ressourcenpfad für die Throttling ausgewählt.
- str: concat(’saad@carbon.super‘, ‚:‘, ‚/test/v1/v1/posts:GET‘) as throttleKey – Die spezifische Benutzer-ID und der Ressourcenpfad werden verkettet und als Throttling-Schlüssel festgelegt, der dann mit der Key-Template identisch sein wird.
- timeBatch(1 min) — Ist der Zeitraum der Throttling-Richtlinie.
- count(throttleKey) >= 5) as isThrottled – Ist die Prüfung für die Anzahl der Throttling-Anfragen (5 Anfragen für den Throttling-Schlüssel, wobei 5 Anfragen für den spezifischen Benutzer für die spezifische Ressource zulässig sind).
Zusammengefasst bedeutet die obige Siddhi-Abfrage, dass diese Richtlinie dem Benutzer saad@carbon.super erlaubt, nur 5 Anfragen pro Minute für die GET-Ressource /test/v1/v1/posts zu senden. Danach wird die Anfrage gedrosselt. Die Throttling gilt nicht für andere Ressourcen und auch nicht für andere Benutzer für diese spezielle Ressource.
Zusätzliche Policy – API-Anfragen für alle Benutzer außer dem Superadmin-Benutzer drosseln
Dies ist eine Richtlinie, um API-Anfragen für alle Benutzer außer dem Superadmin-Benutzer zu drosseln. Daher werden die Anfragen für jeden Benutzer gedrosselt, es sei denn, der Benutzer ist ein Administrator im Supertenant.
Key Template: $userId
Siddhi Query:
FROM
RequestStream
SELECT
userId,
(userId != 'admin@carbon.super') AS isEligible,
userId as throttleKey
INSERT INTO
EligibilityStream;
FROM
EligibilityStream [ isEligible == true ] # throttler: timeBatch(1 min)
SELECT
throttleKey,
(count(userId) >= 5) as isThrottled,
expiryTimeStamp
group by
throttleKey
INSERT
ALL EVENTS into ResultStream;
Gemäß der obigen Abfrage,
- (userId != ‚admin@carbon.super‘) AS isEligible – Hier werden alle Benutzer außer dem Superadmin-Benutzer für die Throttling ausgewählt.
- userId as throttleKey – Die Benutzer-ID wird als Throttling-Schlüssel festgelegt, der dann mit der Key-Template identisch sein wird.
- timeBatch(1 min) — Ist der Zeitraum der Throttling-Richtlinie.
- count(userId) >= 5) as isThrottled – Ist die Prüfung für die Anzahl der Throttling-Anfragen (5 Anfragen für jede Benutzer-ID).
Zusammengefasst bedeutet die obige Siddhi-Abfrage, dass diese Richtlinie dem Superadmin-Benutzer (admin@carbon.super) erlaubt, eine unbegrenzte Anzahl von Anfragen zu senden. Alle anderen Benutzer können nur 5 Anfragen pro Minute für alle Ressourcen senden. Danach werden die Anfragen gedrosselt.
Conclusion
Rate Limiting ist eine grundlegende Funktion in jeder API-Management-Plattform. Mit Custom Rate Limiting können Sie verschiedene Vorteile bieten, insbesondere wenn Sie spezifische Anwendungsfälle und Anforderungen haben, die über die standardmäßigen Ratenbegrenzungsrichtlinien hinausgehen. Sie ermöglicht eine fein granulare Steuerung der Drosselung basierend auf API-Kontext, Version, Ressourcenpfad, Benutzer-ID usw. Diese Kontrolle ermöglicht Anpassungen an sich ändernde Bedingungen oder Geschäftsbedürfnisse. Custom Rate Limiting kann personalisierte Benutzererlebnisse unterstützen. Sie können Ratenlimits an das individuelle Benutzerverhalten anpassen und Ihren aktivsten Benutzern ein flüssigeres und reaktionsschnelleres Erlebnis bieten.
Für Branchen mit spezifischen Compliance-Anforderungen kann die Custom Rate Limiting dazu beitragen, dass Ihre API-Nutzung den regulatorischen Standards entspricht. Sie können Ratenlimits implementieren, die den Compliance-Vorgaben entsprechen. Es ist wichtig zu beachten, dass die Custom Rate Limiting zwar diese Vorteile bietet, aber auch eine sorgfältige Planung, Prüfung und kontinuierliche Überwachung erfordert. Die Implementierung einer komplexen Ratenbegrenzungslogik sollte sorgfältig erfolgen, um unbeabsichtigte Dienstunterbrechungen oder zu restriktive Richtlinien zu vermeiden. Berücksichtigen Sie außerdem die Skalierbarkeit Ihrer benutzerdefinierten Ratenbegrenzungslösung, um der wachsenden API-Nutzung gerecht zu werden.