Panoramica di Cloud Service Mesh con servizi gRPC senza proxy
Questa guida fornisce una panoramica dell'architettura di Cloud Service Mesh. con servizi gRPC senza proxy, inclusi casi d'uso e pattern di architettura.
Il piano di controllo gestito di Cloud Service Mesh consente il routing globale, il bilanciamento del carico e failover a livello di regione per i casi d'uso di mesh di servizi e bilanciamento del carico. Questo include i deployment che incorporano proxy sidecar e gateway. Il supporto di Cloud Service Mesh per le applicazioni gRPC senza proxy offre un un ulteriore modello di deployment in cui le applicazioni gRPC possono partecipare mesh di servizi senza bisogno di un proxy sidecar.
In un esempio tipico, un client gRPC stabilisce una connessione con un server gRPC che ospita la logica di backend. Cloud Service Mesh offre ai tuoi client gRPC informazioni su quali server contattare e su come bilanciare il carico delle richieste più istanze di un server e cosa fare con le richieste se un server in esecuzione.
Per una panoramica completa del funzionamento di Cloud Service Mesh, consulta la Panoramica di Cloud Service Mesh.
Come funziona Cloud Service Mesh con le applicazioni gRPC
Cloud Service Mesh configura i client gRPC con un versione gRPC supportata, in modo simile alla configurazione dei proxy sidecar come Envoy. Tuttavia, le applicazioni gRPC senza proxy connesse direttamente a Cloud Service Mesh non hanno bisogno proxy collaterali. Cloud Service Mesh utilizza invece le API xDS open source per e configurare direttamente le applicazioni gRPC. Queste applicazioni gRPC agiscono come xDS al piano di controllo globale di Cloud Service Mesh. Dopo il giorno sono connessi, le applicazioni gRPC ricevono la configurazione dinamica il piano di controllo, abilitando il rilevamento degli endpoint, il bilanciamento del carico, di failover e controlli di integrità. Questo approccio abilita ulteriori funzionalità di Cloud Service Mesh pattern di deployment.
Nella prima illustrazione, un mesh di servizi viene abilitato utilizzando un proxy sidecar.
Per configurare un proxy sidecar, Cloud Service Mesh utilizza le API xDS. Clienti comunicare con il server tramite il proxy sidecar.
Nella seconda illustrazione, un mesh di servizi è abilitato senza un proxy sidecar. mediante un client gRPC senza proxy.
Se esegui il deployment solo dei servizi gRPC configurati da Cloud Service Mesh, puoi creare un mesh di servizi senza eseguire il deployment di proxy. Questo semplifica l'applicazione delle funzionalità di mesh di servizi alle applicazioni gRPC.
Risoluzione del nome
La risoluzione dei nomi funziona per i deployment senza proxy nei seguenti modi:
- Imposta
xds
come schema di risoluzione dei nomi nel canale client gRPC quando la connessione a un servizio. L'URI di destinazione è formattato comexds:///hostname:port
. Se la porta non è specificata, il valore predefinito è 80, ad esempio in l'URI di destinazionexds:///example.hostname
. - Il client gRPC risolve
hostname:port
nell'URI di destinazione inviando un servizio di rilevamento dell'ascolto (LDS) a Cloud Service Mesh. - Cloud Service Mesh cerca le regole di forwarding configurate che hanno
a una porta corrispondente. Cerca poi la mappa URL corrispondente per una regola host
che corrisponde a
hostname:port
. Restituisce la configurazione del routing associata al client gRPC.
Le regole host che configuri in Cloud Service Mesh devono essere univoche in
tutte le mappe URL. Ad esempio, example.hostname
, example.hostname:80
,
e example.hostname:8080
sono regole diverse.
Risoluzione dei nomi con tipi di deployment diversi
Lo schema di risoluzione dei nomi è diverso per i deployment senza proxy che usano i proxy Envoy.
Il client gRPC utilizza lo schema di risoluzione dei nomi xds
per connettersi a un servizio,
consentendo al client di ricevere la configurazione del servizio
Cloud Service Mesh. Il client gRPC comunica quindi direttamente con
gRPC.
Puoi combinare pattern di deployment proxy sidecar e senza proxy per una maggiore una maggiore flessibilità. La combinazione dei pattern è particolarmente utile quando la tua organizzazione supportano più team con diversi requisiti di funzionalità, e le versioni gRPC.
Nell'illustrazione seguente, sia i client gRPC senza proxy che i client gRPC
con un proxy sidecar di comunicare con un server gRPC. I client gRPC con
i proxy collaterali utilizzano lo schema di risoluzione dei nomi dns
.
Casi d'uso
I seguenti casi d'uso ti aiutano a capire quando potresti voler utilizzare Cloud Service Mesh con applicazioni gRPC senza proxy. Il deployment può includere applicazioni gRPC senza proxy, applicazioni gRPC con proxy sidecar o una combinazione di entrambi.
Efficienza delle risorse in un mesh di servizi su larga scala
Se il tuo mesh di servizi include centinaia o migliaia di client e backend, potresti scoprire che il consumo totale di risorse derivante dall'esecuzione di proxy sidecar inizia ad aumentare. Quando utilizzi applicazioni gRPC senza proxy, non è necessario per introdurre proxy collaterali nel deployment. Un approccio senza proxy può portare in termini di aumento dell'efficienza.
Applicazioni gRPC ad alte prestazioni
Per alcuni casi d'uso, ogni millisecondo di latenza di richieste e risposte è importante. In questo caso, la latenza potrebbe essere ridotta utilizzando una gRPC senza proxy anziché passare ogni richiesta tramite un file collaterale lato client e potenzialmente un proxy sidecar lato server.
Mesh di servizi per ambienti in cui non puoi eseguire il deployment di proxy sidecar
In alcuni ambienti, potresti non essere in grado di eseguire un proxy sidecar come
insieme all'applicazione client o server. Oppure potresti
non potrai configurare lo stack di rete di una macchina per l'intercettazione delle richieste e
il reindirizzamento, ad esempio utilizzando
iptables
In questo caso, puoi utilizzare
Cloud Service Mesh con applicazioni gRPC senza proxy per introdurre il servizio
le funzionalità mesh alle tue applicazioni gRPC.
Mesh di servizi eterogeneo
Poiché le applicazioni gRPC senza proxy e Envoy comunicano con Cloud Service Mesh, il tuo mesh di servizi può includere entrambi i modelli di deployment. L'inclusione di entrambi i modelli ti consente di soddisfare le esigenze operative, le esigenze di prestazioni e funzionalità delle varie applicazioni e dei vari team di sviluppo.
Esegui la migrazione da un mesh di servizi con proxy a un mesh senza proxy
Se hai già un'applicazione gRPC con un proxy sidecar che Cloud Service Mesh configurato, puoi passare a un'applicazione gRPC senza proxy.
Quando viene eseguito il deployment di un client gRPC con un proxy sidecar, utilizza il DNS per risolvere il nome host a cui si connette. Il proxy sidecar intercetta per fornire funzionalità mesh di servizi.
Puoi definire se un client gRPC utilizza la route senza proxy o il file collaterale
route proxy per comunicare con un server gRPC modificando la risoluzione dei nomi
lo schema usato. I client senza proxy utilizzano lo schema di risoluzione dei nomi xds
, mentre
i proxy collaterali utilizzano lo schema di risoluzione dei nomi dns
. Alcuni client gRPC
anche usare la route senza proxy quando si comunica con un server gRPC, ma usare il file
una route proxy quando si comunica con un altro server gRPC. In questo modo puoi migrare gradualmente
a un deployment senza proxy.
Per eseguire la migrazione da un mesh di servizi con proxy a un mesh senza proxy, creare un nuovo servizio Cloud Service Mesh utilizzato dal client gRPC senza proxy. Puoi utilizzare le stesse API per configurare Cloud Service Mesh per l'infrastruttura nuove versioni.
Architettura e risorse
Il modello dei dati di configurazione per i servizi gRPC senza proxy estende la Modello di configurazione di Cloud Service Mesh, con alcune aggiunte e limitazioni descritte in questa guida. Alcune di queste limitazioni sono temporanee perché gRPC senza proxy non supporta tutte le funzionalità di Envoy e altre sono intrinseche all'uso delle RPC. Ad esempio, i reindirizzamenti HTTP che utilizzano gRPC non sono supportati. Per aiutarti a comprendere il modello di configurazione illustrato in questa guida, ti consigliamo di acquisire familiarità con Cloud Service Mesh concetti e configurazione.
Il seguente diagramma mostra le risorse che devi configurare per il proxyless le applicazioni gRPC.
Controlli di integrità
Un controllo di integrità gRPC può controllare lo stato di un servizio gRPC in esecuzione un'istanza di una macchina virtuale (VM) backend o un gruppo di endpoint di rete (NEG).
Se non è possibile utilizzare un controllo di integrità gRPC perché il server gRPC non implementare il protocollo per il controllo di integrità gRPC, usa invece un controllo di integrità TCP. Non utilizzano un controllo di integrità HTTP, HTTPS o HTTP/2.
Per maggiori informazioni, consulta le sezioni Controllo di integrità gRPC e Flag aggiuntivo per i controlli di integrità gRPC.
Servizio di backend
Il servizio di backend definisce il modo in cui un client gRPC comunica con un server gRPC.
Quando crei un servizio di backend per gRPC, imposta il campo del protocollo su GRPC
.
È possibile accedere anche a un servizio di backend configurato con un protocollo impostato su
GRPC
da applicazioni gRPC mediante un proxy sidecar. In tale situazione, gRPC il client non deve utilizzare lo schema di risoluzione dei nomixds
.In tutti i deployment di Cloud Service Mesh, lo schema di bilanciamento del carico per il servizio di backend deve essere
INTERNAL_SELF_MANAGED
.
Backend
I backend ospitano le tue istanze del server gRPC. Puoi utilizzare la modalità gruppi di istanze gestite o non gestite in Compute Engine e NEG di zona in Google Kubernetes Engine come backend per ospitare le istanze del server gRPC.
Passaggi successivi
- Per informazioni sulle API di routing dei servizi e sul loro funzionamento, consulta le Panoramica.
- Per prepararti a configurare Cloud Service Mesh con applicazioni gRPC senza proxy, consulta Preparati alla configurazione con Envoy e carichi di lavoro senza proxy.
- Per saperne di più sulle limitazioni che si applicano ai deployment gRPC senza proxy, consulta Limiti e limitazioni con gRPC senza proxy.