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 – zum Bereitstellen und Verwalten
Google Cloud Console – für Logging, Monitoring und Freigabe
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-Unterstützung ist für die folgenden Plattformen verfügbar: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.proto-Dateien mithilfe der gcloud CLI, die die API-Verwaltungsregeln konfiguriert, für Service Management bereit.
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, mit der Sie verschiedene Google Cloud-Dienste aufrufen können. Mit der Google Cloud CLI stellen Sie Ihre Endpoints-Konfiguration für Service Management bereit.
Google Cloud Console
Die Google Cloud Console ist die grafische Benutzeroberfläche für Google Cloud. In Endpoints werden Monitoring- und Logging-Daten, die vom ESP oder ESPv2 gesendet und von Service Control aufgezeichnet werden, über die Google Cloud Console verfügbar gemacht. Außerdem werden APIs für andere Entwickler freigegeben, damit diese API-Schlüssel zum Aufrufen der API generieren können.
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 mithilfe des Felds x-google-backend in der OpenAPI-Dienstkonfiguration verwendet wird. 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 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 nach dem Schlüssel, um ihn zu validieren, und überprüft, ob die API in dem Projekt, das mit dem Schlüssel verknüpft ist, aktiviert wurde. Wenn der Schlüssel ungültig ist oder die API im Projekt nicht aktiviert wurde, wird der Aufruf abgelehnt und über 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 eine Antwort vom Back-End empfangen wird, 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.
