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 il failover a livello di regione per il mesh di servizi e i casi d'uso di bilanciamento del carico. Sono inclusi i deployment che incorporano proxy sidecar e gateway. Il supporto di Cloud Service Mesh per le applicazioni gRPC senza proxy offre un modello di deployment aggiuntivo in cui le applicazioni gRPC possono partecipare a un 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 tua logica di backend. Cloud Service Mesh fornisce ai client gRPC informazioni sui server da contattare, su come bilanciare il carico delle richieste a più istanze di un server e su cosa fare con le richieste se un server non è 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 una versione gRPC supportata in modo simile alla configurazione dei proxy sidecar come Envoy. Tuttavia, le applicazioni gRPC senza proxy collegate direttamente a Cloud Service Mesh non hanno bisogno di proxy sidecar. Cloud Service Mesh utilizza invece le API xDS open source per configurare direttamente le applicazioni gRPC. Queste applicazioni gRPC agiscono come client xDS, connettendosi al piano di controllo globale di Cloud Service Mesh. Una volta connesse, le applicazioni gRPC ricevono la configurazione dinamica dal piano di controllo, consentendo il rilevamento degli endpoint, il bilanciamento del carico, il failover a livello di regione e i controlli di integrità. Questo approccio abilita ulteriori pattern di deployment di Cloud Service Mesh.

Nella prima illustrazione, un mesh di servizi viene abilitato utilizzando un proxy sidecar.

Un mesh di servizi abilitato utilizzando un proxy sidecar.
Un mesh di servizi abilitato tramite un proxy sidecar (fai clic per ingrandire)

Per configurare un proxy sidecar, Cloud Service Mesh utilizza le API xDS. I client comunicano con il server attraverso il proxy sidecar.

Nella seconda illustrazione, un mesh di servizi viene abilitato senza un proxy sidecar utilizzando un client gRPC senza proxy.

Un mesh di servizi abilitato utilizzando gRPC senza proxy.
Un mesh di servizi abilitato utilizzando gRPC proxyless (fai clic per ingrandire)

Se esegui il deployment solo di servizi gRPC configurati da Cloud Service Mesh, puoi creare un mesh di servizi senza eseguire il deployment di proxy. In questo modo è più facile portare le funzionalità del mesh di servizi nelle tue applicazioni gRPC.

Risoluzione del nome

La risoluzione dei nomi funziona per i deployment senza proxy nei seguenti modi:

  1. Imposta xds come schema di risoluzione dei nomi nel canale client gRPC durante la connessione a un servizio. L'URI di destinazione è formattato come xds:///hostname:port. Se la porta non è specificata, il valore predefinito è 80, ad esempio nell'URI di destinazione xds:///example.hostname.
  2. Il client gRPC risolve hostname:port nell'URI di destinazione inviando una richiesta di servizio di rilevamento dell'ascolto (LDS) a Cloud Service Mesh.
  3. Cloud Service Mesh cerca le regole di forwarding configurate che hanno una porta corrispondente. Cerca quindi la mappa URL corrispondente per trovare una regola host che corrisponda 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 tutte regole diverse.

Risoluzione dei nomi con tipi di deployment diversi

Lo schema di risoluzione dei nomi è diverso per i deployment senza proxy e i deployment che utilizzano 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 da Cloud Service Mesh. Il client gRPC comunica quindi direttamente con il server gRPC.

Puoi combinare pattern di deployment proxy sidecar e senza proxy per una maggiore flessibilità. La combinazione dei pattern è particolarmente utile quando la tua organizzazione e la tua rete supportano più team con requisiti delle funzionalità, esigenze operative e versioni gRPC diversi.

Nell'illustrazione seguente, sia i client gRPC senza proxy che i client gRPC con un proxy sidecar comunicano con un server gRPC. I client gRPC con proxy sidecar utilizzano lo schema di risoluzione dei nomi dns.

Un mesh di servizi composto da client gRPC senza proxy e client gRPC con proxy sidecar.
Un mesh di servizi composto da client gRPC senza proxy e client gRPC con proxy sidecar (fai clic per ingrandire)

Casi d'uso

I seguenti casi d'uso ti aiutano a capire quando 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 dei proxy sidecar inizia a sommarsi. Quando utilizzi applicazioni gRPC senza proxy, non devi introdurre proxy sidecar nel deployment. Un approccio senza proxy può migliorare l'efficienza.

Applicazioni gRPC ad alte prestazioni

Per alcuni casi d'uso, ogni millisecondo di latenza di richieste e risposte è importante. In questo caso, potresti riscontrare una latenza ridotta quando utilizzi un'applicazione gRPC senza proxy, invece di passare ogni richiesta attraverso un proxy sidecar 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 processo aggiuntivo insieme alla tua applicazione client o server. In alternativa, potresti non essere in grado di configurare lo stack di rete di una macchina per l'intercettazione e il reindirizzamento delle richieste, ad esempio utilizzando iptables. In questo caso, puoi utilizzare Cloud Service Mesh con applicazioni gRPC senza proxy per introdurre le funzionalità del mesh di servizi nelle applicazioni gRPC.

Mesh di servizi eterogeneo

Poiché le applicazioni gRPC senza proxy e Envoy comunicano con Cloud Service Mesh, il mesh di servizi può includere entrambi i modelli di deployment. L'inclusione di entrambi i modelli consente di soddisfare le particolari esigenze operative, di prestazioni e di funzionalità di diverse applicazioni e diversi 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 configurato da Cloud Service Mesh, 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 il traffico per fornire funzionalità di mesh di servizi.

Puoi definire se un client gRPC utilizza la route senza proxy o la route proxy sidecar per comunicare con un server gRPC, modificando lo schema di risoluzione dei nomi che utilizza. I client senza proxy utilizzano lo schema di risoluzione dei nomi xds, mentre i proxy sidecar usano lo schema di risoluzione dei nomi dns. Alcuni client gRPC potrebbero anche utilizzare la route senza proxy quando comunica con un server gRPC, ma utilizzare la route proxy sidecar quando comunica con un altro server gRPC. Ciò consente di eseguire gradualmente la migrazione a un deployment senza proxy.

Per eseguire la migrazione da un mesh di servizi con proxy a un mesh senza proxy, devi creare un nuovo servizio Cloud Service Mesh utilizzato dal client gRPC senza proxy. Puoi utilizzare le stesse API per configurare Cloud Service Mesh per la versione esistente e quella nuova.

Mesh di servizi con un client gRPC che comunica con diversi servizi utilizzando meccanismi senza proxy e basati su proxy.
Mesh di servizi con un client gRPC che comunica con diversi servizi utilizzando meccanismi senza proxy e basati su proxy (fai clic per ingrandire)

Architettura e risorse

Il modello dei dati di configurazione per i servizi gRPC senza proxy estende il 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, mentre altre sono inerenti all'utilizzo di RPC. Ad esempio, i reindirizzamenti HTTP che utilizzano gRPC non sono supportati. Per aiutarti a comprendere il modello di configurazione descritto in questa guida, ti consigliamo di acquisire familiarità con i concetti e la configurazione di Cloud Service Mesh.

Il seguente diagramma mostra le risorse che devi configurare per le applicazioni gRPC senza proxy.

Risorse supportate in gRPC senza proxy per il bilanciamento del carico.
Risorse supportate in gRPC proxyless per il bilanciamento del carico (fai clic per ingrandire)

Controlli di integrità

Un controllo di integrità gRPC può controllare lo stato di un servizio gRPC in esecuzione su un'istanza di macchina virtuale (VM) backend o su un gruppo di endpoint di rete (NEG).

Se non è possibile utilizzare un controllo di integrità gRPC perché il server gRPC non implementa il protocollo per il controllo di integrità gRPC, utilizza un controllo di integrità TCP. Non utilizzare 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.

  • Un servizio di backend configurato con un protocollo impostato su GRPC è accessibile anche dalle applicazioni gRPC tramite un proxy sidecar. In questa situazione, il client gRPC non deve utilizzare lo schema di risoluzione dei nomi xds.

  • 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 gruppi di istanze gestite o non gestite in Compute Engine e NEG di zona in Google Kubernetes Engine come backend per ospitare le tue istanze del server gRPC.

Passaggi successivi