Endpoints ist ein verteiltes API-Verwaltungssystem, das aus Diensten, Laufzeiten und Tools besteht. Endpoints bietet Verwaltung, Monitoring und Authentifizierung.
Endpoints besteht aus folgenden Komponenten:
Extensible Service Proxy (ESP) oder Extensible Service Proxy V2 (ESPv2) – zum Einfügen der Funktionalität von Endpoints.
Service Control – zur Anwendung von API-Verwaltungsregeln
Service Management – zur Konfiguration von API-Verwaltungsregeln
Google Cloud CLI – für die Bereitstellung und Verwaltung
Google Cloud Console – zum Protokollieren, Überwachen und Freigeben
Endpoints-Architektur
Endpoints-Komponenten
ESP
Der ESP ist ein auf NGINX basierender Proxy, der dem Back-End vorgelagert ist und die Funktionalität von Endpoints einfügt, zum Beispiel Authentifizierung, Monitoring und Logging. Der ESP ruft eine Dienstkonfiguration aus Service Management ab und verwendet sie zur Überprüfung eingehender Anfragen.
Der ESP wird in einer Containerumgebung bereitgestellt und validiert JWTs und Google-ID-Tokens. Dank verschiedener Techniken, zu denen unter anderem starkes Caching und asynchrone Aufrufe gehören, arbeitet der ESP hochperformant und sehr ressourcensparend.
ESP-Support ist für die folgenden Plattformen verfügbar:
ESPv2
ESPv2 ist ein leistungsstarker, skalierbarer Proxy, der auf Envoy basiert und vor einem OpenAPI- oder gRPC-API-Backend ausgeführt wird. Endpoints unter ESPv2 unterstützt Version 2 der OpenAPI-Spezifikation und der gRPC-Spezifikation.
ESPv2 kann in Google Service Infrastructure eingebunden werden, um API-Verwaltungsfunktionen in großem Maßstab zu aktivieren. Dazu gehören Authentifizierung, Telemetrieberichte, Messwerte und Sicherheit.
ESPv2-Support ist für die folgenden Plattformen verfügbar:- App Engine-Standardumgebung
- Cloud Run-Funktionen
- Cloud Run
- Knative Serving
- Compute Engine
- Google Kubernetes Engine
- Kubernetes
Service Control
Service Control wendet API-Verwaltungsregeln wie Schlüsselauthentifizierung, Monitoring und Logging zur Laufzeit an. Service Control bietet die folgenden Methoden:
Überprüfung – verifiziert Authentifizierungs- und API-Schlüssel und gibt an, ob ein Aufruf zugelassen werden soll
Bericht – benachrichtigt die Systeme über die Aufzeichnungen für Logging und Monitoring
Service Management
Verwenden Sie die OpenAPI-Spezifikation, um die Oberfläche und das Verhalten Ihrer API in einer Textdatei zu beschreiben, die als Endpoints-Konfiguration bezeichnet wird. Stellen Sie die Endpoints-Konfiguration für Service Management bereit. Verwenden Sie dazu die gcloud-Befehlszeile, die die API-Verwaltungsregeln konfiguriert. Hier werden auch andere Konfigurationsaufgaben durchgeführt, z. B. das Freigeben der API für andere Entwickler, das Aktivieren oder Deaktivieren der API in verschiedenen Projekten und das Generieren von API-Schlüsseln.Die gcloud CLI
Die gcloud CLI stellt die Google Cloud CLI bereit, die Sie mit denen verschiedene Google Cloud-Dienste aufgerufen werden können. Sie verwenden die Google Cloud CLI zum Bereitstellen Ihrer Endpunkte Konfiguration für Service Management.
Google Cloud Console
Die Google Cloud Console ist die grafische Benutzeroberfläche für Google Cloud Endpoints verwendet die Google Cloud Console, um Monitoring- und Loggingdaten anzuzeigen, die von ESP oder ESPv2 gesendet und von Service Control aufgezeichnet werden, und APIs mit anderen Entwicklern gemeinsam zu nutzen und für diese API-Schlüssel zum Aufrufen der API zu generieren.
Bereitstellungsszenarien
Die Optionen für die Bereitstellung hängen von der Verwendung von ESP oder ESPv2 als Endpoints-Proxy ab. ESPv2 kann als Remote-Proxy bereitgestellt werden, und sowohl ESPv2 als auch ESP können im Sidecar-Modus bereitgestellt werden, wie in den folgenden Abschnitten beschrieben.
Remote-Proxymodus
Wenn Sie ESPv2 Beta verwenden, können Endpunkte als Remote-Proxy bereitgestellt werden. Dieser Modus wird zur Unterstützung von Anwendungen verwendet, die auf serverlosen Plattformen wie Cloud Run, Cloud Run-Funktionen und App Engine für Standardumgebungen ausgeführt werden.
In diesem Modus wird ESPv2 Beta als Cloud Run-Anwendung bereitgestellt. Die Anwendung ist so konfiguriert, dass ESPv2 als Remote-Back-End verwendet wird. Verwenden Sie dazu in der OpenAPI-Dienstkonfiguration das Feld x-google-backend. Wenn Sie in diesem Bereitstellungsmodus als Remote-Proxy arbeiten, kann eine einzelne ESPv2 mehrere Remote-Back-Ends unterstützen.
Sidecar-Modus
Sowohl ESP als auch ESPv2 unterstützen die Bereitstellung in einem Container zusammen mit jeder Instanz Ihres Back-Ends. Diese serverseitige Topologie ist sowohl für APIs, die auf das Web ausgerichtet sind, als auch für Mikrodienste ideal. Sie verhindert den Netzwerk-Hop, der typischerweise mit zentralisierten Proxys verbunden ist, und erlaubt eine leistungsfähige, skalierbare API-Verwaltung.
In der Regel wird Load-Balancing angewendet, bevor der Traffic ESP oder ESPv2 erreicht. Bei App Engine erfolgt das Load-Balancing automatisch. Bei Compute Engine erfolgt dies über Cloud Load Balancing. Bei Kubernetes-Deployments können Sie einen Eingangsproxy zum Load-Balancing verwenden. In Google Kubernetes Engine können Sie für das Load-Balancing entweder Cloud Load Balancing oder einen Eingangsproxy verwenden.
Beim Start erhält der ESP oder ESPv2 seine Dienstkonfiguration von Service Management. Diese Dienstkonfiguration wird aus der OpenAPI-Spezifikation oder aus der YAML-Dienstkonfigurationsdatei gRPC generiert. Sie teilt ESP oder ESPv2 sowohl die Oberfläche der zu verwaltenden API als auch die Richtlinien mit, beispielsweise welche Methoden Authentifizierung oder API-Schlüssel benötigen.
Routing anfordern
Wenn eine Anfrage empfangen wird, erstellt ESP oder ESPv2 ein Trace-Token für Cloud Trace.
Anschließend gleicht ESP oder ESPv2 den Pfad der eingehenden Anfragen mit der API-Oberfläche ab. Nachdem eine passende Route gefunden wurde, führt ESP oder ESPv2 alle Authentifizierungsschritte für die angegebene Methode aus.
Wenn eine JWT-Validierung notwendig ist, validiert ESP oder ESPv2 die Authentifizierung mithilfe des passenden öffentlichen Schlüssels für den Signer und validiert das Zielgruppenfeld in JWT. Wenn ein API-Schlüssel erforderlich ist, ruft ESP oder ESPv2 die Service Control API auf, um den Schlüssel zu validieren.
Service Control sucht den Schlüssel, um ihn zu validieren, und überprüft, ob in dem Projekt, zu dem der Schlüssel gehört, die API aktiviert ist. Falls der Schlüssel nicht gültig ist oder die API im Projekt nicht aktiviert ist, wird der Aufruf zurückgewiesen. Dies wird durch die Service Control API protokolliert.
Wenn Service Control den Schlüssel erfolgreich validiert, wird die Anfrage, zusammen mit den ursprünglichen Headern und ggf. einem JWT-Validierungs-Header an das Back-End weitergeleitet.
Wenn das Back-End eine Antwort empfängt, gibt ESP oder ESPv2 die Antwort an den Aufrufer zurück und sendet die endgültigen Zeitinformationen an Trace. Die Aufrufpunkte werden über die Service Control API erfasst, die Messdaten und Logs an die entsprechenden Ziele schreibt.
ESP oder ESPv2 in Kubernetes
Das folgende Diagramm zeigt die gesamte Architektur. Hier wird der ESP als "Sidecar"-Container vor dem Anwendungscontainer des API-Diensts ausgeführt. Die API my-api wird unter my-api.com gehostet und von einem Kubernetes-Dienst unterstützt. Die Architektur wäre bei einer Sidecar-Bereitstellung mit ESPv2 identisch.
