Architekturübersicht zu Cloud Endpoints

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

  • Cloud SDK – zur Bereitstellung und Verwaltung

  • Google Cloud Console – zum Protokollieren, Überwachen und Freigeben

Endpoints-Architektur

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-Back-End 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 wird für die folgenden Plattformen unterstützt:

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

Das Verhalten eines gRPC-Dienstes wird in einer YAML-Datei beschrieben, die auch Endpoints-Konfiguration genannt wird. Sie stellen die Endpoints-Konfiguration und die kompilierten Dateien vom Typ .proto mithilfe des Cloud SDK in der Service Management API bereit. Das SDK konfiguriert die Verwaltungsregeln der API. 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.

Cloud SDK

Das Cloud SDK enthält das gcloud-Befehlszeilentool, mit dem Sie Aufrufe an verschiedene Google Cloud-Dienste senden können. Verwenden Sie das gcloud-Befehlszeilentool, um Ihre Endpoints-Konfiguration in Service Management bereitzustellen.

Google Cloud Console

Cloud Console ist die grafische Benutzeroberfläche für die Google Cloud. Endpoints verwendet die 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 für Anwendungen verwendet, die auf serverlosen Plattformen wie Cloud Run, Cloud Functions und App Engine für Standardumgebung 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.

Weitere Informationen finden Sie unter Endpoints konfigurieren.

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 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.

Geht vom Back-End eine Antwort ein, gibt der ESP die Antwort an den Aufrufer zurück und schickt 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.

Übersicht für Endpoints auf Kubernetes

Weitere Informationen