gRPC
Dica
Esse conteúdo é um trecho do livro eletrônico, para Projetar os Aplicativos .NET nativos de nuvem para o Azure, disponível no .NET Docs ou como um PDF para download gratuito que pode ser lido offline.
Até agora neste livro, nos concentramos na comunicação baseada em REST. Vimos que REST é um estilo de arquitetura flexível que define operações baseadas em CRUD em relação aos recursos de entidade. Os clientes interagem com recursos em HTTP com um modelo de comunicação de solicitação/resposta. Embora o REST seja amplamente implementado, uma tecnologia de comunicação mais recente, gRPC, ganhou uma enorme notoriedade em toda a comunidade nativa da nuvem.
O que é gRPC?
gRPC é uma estrutura moderna e de alto desempenho que representa uma evolução do antigo protocolo RPC (chamada de procedimento remoto). No nível do aplicativo, o gRPC simplifica o sistema de mensagens entre clientes e serviços de back-end. Proveniente do Google, o gRPC tem o código aberto e faz parte do ecossistema CNCF (Cloud Native Computing Foundation) de ofertas nativas de nuvem. O CNCF considera gRPC um projeto de incubação. Incubação significa que os usuários finais estão usando a tecnologia em aplicativos de produção, e o projeto tem um número íntegro de colaboradores.
Um aplicativo cliente gRPC típico exporá uma função local em processo que implementa uma operação comercial. Nos bastidores, essa função local invoca outra função em um computador remoto. O que parece ser uma chamada local torna-se essencialmente uma chamada transparente fora do processo para um serviço remoto. A conexão de RPC abstrai a comunicação de rede ponto a ponto, a serialização e a execução entre computadores.
Em aplicativos nativos de nuvem, os desenvolvedores geralmente trabalham em linguagens de programação, estruturas e tecnologias. Essa interoperabilidade complica os contratos de mensagens e a conexão necessários para a comunicação entre plataformas. O gRPC fornece uma "camada horizontal uniforme" que abstrai essas preocupações. Os desenvolvedores codificam em sua plataforma nativa focada na funcionalidade comercial, enquanto o gRPC lida com a conexão de comunicação.
O gRPC oferece suporte abrangente entre as pilhas de desenvolvimento mais populares, incluindo Java, JavaScript, C#, Go, Swift e NodeJS.
Benefícios do gRPC
O gRPC usa HTTP/2 como protocolo de transporte. Embora seja compatível com HTTP 1.1, o HTTP/2 apresenta muitos recursos avançados:
- Um protocolo de enquadramento binário para transporte de dados, ao contrário do HTTP 1.1, que é baseado em texto.
- Suporte a multiplexação para enviar várias solicitações paralelas pela mesma conexão – HTTP 1.1 limita o processamento a uma mensagem de solicitação/resposta por vez.
- Comunicação bidirecional full-duplex para enviar solicitações de cliente e respostas de servidor simultaneamente.
- Streaming interno que habilita solicitações e respostas para transmissão assíncrona de grandes conjuntos de dados.
- Compactação de cabeçalho que reduz o uso da rede.
O gRPC é leve e tem um ótimo desempenho. Ele pode ser até 8x mais rápido do que a serialização JSON, com tamanhos de mensagem 60% a 80% menores. Na linguagem de WCF (Windows Communication Foundation) da Microsoft, o desempenho do gRPC excede a velocidade e a eficiência das associações NetTCP altamente otimizadas. Ao contrário do NetTCP, que favorece a pilha da Microsoft, o gRPC é multiplataforma.
Buffers de protocolo
O gRPC adota uma tecnologia de código aberto chamada Buffers de Protocolo. Eles fornecem um formato de serialização altamente eficiente e independente de plataforma para serializar mensagens estruturadas que os serviços enviam uns aos outros. Usando uma IDL (Linguagem de Definição de Interface) entre plataformas, os desenvolvedores definem um contrato de serviço para cada microsserviço. O contrato, implementado como um arquivo .proto baseado em texto, descreve os métodos, as entradas e as saídas para cada serviço. O mesmo arquivo de contrato pode ser usado para clientes e serviços gRPC criados em diferentes plataformas de desenvolvimento.
O uso do arquivo proto, o compilador Protobuf, protoc, gera o código do cliente e do serviço para sua plataforma de destino. O código inclui os seguintes componentes:
- Objetos fortemente tipados, compartilhados pelo cliente e pelo serviço, que representam as operações de serviço e os elementos de dados de uma mensagem.
- Uma classe base fortemente tipada com a conexão de rede necessária que o serviço gRPC remoto pode herdar e estender.
- Um stub de cliente que contém a conexão necessária para invocar o serviço gRPC remoto.
Em tempo de execução, cada mensagem é serializada como uma representação padrão do Protobuf e trocada entre o cliente e o serviço remoto. Ao contrário de JSON ou XML, as mensagens de Protobuf são serializadas como bytes binários compilados.
Suporte a gRPC no .NET
O gRPC é integrado ao SDK do .NET Core 3.0 e posterior. As seguintes ferramentas dão suporte a ele:
- Visual Studio 2022 com a carga de trabalho ASP.NET e desenvolvimento Web instalada
- Visual Studio Code
- A CLI do
dotnet
O SDK inclui ferramentas para roteamento de ponto de extremidade, IoC interno e registro em log. O servidor Web Kestrel de código aberto dá suporte a conexões HTTP/2. A Figura 4-20 mostra um modelo do Visual Studio 2022 que faz scaffold de um projeto esqueleto para um serviço gRPC. Observe como o .NET é totalmente compatível com Windows, Linux e macOS.
Figura 4-20. Suporte ao gRPC no Visual Studio 2022
A Figura 4-21 mostra o serviço gRPC de esqueleto gerado a partir do scaffolding interno incluído no Visual Studio 2022.
Figura 4-21. Projeto gRPC no Visual Studio 2022
Na figura anterior, observe o arquivo de descrição do proto e o código de serviço. Como você verá em breve, o Visual Studio gera uma configuração adicional na classe de Inicialização e no arquivo de projeto subjacente.
Uso de gRPC
Favoreça gRPC para os seguintes cenários:
- Comunicação síncrona de microsserviço a microsserviço de back-end em que uma resposta imediata é necessária para continuar o processamento.
- Ambientes poliglotas que precisam dar suporte a plataformas de programação mistas.
- Comunicação de baixa latência e alta taxa de transferência em que o desempenho é fundamental.
- Comunicação ponto a ponto em tempo real – O gRPC pode enviar mensagens por push em tempo real sem sondagem e tem excelente suporte para streaming bidirecional.
- Ambientes restritos de rede – Mensagens gRPC binárias são sempre menores do que uma mensagem JSON baseada em texto equivalente.
No momento da produção deste texto, o gRPC é usado principalmente com serviços de back-end. Os navegadores modernos não podem fornecer o nível de controle HTTP/2 necessário para dar suporte a um cliente gRPC de front-end. Dito isto, há suporte para gRPC-Web com .NET que permite a comunicação gRPC de aplicativos baseados em navegador criados com tecnologias JavaScript ou Blazor WebAssembly. O gRPC-Web permite que um aplicativo gRPC ASP.NET Core dê suporte a recursos gRPC em aplicativos do navegador:
- Clientes fortemente tipados e gerados por código
- Mensagens Protobuf compactas
- Streaming de servidor
Implementação do gRPC
A arquitetura de referência de microsserviço, eShop em Contêineres da Microsoft, mostra como implementar serviços gRPC em aplicativos .NET. A Figura 4-22 apresenta a arquitetura de back-end.
Figura 4-22. Arquitetura de back-end para eShop em Contêineres
Na figura anterior, observe como o eShop adota o padrão back-end para front-ends (BFF) expondo vários gateways de API. Discutimos o padrão BFF anteriormente neste capítulo. Preste muita atenção ao microsserviço Agregador (em cinza) que fica entre o Gateway de API Web-Shopping e os microsserviços de Compras de back-end. O Agregador recebe uma única solicitação de um cliente, envia-a para vários microsserviços, agrega os resultados e os envia de volta para o cliente solicitante. Essas operações normalmente exigem comunicação síncrona para produzir uma resposta imediata. No eShop, as chamadas de back-end do Agregador são executadas usando gRPC, conforme mostrado na Figura 4-23.
Figura 4-23. gRPC no eShop em Contêineres
A comunicação gRPC exige componentes de cliente e de servidor. Na figura anterior, observe como o Agregador de Compras implementa um cliente gRPC. O cliente faz chamadas gRPC síncronas (em vermelho) aos microsserviços de back-end, cada um deles implementando um servidor gRPC. O cliente e o servidor aproveitam a conexão gRPC interna a partir do SDK do .NET. Stubs do lado do cliente fornecem a conexão para invocar chamadas gRPC remotas. Os componentes do lado do servidor fornecem a conexão gRPC que as classes de serviço personalizadas podem herdar e consumir.
Os microsserviços que expõem uma API RESTful e uma comunicação gRPC exigem vários pontos de extremidade para gerenciar o tráfego. Você abriria um ponto de extremidade que escuta o tráfego HTTP para as chamadas RESTful e outro para chamadas gRPC. O ponto de extremidade gRPC deve ser configurado para o protocolo HTTP/2 necessário para comunicação gRPC.
Enquanto nos esforçamos para desacoplar microsserviços com padrões de comunicação assíncronos, algumas operações exigem chamadas diretas. gRPC deve ser a principal opção para comunicação síncrona direta entre microsserviços. Seu protocolo de comunicação de alto desempenho, baseado em HTTP/2 e buffers de protocolo, o torna uma escolha perfeita.
Olhando para frente
Olhando para frente, o gRPC continuará a ganhar tração para sistemas nativos de nuvem. Os benefícios de desempenho e a facilidade de desenvolvimento são atraentes. No entanto, REST provavelmente persistirá por um bom tempo. Ele se destaca por APIs expostas publicamente e por compatibilidade com versões anteriores.
