Endpoints è un sistema di gestione delle API distribuito composto da servizi, runtime e strumenti. Endpoints fornisce gestione, monitoraggio e autenticazione.
I componenti che compongono Endpoints sono:
Extensible Service Proxy (ESP) o Extensible Service Proxy V2 (ESPv2) - per l'inserimento di endpoint funzionalità.
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 degli endpoint
ESP
ESP è un proxy basato su NGINX che viene eseguito davanti il backend e inserisce funzionalità di endpoint come l'autenticazione, il monitoraggio e il logging. ESP recupera un servizio configurazione da Service Management e la utilizza per convalidare le risorse in entrata richieste.
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.
Il supporto ESP è disponibile per le seguenti piattaforme:
ESPv2
ESPv2 è un servizio basato su Envoy proxy scalabile ad alte prestazioni, eseguito davanti a un backend OpenAPI o gRPC API. Gli endpoint su ESPv2 supportano la versione 2 della specifica OpenAPI e le specifiche gRPC.
ESPv2 si integra con l'Infrastruttura di servizi Google per abilitare le funzionalità di gestione delle API su larga scala, tra cui autenticazione, report sulla telemetria, metriche e sicurezza.
Il supporto di ESPv2 è disponibile per le seguenti piattaforme:Service Control
Service Control applica le regole di gestione delle API in fase di esecuzione, ad esempio l'autenticazione delle chiavi, il monitoraggio e la registrazione. Service Control offre i seguenti metodi:
Controlla: verifica l'autenticazione e le chiavi API e indica se una chiamata deve essere consentita
Report: invia una notifica ai sistemi di riferimento per il logging e il monitoraggio
Gestione del servizio
Descrivi il comportamento del tuo servizio gRPC in un file YAML denominato la configurazione di Endpoints. Esegui il deployment della configurazione di Endpoints e dei file.proto compilati in Service Management utilizzando l'interfaccia a riga di comando gcloud, che configura le regole di gestione delle API.
Qui vengono eseguite anche altre attività di 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. Puoi utilizzare Google Cloud CLI per il deployment degli endpoint configurazione in Service Management.
Console Google Cloud
La console Google Cloud è la Graphic User Interface per in Google Cloud. Endpoints utilizza Console Google Cloud per esporre i dati di monitoraggio e logging inviati ESP o ESPv2 e registrati da Service Control; inoltre, condividi le API con altri sviluppatori e per loro generare chiavi API per chiamare l'API.
Scenari di deployment
Le opzioni per il deployment variano in base all'utilizzo di ESP o ESPv2 come proxy 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 che ESPv2 supportano il deployment in un contenitore 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 tipicamente 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 Compute Engine, questa operazione viene eseguita da Cloud Load Balancing. Per gli implementazioni Kubernetes, puoi utilizzare un proxy in entrata per il bilanciamento del carico. Nella Google Kubernetes Engine, puoi utilizzare Cloud Load Balancing o un traffico in entrata proxy per il bilanciamento del carico.
All'avvio, ESP o ESPv2 ottiene la configurazione del servizio da Gestione del servizio. La configurazione del servizio viene generata specifica OpenAPI o da gRPC, il file YAML della 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 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 eventuali 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 convalidarla.
Service Control cerca la chiave per convalidarla e garantisce che il progetto associato alla chiave ha abilitato l'API. Se la chiave non è valida o il progetto non ha abilitato l'API, la chiamata viene rifiutata e viene registrata l'API Service Control.
Se il Controllo del servizio convalida la chiave, la richiesta e vengono inoltrati tutte le intestazioni originali più un'intestazione di convalida JWT, se appropriata al backend.
Quando viene ricevuta una risposta dal backend, ESP o ESPv2 restituisce la risposta all'autore della chiamata e invia le informazioni sui tempi finali a 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 sarà la stessa per un deployment sidecar con ESPv2.
