gRPC

Finora, questo libro si è focalizzato sulla comunicazione basata su REST. Si è visto che REST è uno stile di architettura flessibile che definisce operazioni basate su CRUD rispetto alle risorse di entità. I client interagiscono con le risorse in HTTP con un modello di comunicazione di richiesta/risposta. Mentre REST è ampiamente implementato, una tecnologia di comunicazione più recente, gRPC, ha straordinariamente preso piede nella community nativa del cloud.

Che cos'è gRPC?

gRPC è un framework moderno ad alte prestazioni che sviluppa l’obsoleto protocollo RPC (Remote Procedure Call). Al livello di applicazione, gRPC semplifica la messaggistica tra i client e i servizi back-end. gRPC è open source originario di Google e fa parte dell'ecosistema CLOUD Native Computing Foundation (CNCF) di offerte native del cloud. CNCF considera gRPC un progetto in incubazione. In incubazione significa che la tecnologia è usata da utenti finali in applicazioni di produzione e il progetto ha un numero integro di collaboratori.

Un'app client gRPC tipo espone una funzione locale in-process che implementa un'operazione aziendale. Dietro le quinte, la funzione locale richiama un'altra funzione in un computer remoto. Ciò che sembra essere una chiamata locale diventa essenzialmente una chiamata out-of-process trasparente a un servizio remoto. Il plumbing RPC astrae la comunicazione di rete point-to-point, la serializzazione e l'esecuzione tra computer.

Nelle applicazioni native del cloud, gli sviluppatori lavorano spesso con vari linguaggi di programmazione, framework e tecnologie. Questa interoperabilità complica i contratti di messaggio e i meccanismi necessari per la comunicazione multi-piattaforma. gRPC fornisce un "livello orizzontale uniforme" che risolve questi problemi. Il codice degli sviluppatori nella loro piattaforma nativa è focalizzato sulle funzionalità aziendali, mentre gRPC gestisce i meccanismi delle comunicazioni.

gRPC offre supporto completo in tutti gli stack di sviluppo più diffusi, tra cui Java, JavaScript, C#, Go, Swift e NodeJS.

Vantaggi di gRPC

gRPC usa HTTP/2 per il protocollo di trasporto. Sebbene sia compatibile con HTTP 1.1, HTTP/2 offre molte funzionalità avanzate:

• Un protocollo di frame binario per il trasporto dati, mentre HTTP 1.1 è basato su testo.
• Supporto multiplex per l'invio di più richieste parallele tramite la stessa connessione, mentre HTTP 1.1 può elaborare solo un messaggio di richiesta/risposta alla volta.
• Comunicazione full duplex bidirezionale per l'invio simultaneo di richieste client e risposte server.
• Streaming integrato che abilita le richieste e le risposte per trasmettere in modo asincrono set di dati di grandi dimensioni.
• Compressione dell'intestazione per ridurre l'utilizzo di rete.

gRPC è leggero e altamente efficiente. Può essere fino a 8 volte più veloce della serializzazione JSON con messaggi ridotti del 60-80%. Nel linguaggio di Microsoft Windows Communication Foundation (WCF), le prestazioni di gRPC superano la velocità e l'efficienza dei bidning NetTCP altamente ottimizzati. A differenza di NetTCP, che favorisce lo stack Microsoft, gRPC è multi-piattaforma.

Buffer di protocollo

gRPC adotta una tecnologia open source denominata Buffer di protocollo. Questi forniscono un formato di serializzazione altamente efficiente e indipendente dalla piattaforma per serializzare messaggi strutturati inviati tra servizi. Usando un linguaggio IDL (Interface Definition Language) multi-piattaforma, gli sviluppatori definiscono un contratto di servizio per ogni microservizio. Il contratto, implementato come file .proto in formato di testo, descrive i metodi, gli input e gli output per ogni servizio. Lo stesso file di contratto può essere usato per i client e i servizi gRPC basati su altre piattaforme di sviluppo.

Usando il file proto, il compilatore Protobuf protoc genera sia il codice client che il codice del servizio per la piattaforma di destinazione. Il codice include i seguenti componenti:

• Oggetti altamente tipizzati, condivisi dal client e dal servizio, che rappresentano le operazioni del servizio e gli elementi dati per un messaggio.
• Una classe di base altamente tipizzata con il sistema di idraulica di rete richiesto che può essere ereditato ed esteso dal servizio gRPC remoto.
• Uno stub client che contiene l'impianto idraulico necessario per eseguire il servizio gRPC remoto.

In fase di esecuzione, ogni messaggio viene serializzato come rappresentazione Protobuf standard e scambiato tra il client e il servizio remoto. A differenza di JSON o XML, i messaggi Protobuf vengono serializzati come byte binari compilati.

Supporto di gRPC in .NET

gRPC è integrato in .NET Core 3.0 SDK e versioni successive. È supportato dai seguenti strumenti:

• Visual Studio 2022 con i carichi di lavoro ASP.NET e di sviluppo Web installati
• Visual Studio Code
• L’dotnetinterfaccia della riga di comando

L'SDK include strumenti per il routing degli endpoint, IoC integrato e registrazione. Il server Web Kestrel open source supporta le connessioni HTTP/2. La figura 4-20 mostra un modello di Visual Studio 2022 che esegue lo scaffolding dello scheletro di un progetto per un servizio gRPC. Notare che .NET supporta interamente Windows, Linux e macOS.

Figura 4-20. Supporto di gRPC in Visual Studio 2022

La figura 4-21 mostra lo scheletro del servizio gRPC generato dallo scaffolding integrato incluso in Visual Studio 2022.

Figura 4-21. Progetto gRPC in Visual Studio 2022

Nella figura precedente, notare il file di descrizione proto e il codice del servizio. Come si vedrà a breve, Visual Studio genera una configurazione aggiuntiva sia nella classe Startup che nel file di progetto sottostante.

Utilizzo di gRPC

È consigliabile utilizzare gRPC per i seguenti scenari:

• Comunicazione back-end sincorna da microservizio a microservizio in cui è necessaria una risposta immediata per continuare l'elaborazione.
• Ambienti poliglotti che devono supportare piattaforme di programmazione mista.
• Bassa latenza e comunicazione ad alta velocità effettiva in cui le prestazioni sono fondamentali.
• Comunicazione da punto a punto in tempo reale: gRPC può eseguire il push dei messaggi in tempo reale senza polling e offre un ottimo supporto per lo streaming bidirezionale.
• Ambienti vincolati dalla rete: i messaggi gRPC binari sono sempre più piccoli rispetto a un messaggio di testo JSON equivalente.

Al momento della stesura di questo articolo, gRPC è usato principalmente con servizi back-end. I browser moderni non forniscono il livello di controllo di HTTP/2 necessario per supportare un client gRPC front-end. Tuttavia, è disponibile un supporto per gRPC-Web con .NET che consente la comunicazione gRPC da app basate su browser compilate con JavaScript o tecnologie Blazor WebAssembly. gRPC-Web consente a un'app ASP.NET Core gRPC di supportare le funzionalità gRPC nelle app browser:

• Client altamente tipizzati generati da codici
• Messaggi Protobuf compatti
• Streaming del server

Implementazione di gRPC

L'architettura di riferimento dei microservizi eShop in contenitori di Microsoft, illustra come implementare i servizi gRPC nelle applicazioni .NET. La figura 4-22 illustra l'architettura back-end.

Figura 4-22. Architettura back-end per eShop in contenitori

Nella figura precedente, notare come eShop usa il modello back-end per front-end (BFF), esponendo più gateway API. Il modello BFF è stato illustrato in precedenza in questo capitolo. Prestare particolare attenzione al microservizio Aggregator (in grigio) che si trova tra il gateway API Web-Shopping e i microservizi di shopping back-end. Aggregator riceve una singola richiesta da un client, la invia a vari microservizi, aggrega i risultati e li invia al client richiedente. Generalmente, tali operazioni richiedono comunicazioni sincrone per produrre una risposta immediata. In eShop, le chiamate back-end da Aggregator vengono eseguite usando gRPC, come illustrato nella figura 4-23.

Figura 4-23. gRPC in eShop in contenitori

La comunicazione gRPC richiede sia componenti client che server. Nella figura precedente, notare come l'aggregatore di shopping implementa un client gRPC. Il client effettua chiamate gRPC sincrone (in rosso) ai microservizi back-end, ognuno dei quali implementa un server gRPC. Sia il client che il server sfruttano l'impianto gRPC integrato di .NET SDK. Gli stub dal lato del client forniscono l'impianto necessario a eseguire chiamate gRPC remote. I componenti dal lato del server forniscono l’impainto gRPC che può essere ereditato e utilizzato dalle classi di servizio personalizzate.

I microservizi che espongono sia un'API RESTful che una comunicazione gRPC richiedono più endpoint per gestire il traffico. Si aprirebbe un endpoint in ascolto del traffico HTTP per le chiamate RESTful e un altro per le chiamate gRPC. L'endpoint gRPC deve essere configurato per il protocollo HTTP/2 necessario alla comunicazione gRPC.

Mentre ci impegnamo per disaccoppiare i microservizi con modelli di comunicazione asincroni, alcune operazioni richiedono chiamate dirette. gRPC è l‘opzione consigliabile per la comunicazione sincrona diretta tra microservizi. Il protocollo di comunicazione ad alte prestazioni, basato su buffer HTTP/2 e di protocollo, lo rende una scelta perfetta.

Guardando al futuro

Guardando al futuro, gRPC continuerà a prendere piede per i sistemi nativi del cloud. I vantaggi di prestazione e la facilità di sviluppo sono qualità accattivanti. Tuttavia, è probabile che REST rimanga in uso ancora per molto tempo. Eccelle per API esposte pubblicamente e per motivi di compatibilità con le versioni precedenti.