Tag: grpc, protobuf, http2, microservices, rpc, backend, networking

Livello: intermedio

TL;DR: Framework RPC open source ad alte prestazioni basato su HTTP/2 e Protocol Buffers per comunicazione sincrona e streaming tra microservizi.

Concetti chiave

Usa HTTP/2 come trasporto: multiplexing, header compression (HPACK) e connessione TCP persistente singola.

Serializzazione binaria efficiente e fortemente tipizzata tramite Protocol Buffers (.proto).

Contratti di interfaccia rigorosi (Schema-first) indipendenti dal linguaggio di programmazione.

Generazione automatica di codice client (stub) e interfacce server per molteplici linguaggi.

Supporta 4 pattern di comunicazione: Unary, Server streaming, Client streaming e Bidirectional streaming.

Basso overhead di rete e latenza ridotta rispetto all'accoppiata REST su JSON.

Gestione integrata di metadata di contesto, scadenze temporali (deadlines) e cancellazione chiamate.

Autenticazione nativa tramite TLS/mTLS e token bearer via metadata.

Domande tipiche e risposte pronte

Q: Quando preferisci gRPC rispetto a una classica API REST?R: Lo scelgo per la comunicazione inter-service a bassa latenza e alto throughput, oppure quando mi servono contratti stretti e streaming bidirezionale nativo.

Q: Quali sono i vantaggi principali di Protocol Buffers rispetto a JSON?R: Dimensione del payload drasticamente ridotta, serializzazione/deserializzazione molto più veloce via CPU e garanzia di tipi a tempo di compilazione.

Q: Come gestisci la backward compatibility sui messaggi Protobuf?R: Non cambio mai i field number già assegnati; se un campo diventa deprecato uso reserved ed evito riutilizzi per prevenire corruzioni.

Q: Che differenza c'è tra Server Streaming e Bidirectional Streaming?R: In Server Streaming il client manda una singola richiesta e riceve un flusso di risposte; nel Bidirectional entrambi i lati inviano stream indipendenti e concorrenti.

Insidie e errori comuni

Il browser web non supporta gRPC nativo direttamente: richiede un proxy come Envoy con gRPC-Web.

Il load balancing su HTTP/2 opera a livello L7 (richiesta), non L4 (connessione TCP); i bilanciatori L4 saturano una singola istanza.

Riassegnare o modificare il numero di tag numerico in un file .proto rompe la compatibilità dei dati binari.

Mancata impostazione di deadlines o timeout, che rischia di bloccare thread del chiamante a tempo indefinito.

Ignorare la propagazione del contesto e della cancellazione lungo la catena di microservizi.

Snippet e comandiProtocol Buffers

```syntax = "proto3";

package user.v1;

service UserService {

rpc GetUser (UserRequest) returns (UserResponse);

rpc StreamEvents (UserRequest) returns (stream EventResponse);

}

message UserRequest {

string id = 1;

}

message UserResponse {

string id = 1;

string name = 2;

string email = 3;

}

message EventResponse {

string event_id = 1;

int64 timestamp = 2;

}

Compilazione file proto con protoc per Go

protoc --go_out=. --go_opt=paths=source_relative \

--go-grpc_out=. --go-grpc_opt=paths=source_relative \

proto/user.proto

```

Da ripassare

[ ] Meccanismo di field tags e tipi reserved in Protocol Buffers

[ ] Configurazione di gRPC Interceptors per logging e auth

[ ] Strategie di L7 load balancing (Envoy, client-side LB, Kubernetes service mesh)

[ ] Gestione dei codici di stato nativi gRPC (OK, NotFound, DeadlineExceeded)