Endpoints è un sistema di gestione delle API distribuito che comprende servizi, runtime e strumenti. Endpoints fornisce la gestione, il monitoraggio e l'autenticazione.
I componenti che costituiscono Endpoints sono:
Extensible Service Proxy (ESP) o Extensible Service Proxy V2 (ESPv2) per iniettare 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 il logging, il monitoraggio e la condivisione.
Architettura di Endpoints
Componenti endpoint
ESP
ESP è un proxy basato su NGINX che viene eseguito davanti al backend e inietta funzionalità di Endpoints come autenticazione, monitoraggio e logging. ESP recupera una configurazione del servizio da Service Management e la utilizza per convalidare le richieste in arrivo.
ESP è progettato per essere implementato in un ambiente con contenitori e per convalidare i token JWT e ID Google. Utilizza una serie di tecniche, come la memorizzazione nella cache e le chiamate asincrone, per rimanere leggero e offrire prestazioni elevate.
L'assistenza di 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 dell' Specifica OpenAPI e specifiche gRPC.
ESPv2 si integra con Google Service Infrastructure per abilitare le funzionalità di gestione delle API su larga scala, tra cui autenticazione, rapporti di telemetria, metriche e sicurezza.
Il supporto di ESPv2 è disponibile per le seguenti piattaforme:- Ambiente standard di App Engine
- Funzioni Cloud Run
- Cloud Run
- Knative serving
- Compute Engine
- Google Kubernetes Engine
- Kubernetes
Service Control
Service Control applica le regole di gestione delle API a come l'autenticazione della chiave, il monitoraggio e il logging. Service Control fornisce i seguenti metodi:
"Check": verifica l'autenticazione e le chiavi API e indica se è stata effettuata una chiamata dovrebbe essere consentito
Report: notifica ai sistemi di registrazione per il logging e il monitoraggio
Gestione del servizio
Puoi utilizzare la specifica OpenAPI per descrivono la superficie e il comportamento dell'API in un file di testo denominato la configurazione di Endpoints. Esegui il deployment Configurazione degli endpoint per Service Management mediante gcloud CLI, che configura le regole di gestione delle API. Qui vengono eseguite anche altre attività relative 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.gcloud CLI
L'interfaccia a riga di comando gcloud fornisce l'interfaccia a riga di comando Google Cloud che puoi utilizzare per effettuare chiamate a vari servizi Google Cloud. Utilizza Google Cloud CLI per eseguire il deployment della configurazione di Endpoints in Service Management.
Console Google Cloud
La console Google Cloud è l'interfaccia utente grafica di Google Cloud. Endpoints utilizza la console Google Cloud per esporre i dati di monitoraggio e di log inviati da ESP o ESPv2 e registrati da Service Control, nonché per condividere le API con altri sviluppatori e consentire loro di generare chiavi API per chiamare l'API.
Scenari di deployment
Le opzioni di implementazione variano a seconda dell'utilizzo di ESP o ESPv2 come proxy di Endpoints. È possibile eseguire il deployment di ESPv2 come proxy remoto e di eseguire il deployment di ESPv2 ed ESP in modalità sidecar, come spiegato nelle sezioni seguenti.
Modalità proxy remoto
Se utilizzi ESPv2, Endpoints può essere implementato 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à, viene eseguito il deployment di ESPv2 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 ciascuna istanza del backend. Questa topologia locale del server è ideale sia per le API rivolte al web sia per i microservizi. Evita tipicamente l'hop di rete associate a proxy centralizzati e consente una gestione delle API più performante 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. Su Compute Engine, viene eseguito da Cloud Load Balancing. Per nei deployment Kubernetes, puoi utilizzare un proxy in entrata per il bilanciamento del carico. In Google Kubernetes Engine, puoi utilizzare Cloud Load Balancing o un proxy di ingresso per il bilanciamento del carico.
All'avvio, ESP o ESPv2 ottiene la configurazione del servizio da Service Management. La configurazione del servizio viene generata specifica OpenAPI o da gRPC, il file YAML della configurazione del servizio. Dice a ESP o ESPv2 sia la superficie dell'API da gestire insieme ai criteri, ad esempio quali metodi richiedono l'autenticazione e quali richiedono chiavi API.
Routing delle richieste
Quando viene ricevuta una richiesta, ESP o ESPv2 crea un token di traccia per in Cloud Trace.
Successivamente, ESP o ESPv2 associa il percorso delle richieste in arrivo all'interfaccia dell'API. Dopo aver trovato un percorso corrispondente, ESP o ESPv2 esegue tutti 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 pubblico nel JWT. Se è necessaria una chiave API, ESP o ESPv2 chiama l'API Service Control per convalidare la chiave.
Service Control cerca la chiave per convalidarla e assicurarsi che il progetto associato alla chiave abbia attivato l'API. Se la chiave non è valida o se il progetto non ha attivato l'API, la chiamata viene rifiutata e registrata tramite l'API Service Control.
Se Service Control convalida la chiave, la richiesta viene inoltrata al backend insieme a tutte le intestazioni originali e a un'intestazione di convalida JWT, se opportuno.
Quando viene ricevuta una risposta dal backend, ESP o ESPv2 restituisce il parametro in risposta al chiamante e invia le informazioni Trace. I punti di chiamata vengono registrati dal Service Control API, 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 contenitore sidecar davanti al contenitore 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 collaterale con ESPv2.
