Endpoints è un sistema di gestione delle API distribuito che comprende servizi, runtime e strumenti. Endpoints fornisce gestione, monitoraggio e autenticazione.
I componenti che costituiscono Endpoints sono:
Extensible Service Proxy (ESP) o Extensible Service Proxy V2 (ESPv2) - per inserire la funzionalità Endpoints.
Service Control - per applicare le regole di gestione delle API.
Service Management - per configurare le regole di gestione delle API.
Google Cloud CLI - per il deployment e la gestione.
Google Cloud Console - per logging, monitoraggio e condivisione.
Architettura di Endpoints
Componenti di Endpoints
ESP
ESP è un proxy basato su NGINX che viene eseguito davanti al backend e inserisce la funzionalità Endpoints, come autenticazione, monitoraggio e logging. ESP recupera una configurazione del servizio da Service Management e la utilizza per convalidare le richieste in entrata.
ESP è progettato per essere eseguito il deployment in un ambiente containerizzato e per convalidare i JWT e i token ID Google. Utilizza una serie di tecniche, come la memorizzazione nella cache e le chiamate asincrone, per rimanere leggero e altamente performante.
Il supporto ESP è disponibile per le seguenti piattaforme:
ESPv2
ESPv2 è un proxy scalabile e ad alte prestazioni basato su Envoy che viene eseguito davanti a un backend API OpenAPI o gRPC. Endpoints su ESPv2 supporta la versione 2 della specifica OpenAPI e le specifiche gRPC.
ESPv2 si integra con Google Service Infrastructure per abilitare le funzionalità di gestione delle API su larga scala, tra cui autenticazione, report di telemetria, metriche e sicurezza.
Il supporto ESPv2 è disponibile per le seguenti piattaforme:- Ambiente standard di App Engine
- Cloud Run Functions
- Cloud Run
- Knative serving
- Compute Engine
- Google Kubernetes Engine
- Kubernetes
Service Control
Service Control applica le regole di gestione delle API in fase di runtime, come l'autenticazione delle chiavi, il monitoraggio e il logging. Service Control fornisce i seguenti metodi:
Check: verifica l'autenticazione e le chiavi API e indica se una chiamata deve essere consentita
Report: invia una notifica ai sistemi di record per il logging e il monitoraggio
Service Management
Utilizza la specifica OpenAPI per descrivere la superficie e il comportamento dell'API in un file di testo denominato configurazione di Endpoints. Esegui il deployment della configurazione di Endpoints in Service Management utilizzando gcloud CLI, che configura le regole di gestione delle API. Qui vengono eseguite anche altre attività correlate alla configurazione, come la condivisione dell'API con altri sviluppatori, l'attivazione o la disattivazione dell'API in progetti diversi e la generazione di chiavi API.Google Cloud CLI
Google Cloud CLI fornisce Google Cloud CLI, che puoi utilizzare per effettuare chiamate a vari Google Cloud servizi. Utilizza Google Cloud CLI per eseguire il deployment della configurazione di Endpoints in Service Management.
Google Cloud Console
Google Cloud La console è la GUI (Graphic User Interface) di Google Cloud. Endpoints uses the Google Cloud console to expose monitoring and logging data that are sent from ESP or ESPv2 and recorded by Service Control and for sharing APIs with other developers, who can generate API keys to call the API.
Scenari di deployment
Le opzioni di deployment variano a seconda dell'utilizzo di ESP o ESPv2 come proxy Endpoints. ESPv2 può essere eseguito il deployment come proxy remoto ed ESPv2 ed ESP possono essere eseguiti il deployment in modalità sidecar, come spiegato nelle sezioni seguenti.
Modalità proxy remoto
Se utilizzi ESPv2, puoi eseguire il deployment di Endpoints come proxy remoto. Questa modalità viene utilizzata per supportare le applicazioni in esecuzione su piattaforme serverless come Cloud Run, Cloud Run Functions e App Engine per gli ambienti standard.
In questa modalità, ESPv2 viene eseguito il deployment come applicazione Cloud Run. L'applicazione è configurata per utilizzare ESPv2 come backend remoto utilizzando il campo x-google-backend nella configurazione del servizio OpenAPI. Quando funziona come proxy remoto in questa modalità di deployment, un singolo ESPv2 può supportare più backend remoti.
Modalità sidecar
Sia ESP sia ESPv2 supportano il deployment in un container insieme a ogni istanza del backend. Questa topologia locale del server è ideale sia per le API rivolte al web sia per i microservizi. Evita l'hop di rete in genere associato ai proxy centralizzati e consente una gestione delle API altamente performante e scalabile.
In genere, il bilanciamento del carico viene applicato prima che il traffico raggiunga ESP o ESPv2. Su App Engine, il bilanciamento del carico avviene automaticamente. Su Compute Engine, viene eseguito tramite Cloud Load Balancing. Per i deployment di Kubernetes, puoi utilizzare un proxy Ingress per il bilanciamento del carico. In Google Kubernetes Engine, puoi utilizzare Cloud Load Balancing o un proxy Ingress per il bilanciamento del carico.
All'avvio, ESP o ESPv2 ottiene la configurazione del servizio da Service Management. La configurazione del servizio viene generata dalla specifica OpenAPI o da gRPC, il file YAML di configurazione del servizio. Indica a ESP o ESPv2 sia la superficie dell'API da gestire sia i criteri, ad esempio quali metodi richiedono l'autenticazione e quali richiedono le chiavi API.
Routing delle richieste
Quando viene ricevuta una richiesta, ESP o ESPv2 crea un token di traccia per Cloud Trace.
Successivamente, ESP o ESPv2 associa il percorso delle richieste in entrata alla superficie dell'API. Dopo aver trovato una route corrispondente, ESP o ESPv2 esegue i passaggi di autenticazione per il metodo specificato.
Se è necessaria la convalida JWT, ESP o ESPv2 convalida l'autenticazione utilizzando la chiave pubblica appropriata per il firmatario e convalida il campo pubblico nel JWT. Se è richiesta una chiave API, ESP o ESPv2 chiama l'API Service Control per convalidare la chiave.
Service Control cerca la chiave per convalidarla e si assicura che il progetto associato alla chiave abbia abilitato l'API. Se la chiave non è valida o il progetto non ha abilitato l'API, la chiamata viene rifiutata e registrata tramite l'API Service Control.
Se Service Control convalida correttamente la chiave, la richiesta, insieme a tutte le intestazioni originali e a un'intestazione di convalida JWT, se appropriata, viene inoltrata al backend.
Quando viene ricevuta una risposta dal backend, ESP o ESPv2 restituisce la risposta al chiamante e invia le informazioni di temporizzazione finali a Trace. I punti di chiamata vengono registrati dall'API Service Control, che scrive metriche e log nelle destinazioni appropriate.
ESP o ESPv2 su Kubernetes
Il seguente diagramma mostra l'architettura complessiva in cui ESP
viene eseguito come container sidecar davanti al container dell'applicazione del servizio API, con l'API my-api ospitata su my-api.com e supportata da un
servizio Kubernetes. L'architettura sarebbe la stessa per un deployment sidecar con ESPv2.
