Prima di precipitarci in gRPC (Google Remote Procedure Call), dovremmo dare un'occhiata a cosa sono le chiamate di procedura remota (RPC).
RPC utilizza un modello client-server. Il server richiedente (in altre parole, il client) richiede un messaggio che viene tradotto dall'RPC e inviato a un altro server. Una volta che il server riceve la richiesta, invia la risposta al client. Mentre il server elabora questa chiamata, il client viene bloccato e il messaggio interno che passa all'interno dei server viene nascosto.
Inoltre, RPC consente al client di richiedere una funzione in un formato particolare e di ricevere la risposta nello stesso identico formato. Tuttavia, il metodo per inviare una chiamata con l'API RPC si trova nell'URL. RPC supporta chiamate di procedure remote sia in ambienti locali che distribuiti.
Come un' API REST, anche RPC stabilisce le regole di interazione e come un utente può inviare "chiamate" (richieste) per invocare metodi che comunicano e interagiscono con il servizio.
Se non ve ne siete ancora resi conto, l'RPC in gRPC sta per Remote Procedure Call. gRPC replica questo stile di comunicazione client server, tramite chiamate di funzione.
Quindi gRPC tecnicamente non è un concetto nuovo. Piuttosto è stato adottato da questa vecchia tecnica e migliorato, rendendolo molto popolare in pochi anni.
gRPC sta per Google Remote Procedure Call ed è una variante basata sull'architettura RPC. Questa tecnologia segue l'implementazione di un'API RPC che utilizza il protocollo HTTP 2.0, ma HTTP non viene presentato allo sviluppatore dell'API né al server. Pertanto, non è necessario preoccuparsi di come vengono mappati i concetti RPC su HTTP, il che riduce la complessità.
Nel complesso, gRPC mira a rendere più veloci le trasmissioni di dati tra microservizi. Si basa sull'approccio di determinazione di un servizio, stabilendo i metodi ei rispettivi parametri per abilitare le chiamate remote e i tipi restituiti.
Inoltre, esprime il modello API RPC in un IDL (interface description language), che offre una via più diretta per determinare le procedure remote. Per impostazione predefinita, l'IDL utilizza i buffer di protocollo (ma sono disponibili anche altre alternative) per descrivere l'interfaccia del servizio e la struttura dei messaggi di payload.
Ora che abbiamo una panoramica di gRPC, diamo un'occhiata alle principali differenze con un servizio REST.
Le API REST seguono un modello di comunicazione richiesta-risposta generalmente basato su HTTP 1.1. Sfortunatamente, ciò implica che se un microservizio riceve più richieste da più client, il modello deve gestire una richiesta alla volta, il che di conseguenza rallenta l'intero sistema. Tuttavia, le API REST possono essere costruite anche su HTTP 2 , ma il modello di comunicazione richiesta-risposta rimane lo stesso, il che impedisce alle API REST di sfruttare al massimo i vantaggi di HTTP 2, come la comunicazione in streaming e il supporto bidirezionale.
gRPC, al contrario, non deve affrontare ostacoli simili. È basato su HTTP 2 e segue invece un modello di comunicazione di risposta del client. Queste condizioni supportano la comunicazione bidirezionale e la comunicazione in streaming grazie alla capacità di gRPC di ricevere più richieste da diversi client e di gestire tali richieste contemporaneamente trasmettendo costantemente informazioni in streaming. Inoltre, gRPC può anche gestire interazioni "unarie" come quelle basate su HTTP 1.1.
Come accennato in precedenza, gRPC utilizza Protocol Buffer per impostazione predefinita per serializzare i dati del payload. Questa soluzione è più leggera poiché consente un formato altamente compresso e riduce le dimensioni dei messaggi. Inoltre, Protobuf (o Protocol Buffer) è binario; quindi serializza e deserializza i dati strutturati per comunicarli e trasmetterli. In altre parole, i messaggi fortemente tipizzati possono essere automaticamente convertiti da Protobuf al linguaggio di programmazione del client e del server.
gRPC ha funzionalità di generazione del codice native grazie al suo compilatore protoc, che è compatibile con diversi linguaggi di programmazione. Ciò è particolarmente vantaggioso per i sistemi a microservizi che integrano vari servizi sviluppati in linguaggi e piattaforme differenti. Tutto sommato, il generatore di codice integrato facilita anche la creazione di SDK (Software Development Kit).
In sintesi, gRPC è in grado di gestire sia interazioni unarie che diversi tipi di streaming:
Unary: quando il client invia una singola richiesta e riceve una singola risposta.
Streaming del server: quando il server risponde con un flusso di messaggi alla richiesta di un client. Una volta inviati tutti i dati, il server invia inoltre un messaggio di stato per completare il processo.
Streaming client: quando il client invia un flusso di messaggi e, a sua volta, riceve un singolo messaggio di risposta dal server.
Streaming bidirezionale: i due flussi (client e server) sono indipendenti, nel senso che entrambi possono trasmettere messaggi in qualsiasi ordine. Il client è colui che avvia e termina lo streaming bidirezionale.
Altre cose interessanti che gRPC ci offre sono:
Metadati: Invece di utilizzare una normale intestazione di richiesta HTTP, gRPC ha i metadati. I metadati sono un tipo di dati chiave-valore che possono essere impostati lato client o server.
Intercettori: gRPC supporta l'utilizzo di intercettori per la sua richiesta/risposta. Gli intercettori, beh, intercettano i messaggi e ti permettono di modificarli.
Se hai giocato con i processi HTTP su un'API REST, gli intercettori sono molto simili al middleware.
Le librerie gRPC di solito supportano gli intercettori e consentono una facile implementazione. Gli intercettori sono solitamente usati per:
Modificare la richiesta/risposta prima di essere inoltrata. Può essere utilizzato per fornire informazioni obbligatorie prima di essere inviato al client/server.
Consentono di manipolare ogni chiamata di funzione, ad esempio per tenere traccia del tempo di risposta.
Bilanciamento del carico: Se non hai già familiarità con il bilanciamento del carico, è un meccanismo che consente di distribuire le richieste dei client su più server.
Ma il bilanciamento del carico viene solitamente eseguito a livello di proxy (ad esempio, NGINX). Allora perché ne parlo qui?
Risulta che gRPC supporta un metodo di bilanciamento del carico da parte del client. È già implementato nella libreria Golang e può essere utilizzato con facilità.
Anche se potrebbe sembrare qualcosa di anomale, non lo è. C'è una sorta di risolutore DNS per ottenere un elenco di IP e un algoritmo di bilanciamento del carico sotto il cofano.
Cancellazione della chiamata: I client gRPC sono in grado di annullare una chiamata gRPC quando non è più necessaria una risposta. Tuttavia, non è possibile eseguire il rollback sul lato server.
Questa funzione è particolarmente utile per lo streaming lato server in cui potrebbero arrivare più richieste del server. La libreria gRPC è dotata di un modello per sapere se una richiesta viene annullata e consentirgli di annullare più richieste corrispondenti contemporaneamente.
gRPC offre molti vantaggi. A differenza di REST, può ottenere il massimo da HTTP 2, utilizzando flussi multiplex e seguendo il protocollo binario . Inoltre, offre vantaggi in termini di prestazioni grazie alla struttura del messaggio Protobuf e non dimentichiamo le funzionalità integrate di generazione del codice che consentono un ambiente multilingue. Questi motivi rendono gRPC uno stile architetturale API promettente.
Vedi Guida completa all'utilizzo del protocollo gRPC
Programmatore informatico italiano, mi occupo di sviluppo sia Front-end che Back-end presso una grande azienda. La programmazione è stata la mia passione, insieme allo sport e al teatro che pratico tutt'ora. Ho deciso di aprire questo blog per dare consigli e condividerli con chi, come me, porta con sé questa passione. [..]
