gRPC
Gorjeta
Este conteúdo é um excerto do eBook, Architecting Cloud Native .NET Applications for Azure, disponível no .NET Docs ou como um PDF transferível gratuito que pode ser lido offline.
Até agora, neste livro, nos concentramos na comunicação baseada em REST. Vimos que o REST é um estilo de arquitetura flexível que define operações baseadas em CRUD em relação aos recursos da 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, o gRPC, ganhou um tremendo impulso em toda a comunidade nativa da nuvem.
O que é gRPC?
O gRPC é uma estrutura moderna e de alto desempenho que evolui o antigo protocolo de chamada de procedimento remoto (RPC). No nível do aplicativo, o gRPC simplifica as mensagens entre clientes e serviços back-end. Originário do Google, o gRPC é de código aberto e faz parte do ecossistema de ofertas nativas da nuvem da Cloud Native Computing Foundation (CNCF). O CNCF considera o gRPC um projeto de incubação. Incubar significa que os usuários finais estão usando a tecnologia em aplicações de produção, e o projeto tem um número saudável de contribuidores.
Um aplicativo cliente gRPC típico irá expor uma função local em processo que implementa uma operação de negócios. Sob as cobertas, essa função local invoca outra função em uma máquina remota. O que parece ser uma chamada local torna-se essencialmente uma chamada transparente fora do processo para um serviço remoto. O encanamento RPC abstrai a comunicação, serialização e execução de rede ponto a ponto entre computadores.
Em aplicativos nativos da nuvem, os desenvolvedores geralmente trabalham em linguagens de programação, estruturas e tecnologias. Essa interoperabilidade complica os contratos de mensagens e o encanamento necessário 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 de negócios, enquanto o gRPC lida com o encanamento de comunicação.
O gRPC oferece suporte abrangente nas pilhas de desenvolvimento mais populares, incluindo Java, JavaScript, C#, Go, Swift e NodeJS.
Benefícios do gRPC
gRPC usa HTTP/2 para seu protocolo de transporte. Embora compatível com HTTP 1.1, 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 de 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 de cada vez.
- Comunicação full-duplex bidirecional para enviar solicitações de clientes e respostas do servidor simultaneamente.
- Streaming integrado que permite solicitações e respostas para transmitir grandes conjuntos de dados de forma assíncrona.
- Compressão de cabeçalho que reduz o uso da rede.
O gRPC é leve e de alto desempenho. Pode ser até 8x mais rápido do que a serialização JSON com mensagens 60-80% menores. Na linguagem do Microsoft Windows Communication Foundation (WCF), o desempenho do gRPC excede a velocidade e a eficiência das ligações NetTCP altamente otimizadas. Ao contrário do NetTCP, que favorece a pilha da Microsoft, o gRPC é multiplataforma.
Memória Intermédia do Protocolo
O gRPC adota uma tecnologia de código aberto chamada Protocol Buffers. Eles fornecem um formato de serialização altamente eficiente e neutro em relação à plataforma para serializar mensagens estruturadas que os serviços enviam uns aos outros. Usando uma linguagem de definição de interface (IDL) multiplataforma, os desenvolvedores definem um contrato de serviço para cada microsserviço. O contrato, implementado como um arquivo baseado em .proto texto, descreve os métodos, entradas e saídas para cada serviço. O mesmo arquivo de contrato pode ser usado para clientes gRPC e serviços construídos em diferentes plataformas de desenvolvimento.
Usando o arquivo proto, o compilador Protubuf, 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 serviço, que representam as operações de serviço e os elementos de dados de uma mensagem.
- Uma classe base fortemente tipada com o encanamento de rede necessário que o serviço gRPC remoto pode herdar e estender.
- Um stub de cliente que contém o encanamento necessário 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 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 suportam-no:
- Visual Studio 2022 com a carga de trabalho de desenvolvimento ASP.NET e Web instalada
- Visual Studio Code
- A
dotnetCLI
O SDK inclui ferramentas para roteamento de pontos finais, IoC interno e registro em log. O servidor web Kestrel de código aberto suporta conexões HTTP/2. A Figura 4-20 mostra um modelo do Visual Studio 2022 que cria um scaffold de um projeto esqueleto para um serviço gRPC. Observe como o .NET suporta totalmente Windows, Linux e macOS.
Figura 4-20. Suporte a gRPC no Visual Studio 2022
A Figura 4-21 mostra o serviço gRPC esqueleto gerado a partir do andaime 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 configuração adicional na classe Startup e no arquivo de projeto subjacente.
Utilização do gRPC
Favoreça o gRPC para os seguintes cenários:
- Comunicação síncrona de microsserviço para microsserviço de back-end em que uma resposta imediata é necessária para continuar o processamento.
- Ambientes poliglotas que precisam suportar plataformas de programação mistas.
- Comunicação de baixa latência e alta taxa de transferência onde o desempenho é crítico.
- Comunicação ponto-a-ponto em tempo real - gRPC pode enviar mensagens 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 em que este artigo foi escrito, 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 suportar um cliente gRPC front-end. Dito isso, há suporte para gRPC-Web com .NET que permite a comunicação gRPC a partir de aplicativos baseados em navegador criados com JavaScript ou Blazor WebAssembly tecnologias. O gRPC-Web permite que um aplicativo gRPC ASP.NET Core ofereça suporte a recursos gRPC em aplicativos de navegador:
- Clientes fortemente tipados e gerados por código
- Mensagens compactas do Protobuf
- Streaming de servidor
Implementação do gRPC
A arquitetura de referência de microsserviços, eShop on Containers, 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 Backend for Frontends (BFF) expondo vários gateways de API. Discutimos o padrão BFF no início deste capítulo. Preste muita atenção ao microsserviço Agregador (em cinza) que fica entre o Web-Shopping API Gateway e os microsserviços de back-end do Shopping. O Agregador recebe uma única solicitação de um cliente, a envia para vários microsserviços, agrega os resultados e os envia de volta ao cliente solicitante. Tais operações normalmente exigem comunicação síncrona para produzir uma resposta imediata. Na eShop, as chamadas de back-end do Agregador são realizadas usando gRPC, como mostra a Figura 4-23.
Figura 4-23. gRPC na eShop em Contentores
A comunicação gRPC requer componentes de cliente e servidor. Na figura anterior, observe como o Agregador de Compras implementa um cliente gRPC. O cliente faz chamadas gRPC síncronas (em vermelho) para microsserviços de back-end, cada um dos quais implementa um servidor gRPC. Tanto o cliente quanto o servidor aproveitam o encanamento gRPC interno do SDK do .NET. Os stubs do lado do cliente fornecem o encanamento para invocar chamadas gRPC remotas. Os componentes do lado do servidor fornecem canalizaçã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 a comunicação gRPC.
Embora nos esforcemos para dissociar microsserviços com padrões de comunicação assíncronos, algumas operações exigem chamadas diretas. O 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 tornam uma escolha perfeita.
Perspetivas futuras
Olhando para o futuro, o gRPC continuará a ganhar força para sistemas nativos da nuvem. Os benefícios de desempenho e facilidade de desenvolvimento são atraentes. No entanto, o REST provavelmente estará por aí por um longo tempo. Ele se destaca por APIs expostas publicamente e por motivos de compatibilidade com versões anteriores.
