Was sind API-Gateway-Richtlinien?

Mit der Entwicklung von Cloud-Native- und Microservices-Architekturen wird die Rolle von API-Gateways als Verkehrsportale immer wichtiger. API-Gateways sind hauptsächlich dafür verantwortlich, angeforderte Anfragen zu empfangen und an die entsprechenden Upstream-Dienste weiterzuleiten. Die Richtlinien des API-Gateways bestimmen die Logik und Regeln für die Verwaltung des Datenverkehrs, was direkt das Verhalten des Geschäftsverkehrs beeinflusst.

Was sind API-Gateway-Richtlinien?

Das API-Gateway befindet sich in der Regel vor allen Upstream-Diensten. Wenn ein Benutzer eine Anfrage an einen Dienst sendet, wird die Anfrage zunächst an das API-Gateway gesendet, und das API-Gateway überprüft in der Regel mehrere Dinge:

1. Überprüfen, ob die Anfrage legal ist. Stammt sie von einer Liste von Benutzern, denen der Zugriff verboten ist?
2. Überprüfen, ob die Anfrage authentifiziert ist und der Zugriff auf die Inhalte autorisiert ist.
3. Überprüfen, ob die Anfrage bestimmte Einschränkungsregeln auslöst, wie z.B. Ratenbegrenzungen.
4. Überprüfen, an welchen Upstream-Dienst die Anfrage weitergeleitet werden soll.

Nach dieser Reihe von Schritten wird die Anfrage entweder abgelehnt oder erreicht den angegebenen Upstream-Dienst korrekt. Wir nennen diese Verarbeitungsregeln die Richtlinien des API-Gateways. Diese Regeln werden kontinuierlich vom Gateway-Administrator hinzugefügt, während das Gateway läuft. Das Gateway akzeptiert diese Regeln und führt entsprechende Verkehrsverarbeitungsaktionen durch.

Nehmen wir das API-Gateway Apache APISIX als Beispiel. Es gibt zwei Arten von APISIX-Konfigurationsinformationen: die Konfigurationsdatei für den Gateway-Start, wie z.B. config.yaml. Diese Datei bestimmt einige Konfigurationen, die für den normalen Start des Gateways erforderlich sind. Darüber hinaus können Administratoren während der Laufzeit dynamisch verschiedene Regeln und Konfigurationen über die Admin API erstellen, wie z.B. Route, Consumer, Plugin usw. Die Richtlinien des API-Gateways sind die verschiedenen Regeln und Konfigurationen, die der Administrator dynamisch über die Admin API erstellt.

Dieser Artikel wird die Szenarien der vier API-Gateways, Authentifizierung und Autorisierung, Sicherheit, Verkehrsverarbeitung und Beobachtbarkeit erläutern und wie API-Gateway-Richtlinien in jedem Szenario funktionieren.

Authentifizierungs- und Autorisierungsrichtlinie

Authentifizierung kann die Identität des API-Aufrufers bestätigen, und Autorisierung beschränkt den Aufrufer darauf, nur auf Ressourcen innerhalb der Berechtigung zuzugreifen.

Wenn beispielsweise ein Passagier zu einem Bahnhof reist, wird er seinen Ausweis zur "Authentifizierung" verwenden, um seine Identität zu bestätigen, bevor er den Bahnhof betritt. Nach dem Betreten des Bahnhofs zeigt er sein Ticket dem Personal zur Bestätigung und wird "autorisiert", um in einen bestimmten Zug einzusteigen. Der Hauptzweck von Authentifizierungs- und Autorisierungsrichtlinien besteht darin, sicherzustellen, dass alle Anfragen, die an Upstream-Dienste weitergeleitet werden, legal sind und die Anfragen nur auf Ressourcen innerhalb des Berechtigungsbereichs zugreifen. Einige Standardrichtlinien sind wie folgt:

Basic Auth

Die Basic Access Authentication-Richtlinie ist die einfachste Zugriffskontrolle. In der Regel trägt der HTTP-Proxy des Benutzers einen Anfrageheader für die Authentifizierung, wenn er eine Anfrage sendet, normalerweise: Authorization: Basic <credentials>, und die Anmeldeinformationen enthalten die Benutzer-ID und das Passwort, die für die Benutzerauthentifizierung erforderlich sind, getrennt durch :. Diese Methode erfordert keine komplexen Einstellungen wie Login-Seiten und Cookies. Sie basiert auf einfachen Anmeldeinformationen im Anfrageheader, in der Regel ein Benutzername und ein Passwort, was einfach zu konfigurieren und zu verwenden ist.

Ein Beispiel für eine cURL-Anfrage mit Basic-Authentifizierung ist wie folgt, mit username und password:

curl -i -u 'username:password' http://127.0.0.1:8080/hello

Es ist zu beachten, dass die Informationen in credentials während der Übertragung nicht verschlüsselt werden. Sie werden nur base64-kodiert, daher müssen sie normalerweise mit HTTPS verwendet werden, um die Sicherheit des Passworts zu gewährleisten.

Nachdem diese Richtlinie im Gateway implementiert wurde, werden Anfragen ohne Anmeldeinformationen nicht weitergeleitet, es sei denn, die korrekten Authentifizierungsinformationen werden in der Anfrage mitgeführt. Diese Richtlinie implementiert die API-Zugriffsüberprüfung mit minimalem Aufwand.

Key Auth

Die Key Auth-Richtlinie beschränkt API-Aufrufe, indem Schlüssel zur API hinzugefügt werden und Schlüssel verwendet werden, um den Zugriff auf Ressourcen zu kontrollieren. Nur Anfragen mit dem richtigen Schlüssel, der im Anfrageheader oder in der Abfrage mitgeführt werden kann, können auf die Ressourcen zugreifen. Normalerweise kann dieser Schlüssel auch verwendet werden, um verschiedene API-Aufrufer zu unterscheiden. So können unterschiedliche Richtlinien oder Ressourcenkontrollen für verschiedene Aufrufer implementiert werden. Wie bei der Basic Auth wird der Schlüssel nicht verschlüsselt. Stellen Sie sicher, dass die Anfrage HTTPS verwendet, um die Sicherheit zu gewährleisten.

Nehmen wir das key-auth-Plugin von APISIX als Beispiel. Das Plugin muss einen Consumer mit einem eindeutigen Schlüsselwert über die Admin API erstellen:

curl http://127.0.0.1:9180/apisix/admin/consumers \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "username": "jack",
    "plugins": {
        "key-auth": {
            "key": "jack-key"
        }
    }
}'

Diese Anfrage erstellt einen Consumer namens jack mit dem Schlüsselwert jack-key.

Wenn das Plugin in der Route aktiviert wird, müssen Sie den Ort und den Feldnamen des Schlüssels in der Anfrage konfigurieren. Die Standardkonfiguration befindet sich im header, und der Feldname ist apikey, daher lautet der korrekte Code für die Anfrage an diese Route:

curl -i http://127.0.0.1:8080/hello -H 'apikey: jack-key'

Sobald APISIX diese Anfrage empfängt, wird APISIX den Schlüssel extrahieren und den Consumer jack aus allen konfigurierten Schlüsseln abgleichen. Das Gateway weiß also, dass die Anfrage von jack gesendet wurde. Wenn kein passender Schlüssel gefunden wird, kann dies als illegale Anfrage gewertet werden.

JSON Web Token

JSON Web Token (JWT) ist ein offener Standard, der eine Möglichkeit definiert, Informationen sicher zwischen Parteien in Form von JSON-Objekten zu übertragen. Die JWT-Richtlinie kann Authentifizierung und Autorisierung kombinieren. Nach der Autorisierung des Benutzers wird ein JWT-Token an den Benutzer übermittelt, und der Aufrufer wird dieses Token in allen nachfolgenden Anfragen mitführen, um sicherzustellen, dass die Anfrage autorisiert ist.

Im API-Gateway kann die JWT-Authentifizierung über die JWT-Richtlinie zum Gateway hinzugefügt werden. So können wir die Authentifizierungslogik vom Geschäftscode trennen, und die Entwickler können sich mehr auf die Implementierung der Geschäftslogik konzentrieren. Nehmen wir das jwt-auth-Plugin von APISIX als Beispiel. Das Plugin muss in Consumer aktiviert und konfiguriert werden, mit seinem eindeutigen Schlüssel, öffentlichen und privaten Schlüsseln für die Verschlüsselung, dem Verschlüsselungsalgorithmus, der Token-Ablaufzeit usw. Gleichzeitig müssen Sie dieses Plugin in der Route aktivieren und das Gateway so konfigurieren, dass es den Ort und die Felder des Tokens liest, wie z.B. Header, Query, Cookie usw. Dieses Plugin fügt dem API-Gateway eine API für die Ausstellung von Tokens hinzu. Bevor die Anfrage gesendet wird, muss die API, die das Token ausstellt, angefordert werden. Das Token muss gemäß den Konfigurationsinformationen an der angegebenen Stelle mitgeführt werden, wenn die Anfrage gesendet wird. Nachdem die Anfrage das Gateway erreicht hat, liest das Gateway das Token gemäß den Konfigurationsinformationen aus der angegebenen Stelle der Anfrage und überprüft die Gültigkeit des Tokens. Nach der Überprüfung kann die Anfrage an den Upstream-Dienst weitergeleitet werden.

Im Vergleich zu den beiden vorherigen Strategien bietet die JWT-Richtlinie eine Option für die Ablaufzeit. Das ausgestellte Token kann mit der Zeit ablaufen, aber die Gültigkeitsdauer von Basic Auth und Key Auth ist dauerhaft, es sei denn, der Server ändert das Passwort oder den Schlüssel. Darüber hinaus kann die JWT-Richtlinie zwischen mehreren Diensten geteilt werden, was für Single Sign-On (SSO)-Szenarien von Vorteil ist.

OpenID Connect

OpenID Connect ist eine Authentifizierungs- und Autorisierungsmethode basierend auf dem OAuth2.0-Protokoll, die eine relativ vollständige Anwendungslösung bietet. Die OpenID Connect-Richtlinie im API-Gateway ermöglicht es dem Upstream-Dienst, Benutzerinformationen vom Identitätsanbieter (IdP) zu erhalten, wodurch die API-Sicherheit geschützt wird. Gängige IdPs sind Keycloak, Ory Hydra, Okta, Auth0 usw. Nehmen wir Apache APISIX als Beispiel, der OpenID Connect-Richtlinien-Workflow im Gateway ist wie folgt:

1. Der Client sendet eine Anfrage an das Gateway
2. Nach Erhalt der Anfrage sendet das Gateway eine Authentifizierungsanfrage an den IdP
3. Der Benutzer wird auf die vom IdP bereitgestellte Seite umgeleitet, um die Anmeldung abzuschließen
4. Der IdP leitet mit dem Authentifizierungscode zurück zum Gateway
5. Das Gateway fordert über den Code ein Access Token vom IdP an, um Benutzerinformationen zu erhalten
6. Das Gateway kann Benutzerinformationen beim Weiterleiten der Anfrage an den Upstream mitführen

Dieser Prozess ermöglicht es, Authentifizierung und Autorisierung vom Geschäft zu trennen, was die Architektur granularer macht.

Weitere Authentifizierungs- und Autorisierungsmethoden für APISIX finden Sie unter API Gateway Authentication.

Sicherheitsrichtlinie

Die API-Gateway-Sicherheitsrichtlinie fungiert wie ein Türsteher, um den sicheren API-Zugriff zu gewährleisten, indem legale Anfragen vom Gateway weitergeleitet werden und illegale Anfragen auf dem Gateway blockiert werden. Laut dem OWASP API Security Project gibt es viele mögliche Bedrohungen und Angriffe auf API-Aufrufer. Die Verwendung der API-Gateway-Sicherheitsrichtlinie kann eine Sicherheitsüberprüfung für alle API-Anfragen durchführen, was eine wichtige Rolle beim Schutz der API vor diesen Sicherheitsbedrohungen spielt.

Die folgenden sind einige wichtige API-Gateway-Sicherheitsrichtlinien:

IP-Zugriffsbeschränkungen

Die IP-Beschränkungsrichtlinie beschränkt den Zugriff bestimmter Clients auf die API, indem bestimmte IPs oder CIDR in einer Zulassungs- oder Sperrliste festgelegt werden, um den böswilligen Zugriff auf sensible Daten zu verhindern. Die ordnungsgemäße Konfiguration dieser Richtlinie wird die Sicherheit der API erheblich verbessern und eine höhere API-Sicherheitsgovernance ermöglichen.

URI-Blocker

Die URI-Sperrrichtlinie blockiert potenziell gefährliche API-Anfragen, indem einige URI-Regeln festgelegt werden. Beispielsweise können einige Sicherheitsangriffe potenzielle Schwachstellen durch das Ausspähen des URI-Pfads erkennen und dann angreifen. Apache APISIX bietet das uri-blocker-Plugin, um gefährliche API-Anfragen zu blockieren. Man kann auch reguläre Ausdrücke über das uri-blocker-Plugin festlegen. Das API-Gateway blockiert die Anfrage, wenn die Anfrage der Regel entspricht. Wenn wir beispielsweise root.exe, admin konfigurieren, kann dieses Plugin */root.exe und */admin-Anfragen blockieren, um die API-Sicherheit weiter zu schützen.

CORS

CORS (Cross-origin resource sharing) ist die Sicherheitsrichtlinie des Browsers für domänenübergreifende Anfragen. In der Regel überprüft der Browser, bevor er eine xhr-Anfrage sendet, ob die Anfrageadresse und die aktuelle Adresse denselben Ursprung haben. Anfragen innerhalb desselben Ursprungs werden direkt gesendet. Andernfalls sendet der Browser zunächst eine OPTION-Typ domänenübergreifende Preflight-Anfrage. In der Antwortheader gibt es CORS-bezogene Einstellungen, wie z.B. die Methoden und die Anmeldeinformationen, die in den domänenübergreifenden Anfragen mitgeführt werden dürfen. Der Browser entscheidet basierend auf diesen Informationen, ob eine formelle Anfrage gesendet wird. Weitere Details finden Sie unter CORS.

In der Regel wird die Antwort mit CORS-Einstellungen vom Backend-Dienst festgelegt. Wenn es jedoch viele Dienste gibt, ist es sicherer und bequemer, sie einheitlich auf der Gateway-Ebene zu verarbeiten. Die CORS-Richtlinie kann unterschiedliche domänenübergreifende Auflösungsrichtlinien für verschiedene APIs festlegen, und Upstream-Dienste müssen diese Logik nicht mehr behandeln.

CSRF

CSRF ist ein domänenübergreifender Anfragefälschungsangriff, der Endbenutzer dazu veranlasst, unfreiwillige Aktionen auf der Website auszuführen, die sie authentifiziert haben. Dieser Angriff wird in der Regel von Social Engineering begleitet (z.B. das Senden eines bösartigen Links an das Opfer per E-Mail). Wenn der Benutzer auf den Link klickt, verwendet der Angreifer die authentifizierte Identität des Opfers, um Angriffsoperationen auf der Website durchzuführen. Aus Sicht der Website ist jedes Verhalten erwartet, da der Benutzer bereits angemeldet ist.

Normalerweise muss der Backend-Dienst der Website zusätzliche Middleware hinzufügen, um diese Logik zu behandeln, und die Präventionsmethoden haben bestimmte Standards. Die Verwendung der CSRF-Richtlinie kann diesen Angriff verhindern und die CSRF-Sicherheitsverarbeitung auf der Gateway-Ebene durchführen, um die logische Komplexität der Upstream-Dienste zu vereinfachen.

Verkehrsverarbeitungsrichtlinie

Die Verkehrsverarbeitungsrichtlinie stellt hauptsächlich sicher, dass die Upstream-Last des API-Gateways für die Weiterleitung des Datenverkehrs innerhalb eines gesunden Bereichs liegt. Gleichzeitig wird die Anfrage vor der Weiterleitung oder Rückgabe an den Aufrufer bedarfsgerecht umgeschrieben. Diese Art von Richtlinie betrifft hauptsächlich Funktionen wie Ratenbegrenzung, Circuit Breaker, Caching und Umschreibung.

Ratenbegrenzung

Bei begrenzten Ressourcen gibt es eine Grenze für die Dienstleistungsfähigkeiten, die die API bereitstellen kann. Wenn der Aufruf diese Grenze überschreitet, kann der Upstream-Dienst abstürzen und einige Kettenreaktionen verursachen. Ratenbegrenzung kann solche Fälle vermeiden und effektiv verhindern, dass APIs von DDOS (Denial-of-service attack) angegriffen werden.

Wir können in der Ratenbegrenzungsrichtlinie ein Zeitfenster und die maximal zulässige Anzahl von Anfragen konfigurieren. Das API-Gateway lehnt Anfragen ab, die die maximal zulässige Anzahl überschreiten, und gibt eine Ratenbegrenzungs-Fehlermeldung zurück. Die Anfrage wird erst zugelassen, wenn die Anzahl der Anfragen unter der Grenze liegt oder das nächste Zeitfenster geöffnet wird.

Die Variable für die Anfragezählung kann in der Anfrage oder als bestimmter Anfrageheader festgelegt werden, z.B. um die entsprechende Geschwindigkeitsbegrenzungsrichtlinie gemäß verschiedenen IPs festzulegen, um eine bessere Flexibilität zu erreichen.

Circuit Breaking

Die API-Circuit-Breaking-Richtlinie kann die Circuit-Breaking-Fähigkeit für Upstream-Dienste bereitstellen. Bei Verwendung dieser Richtlinie müssen Sie die Statuscodes für gesunde und ungesunde Upstream-Dienste für das Gateway festlegen, um den Status der Upstream-Dienste zu beurteilen. Darüber hinaus ist es auch notwendig, den Schwellenwert für Anfragen festzulegen, um einen Bruch oder die Wiederherstellung der Gesundheit auszulösen. Wenn der Upstream-Dienst kontinuierlich ungesunde Statuscodes an das Gateway zurückgibt, wird das Gateway den Upstream-Dienst für einige Zeit unterbrechen. Während dieser Zeit leitet das Gateway keine Anfragen mehr an den Upstream weiter, sondern gibt direkt einen Fehler zurück. Dies kann verhindern, dass Upstream-Dienste aufgrund von Fehlern weiterhin Anfragen erhalten und Geschäftsdienste schützen. Nach dieser Zeit versucht das Gateway erneut, die Anfrage an den Upstream weiterzuleiten. Wenn weiterhin ein ungesunder Statuscode zurückgegeben wird, wird das Gateway die Unterbrechung für eine längere Zeit (verdoppelt) fortsetzen. Bis der Upstream eine bestimmte Anzahl von gesunden Statuscodes zurückgibt, geht das Gateway davon aus, dass der Upstream-Dienst wieder gesund ist, und leitet den Datenverkehr weiter an den Upstream-Knoten.

In dieser Richtlinie ist es auch notwendig, den Statuscode und die Informationen festzulegen, die zurückgegeben werden müssen, wenn der Dienst ungesund ist. Wenn der Upstream-Dienst ungesund ist, wird die Anfrage direkt auf der Gateway-Ebene zurückgegeben, um die Stabilität der Geschäftsdienste zu schützen.

Verkehrsaufteilung

Die Verkehrsaufteilungsrichtlinie kann den Datenverkehr dynamisch in verschiedenen Anteilen an verschiedene Upstream-Dienste weiterleiten. Dies ist besonders nützlich bei Canary Releases und Blue-Green Deployment.

Der Canary Release ermöglicht es, dass nur einige Anfragen den neuen Dienst verwenden, während der andere Teil im alten Dienst bleibt. Wenn der neue Dienst stabil bleibt, können Sie den Anteil erhöhen und schrittweise alle Anfragen auf den neuen Dienst umleiten, bis das Verhältnis vollständig umgeschaltet ist, um das Upgrade abzuschließen.

Der Blue-Green Release ist ein weiteres Bereitstellungsmodell, bei dem eine neue Version während der Spitzenzeit ohne Unterbrechung des Dienstes freigegeben wird. Sowohl die alte als auch die neue Version des Dienstes koexistieren. Typischerweise wird die Produktionsumgebung (blau) in einen identischen, aber separaten Container (grün) kopiert. Neue Updates werden in der grünen Umgebung freigegeben, und dann werden sowohl die grüne als auch die blaue Umgebung in die Produktion freigegeben. Die grüne Umgebung kann dann getestet und repariert werden, während der Benutzer weiterhin auf das blaue System zugreift. Anfragen können dann mit einer Lastverteilungsrichtlinie an die grüne Umgebung umgeleitet werden. Die blaue Umgebung kann dann als Disaster-Recovery-Option oder für das nächste Update aufbewahrt werden.

APISIX unterstützt beide Bereitstellungen über das traffic-split-Plugin, was die Geschäftsbereitstellung bequemer und zuverlässiger macht.

Antwortumschreibung

In der modernen Microservice-Architektur gibt es viele verschiedene Protokolle zwischen Diensten und keine einheitlichen Antwortdatenformate. Wenn diese Transkodierungslogik separat in den jeweiligen Diensten implementiert wird, gibt es redundante Logikcodes, die schwer zu verwalten sind. Einige Antwortumschreibungsrichtlinien können Protokollkonvertierung, Anfragekörperumschreibung und andere Logiken behandeln.

APISIX bietet ein Response Rewrite-Plugin, um den Body oder Header-Informationen, die von Upstream-Diensten zurückgegeben werden, zu ändern, und unterstützt das Hinzufügen oder Löschen von Antwortheadern, das Festlegen von Regeln zur Änderung des Antwortkörpers usw. Dies ist nützlich in Szenarien wie dem Setzen von CORS-Antwortheadern für domänenübergreifende Anfragen oder dem Setzen von Location für Umleitungen.

Andererseits bietet APISIX proxy-rewrite für die Anfrageumschreibung. Das Plugin kann auch den angeforderten Inhalt, der an den Upstream-Dienst weitergeleitet wird, behandeln. Sie können den angeforderten URI, die Methode, den Anfrageheader usw. umschreiben, was in vielen Szenarien die Geschäftsverarbeitung erleichtert.

Fehlerinjektion

Fehlerinjektion ist eine Software-Testmethode, die das korrekte Verhalten eines Systems sicherstellt, indem absichtlich Fehler eingeführt werden. In der Regel wird vor der Bereitstellung getestet, um sicherzustellen, dass es keine potenziellen Ausfälle in der Produktionsumgebung gibt. In einigen Chaos-Testszenarien ist es notwendig, einige Fehler in den Dienst zu injizieren, um seine Zuverlässigkeit zu überprüfen.

Software-Fehlerinjektion kann in Compile-Time-Injektion und Runtime-Injektion kategorisiert werden. Compile-Time-Injektion bezieht sich auf das Ändern einiger Codes oder Logiken beim Schreiben von Software. Runtime-Injektion testet das Verhalten von Software, indem Fehler in der laufenden Softwareumgebung gesetzt werden. Die Fehlerinjektionsrichtlinie kann Fehler in Anwendungsnetzwerkanfragen durch Runtime-Injektion simulieren. Durch die Auswahl eines Verhältnisses in der Richtlinie werden Anfragen in diesem Verhältnis die Fehlerlogik ausführen, wie z.B. die Rückgabe mit einer Verzögerungszeit oder die direkte Rückgabe des festgelegten Fehlercodes und der Fehlermeldung an den Aufrufer. Auf diese Weise kann die Anpassungsfähigkeit der Software erhöht werden, sodass Entwickler einige mögliche Fehlersituationen im Voraus sehen und vor der Veröffentlichung Anpassungen an den Problemen vornehmen können.

Protokollkonvertierung

Die Richtlinie der Protokollkonvertierungsklasse kann zwischen einigen Standardprotokollen wie HTTP-Anfragen und gRPC konvertieren. Apache APISIX bietet das grpc-transcode-Plugin, das HTTP-Anfragen in gRPC-Dienste transkodieren und weiterleiten kann. Die Antwort wird im HTTP-Format an den Client zurückgegeben. Auf diese Weise kann sich der Client nur auf HTTP konzentrieren, ohne auf den Typ des Upstream-gRPC zu achten.

Beobachtbarkeitsrichtlinie

Beobachtbarkeit bezieht sich auf die Fähigkeit, den Betriebszustand des Systems durch die Ausgabedaten des Systems zu messen. In einigen einfachen Systemen, da die Anzahl der Systemkomponenten relativ gering ist, kann der Fehler durch die Analyse des Status jeder Komponente gefunden werden, wenn ein Fehler auftritt. In einem großen verteilten System ist die Anzahl der verschiedenen Microservice-Komponenten jedoch sehr groß, und es ist unrealistisch, die Komponenten einzeln zu überprüfen. Zu diesem Zeitpunkt muss das System beobachtbar sein. Beobachtbarkeit bietet die Sichtbarkeit eines umfangreichen Systems, und wenn ein Problem auftritt, kann es den Ingenieuren die Kontrolle geben, die sie benötigen, um das Problem zu lokalisieren.

Die Datensammlung kann innerhalb von Anwendungskomponenten implementiert werden. Das API-Gateway ist der Eingang des gesamten Datenverkehrs, daher kann die Implementierung der Beobachtbarkeitsfunktionen des Systems im API-Gateway die Nutzung der System-API widerspiegeln. Eine API-Gateway-Beobachtbarkeitsrichtlinie kann allen Teams helfen:

• Ein Team von Ingenieuren kann API-Probleme überwachen und lösen.
• Das Produktteam kann die Nutzung der API verstehen, um den Geschäftswert dahinter zu entdecken.
• Vertriebs- und Wachstumsteams können die API-Nutzung überwachen, Geschäftschancen beobachten und sicherstellen, dass APIs die richtigen Daten liefern.

Beobachtbarkeitsrichtlinien werden in der Regel nach dem Ausgabedatentyp in drei Kategorien unterteilt: Tracing, Metriken und Protokollierung.

Tracing

In einem großen verteilten System ist die Beziehung zwischen Diensten komplex. Tracing (Link-Tracking) kann den vollständigen Aufruflink, die Abhängigkeitsanalyse zwischen Anwendungen und die Anfragestatistik in verteilten Anwendungen verfolgen. Wenn ein Problem im System auftritt, kann es Ingenieuren helfen, den Umfang und den Ort der Untersuchung zu bestimmen.

Die Tracing-Richtlinie kann andere verteilte Aufruflink-Tracking-Systeme im API-Gateway integrieren, um Informationen zu sammeln und aufzuzeichnen. Beispielsweise können Dienste wie Zipkin und SkyWalking in das API-Gateway integriert werden, um Daten und die Kommunikation zwischen Diensten zu sammeln. Daher können Ingenieure mit dieser Richtlinie wissen, welches Protokoll für eine bestimmte Sitzung oder verwandte API-Aufrufe zu sehen ist, und den Umfang der Fehlerbehebung überprüfen.

Metriken

Metriken beziehen sich auf die Beobachtungsdaten einer Software, die während eines Zeitintervalls des Dienstbetriebs gesammelt werden. Diese Daten sind standardmäßig strukturiert, was die Abfrage und Visualisierung erleichtert. Man kann den Betriebszustand des Systems durch die Analyse dieser Daten lernen.

Die Metriken-Richtlinie kann Dienste wie Prometheus oder Datadog im API-Gateway integrieren, um Überwachungs- und Alarmfunktionen für das System bereitzustellen. Diese Richtlinie sammelt Daten während des Betriebs des Gateways über verschiedene API-Gateway-Schnittstellen und meldet Daten an Prometheus oder Datadog. Durch die Visualisierung dieser Daten können Entwickler den Betriebszustand des Gateways, die statistischen Informationen von API-Anfragen und andere statistische Diagramme sehen.

Protokollierung

Das Protokoll ist eine Textaufzeichnung von Systemereignissen zu einem bestimmten Zeitpunkt. Das Protokoll ist der erste Ort, an dem überprüft wird, wenn ein Problem im System auftritt. Ingenieure verlassen sich auf den Protokollinhalt, um herauszufinden, was mit dem System passiert ist, und die entsprechende Lösung zu finden. Der Protokollinhalt ist in der Regel in das API-Anfrageprotokoll und das Betriebsprotokoll des Gateways unterteilt. Das API-Anfrageprotokoll zeichnet alle API-Anfrageaufzeichnungen während des Betriebs des API-Gateways auf. Ingenieure können die API-Zugriffsinformationen durch diese Aufzeichnungen lernen und abnormale Anfragen rechtzeitig erkennen und beheben. Das Betriebsprotokoll des Gateways enthält Aufzeichnungen aller Ereignisse, die während des Betriebs des Gateways aufgetreten sind. Wenn das API-Gateway abnormal ist, kann es als wesentliche Grundlage für die Fehlerbehebung verwendet werden.

Die Protokollierungsrichtlinie kann die Protokolle im API-Gateway auf der Serverfestplatte speichern oder an einige andere Protokollserver wie HTTP-Protokollserver, TCP-Protokollserver, UDP-Protokollserver usw. oder andere Protokollsysteme wie Kafka, RocketMQ, Clickhouse senden.

Zusammenfassung

Dieser Artikel stellt vier häufig verwendete Richtlinien in API-Gateways vor: Authentifizierung und Autorisierung, Sicherheit, Verkehrsverarbeitung und Beobachtbarkeit. Das API-Gateway empfängt angeforderte Anfragen vor allen Upstream-Diensten, kontrolliert, wohin und wie Anfragen weitergeleitet werden, und lehnt unsichere und nicht autorisierte Anfragen direkt ab oder beschränkt sie. API-Gateway-Richtlinien können all diese Verhaltensweisen konfigurieren.

Weitere Informationen zu API-Gateways finden Sie unter Blogs und API7.ai für weitere kommerzielle Unterstützung.