Comunicazione interservizi con gRPC – Capitolo 1

In gRPC un’applicazione client può chiamare direttamente metodi su un’applicazione server su una macchina diversa come se fosse un oggetto locale, facilitando la creazione di applicazioni e servizi distribuiti. In gRPC definiamo un servizio e specificiamo i metodi che possono essere chiamato da remoto. Il server implementa questa interfaccia ed esegue un server gRPC per gestire le chiamate client gRPC. Sul lato client, il client ha uno stub che fornisce gli stessi metodi del server.

gRPC supporta molti linguaggi come Go, Python, Java, C ++, Ruby ecc.

gRPC utilizza Protocol Buffers che è di nuovo un termine nuovo di zecca. Protocol Buffers è un modo per definire la struttura dei dati che si desidera serializzare. Per essere più comprensibile è proprio come JSON o XML . Una volta definita la struttura dei dati in un file con. proto extension, utilizziamo il compilatore di protocolli per generare classi di accesso ai dati nelle tue lingue preferite dalla tua definizione di proto. Per ulteriori informazioni sui buffer di protocollo, segui questo link. Buffer di protocollo .

Ecco un esempio di file .proto, come compilarlo in un codice Go e campionare codice client e server gRPC.

campione . proto

service Greeter { 
// Sends a greeting
rpc SayHello (HelloRequest) returns (HelloReply) {}
// Sends another greeting
rpc SayHelloAgain (HelloRequest) returns (HelloReply) {}
}

// The request message containing the user's name.
message HelloRequest {
string name = 1;
}

// The response message containing the greetings
message HelloReply {
string message = 1;
}

Compilazione.

 protoc -I / directory_name/sample.proto --go_out=plugins=grpc:sample 

Vai client

 r, err = c.SayHelloAgain(context.Background(), &pb.HelloRequest{Name: name}) 
if err != nil {
log.Fatalf("could not greet: %v", err)
}
log.Printf("Greeting: %s", r.Message)

Vai al server

 func (s *server) SayHelloAgain(ctx context.Context, in *pb.HelloRequest) (*pb.HelloReply, error) { 
return &pb.HelloReply{Message: "Hello again " + in.Name}, nil
}

Una domanda che è scattata immediatamente nella mia testa dopo aver letto su gRPC e sono sicuro che farà clic sulla mente di chiunque è come è diverso da REST. Dopotutto è basato su RPC che è solo un protocollo di comunicazione, quindi perché non REST? Ecco il confronto tra i due sui seguenti parametri.

Velocità

gRPC è più veloce di REST. gRPC utilizza HTTP2 per impostazione predefinita e, inoltre, utilizza i buffer di protocollo di Google (non è necessario) per la codifica, le informazioni vengono ricevute e disattivate molto più velocemente di JSON. La latenza è un fattore importante in diverse aziende. La codifica JSON è in realtà una parte evidente della latenza durante la creazione del profilo. Per l’architettura di applicazioni distribuite e pesanti, gRPC fa davvero la differenza.

Robustezza

gRPC definisce le relazioni tra client e server e applica rigide regole di comunicazione tra di loro. Nelle chiamate REST, la richiesta e la risposta sono totalmente disaccoppiate: puoi inviare tutto ciò che ti piace e speriamo che l’altra parte capisca cosa farne. Dobbiamo aggiornare sia il server che il client (nel caso di gRPC) per far funzionare le cose quando si apportano modifiche. Previene errori specialmente nell’architettura dei microservizi. Per una tipica piattaforma basata su microservizi, gRPC ne sottolinea l’importanza.

Ulteriori vantaggi

  1. gRPC supporta aggiunte utili come risposte di errore standard e metadati. Per es. se ” Applicazione client ha annullato la richiesta “, il codice ” Annullato ” verrà generato sia sul lato client che sul lato server. Oppure se ” Metodo non trovato sul server “, verrà generato ” UNIMPLEMENTE D” sul lato server. Per ulteriori codici di stato, seguire questo link StatusCodes .
  2. Mantiene aperta la pipa di comunicazione tra l’app del telefono e il servizio back-end e quindi molto utile per creare applicazioni mobili a bassa latenza.
  3. Poiché le richieste possono essere monitorate utilizzando lo stesso contesto attraverso più servizi, è possibile annullare le richieste su sistemi diversi o rintracciarle per vedere cosa sta causando ritardi.
  4. gRPC è molto più efficiente se riutilizzi le connessioni, quindi se sai che utilizzerai di nuovo la stessa connessione, tienila aperta.

Lati negativi di gRPC

Attualmente, il supporto del browser per gRPC non è buono. Quindi, ogni qualvolta viene creata una richiesta da un browser client, non possiamo fidarci di gRPC lì. Ecco perché, attualmente, è il più adatto per la comunicazione tra micro servizi. Nelle versioni future di gRPC, questo problema verrà risolto.

Conclusione

gRPC diventerà un grande nome nel prossimo futuro e specialmente per le organizzazioni che adottano l’architettura dei microservizi.

Tratteremo la differenza tra il server REST e il server gRPC, la connessione e lo smontaggio nei servizi REST HTTP1.1 e il suo confronto con la creazione del canale e poche altre cose nei prossimi capitoli.