Endpoints è un sistema di gestione delle API distribuito, che comprende servizi, runtime e strumenti. Endpoints offre gestione, monitoraggio e autenticazione.
I componenti che compongono gli endpoint sono:
Extensible Service Proxy (ESP) o Extensible Service Proxy V2 (ESPv2), per inserire la funzionalità di 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.
Console Google Cloud - per logging, monitoraggio e condivisione
Architettura degli endpoint
Componenti degli endpoint
ESP
ESP è un proxy basato su NGINX che viene eseguito davanti al backend e inserisce le funzionalità degli endpoint 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 consentirti di eseguirne il deployment in un ambiente containerizzato e di convalidare i token JWT e ID Google. Utilizza una serie di tecniche, come la memorizzazione nella cache intensiva e le chiamate asincrone, per rimanere leggero e ad alte prestazioni.
L'assistenza ESP è disponibile per le seguenti piattaforme:
ESPv2
ESPv2 è un proxy scalabile ad alte prestazioni basato su Envoy che viene eseguito davanti al backend di un'API OpenAPI o gRPC. Endpoints su ESPv2 supporta la versione 2 della specifica OpenAPI e delle specifiche gRPC.
ESPv2 si integra con Google Service Infrastructure per abilitare funzionalità di gestione delle API su larga scala, tra cui autenticazione, report di telemetria, metriche e sicurezza.
L'assistenza ESPv2 è disponibile per le seguenti piattaforme:- Ambiente standard di App Engine
- Cloud Functions
- Cloud Run
- Pubblicazione Knative
- Compute Engine
- Google Kubernetes Engine
- Kubernetes
Service Control
Controllo dei servizi applica le regole di gestione delle API in fase di runtime, come l'autenticazione delle chiavi, il monitoraggio e il logging. Service Control offre i seguenti metodi:
Controllo: consente di verificare l'autenticazione e le chiavi API e indica se una chiamata deve essere consentita
Report: notifica i sistemi di registrazione per il logging e il monitoraggio
Gestione del servizio
Utilizza la specifica OpenAPI per descrivere la piattaforma e il comportamento dell'API in un file di testo denominato configurazione di Endpoints. Per eseguire il deployment della configurazione degli endpoint in Service Management, utilizza gcloud CLI, che configura le regole di gestione delle API. Anche altre attività relative alla configurazione si verificano qui, ad esempio la condivisione dell'API con altri sviluppatori, l'abilitazione o la disattivazione dell'API in progetti diversi e la generazione di chiavi API.Gcloud CLI
gcloud CLI fornisce Google Cloud CLI che puoi utilizzare per effettuare chiamate a vari servizi Google Cloud. Puoi utilizzare Google Cloud CLI per eseguire il deployment della configurazione di Endpoints in Service Management.
Console Google Cloud
La console Google Cloud è la Graphic User Interface di Google Cloud. Endpoints utilizza la console Google Cloud per esporre i dati di monitoraggio e logging inviati da ESP o ESPv2 e registrati da Service Control, nonché per condividere le API con altri sviluppatori e per generare chiavi API per chiamare l'API.
Scenari di deployment
Le opzioni per l'implementazione variano in base all'utilizzo di ESP o ESPv2 come proxy Endpoints. ESPv2 può essere implementato come proxy remoto e sia ESPv2 che ESP possono essere distribuiti in modalità collaterale, 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 Functions e App Engine per gli ambienti standard.
In questa modalità, il deployment di ESPv2 viene eseguito come applicazione Cloud Run. L'applicazione è configurata per utilizzare ESPv2 come backend remoto mediante 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 che ESPv2 supportano il deployment in un container insieme a ogni istanza del backend. Questa topologia server-locale è ideale sia per le API per il web che per i microservizi. Evita l'hop di rete tipicamente associato a proxy centralizzati e consente una gestione delle API ad alte prestazioni e scalabile.
In genere, il bilanciamento del carico viene applicato prima che il traffico raggiunga ESP o ESPv2. In App Engine, il bilanciamento del carico viene eseguito automaticamente. In Compute Engine, l'operazione viene eseguita da Cloud Load Balancing. Per i deployment di Kubernetes, puoi utilizzare un proxy in entrata per il bilanciamento del carico. In Google Kubernetes Engine, puoi utilizzare Cloud Load Balancing o un proxy in entrata 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 la superficie dell'API da gestire insieme ai criteri, ad esempio i metodi che richiedono l'autenticazione e quelli che richiedono chiavi API.
Routing delle richieste
Quando viene ricevuta una richiesta, ESP o ESPv2 crea un token di traccia per Cloud Trace.
Quindi, ESP o ESPv2 associano il percorso delle richieste in entrata alla superficie dell'API. Dopo aver trovato una route corrispondente, ESP o ESPv2 esegue qualsiasi passaggio di autenticazione per il metodo specificato.
Se è necessaria la convalida di JWT, ESP o ESPv2 convalida l'autenticazione utilizzando la chiave pubblica appropriata per il firmatario e convalida il campo del pubblico nel JWT. Se è necessaria una chiave API, ESP o ESPv2 chiama l'API Service Control per convalidarla.
Service Control cerca la chiave per convalidarla e garantisce che il progetto associato alla chiave abbia abilitato l'API. Se la chiave non è valida o se il progetto non ha abilitato l'API, la chiamata viene rifiutata e viene registrata tramite l'API Service Control.
Se Service Control convalida la chiave correttamente, la richiesta insieme a tutte le intestazioni originali e a un'intestazione di convalida JWT, se appropriata, vengono inoltrate al backend.
Quando riceve una risposta dal backend, ESP o ESPv2 restituisce la risposta al chiamante e invia le informazioni finali sulla tempistica a Trace. I call point 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 side-car davanti al container dell'applicazione del servizio API, con l'API my-api ospitata in my-api.com e supportata da un servizio Kubernetes. L'architettura sarebbe la stessa per un deployment collaterale con ESPv2.
