Introdução ao gRPC. O que é gRPC?

O gRPC foi liberado pelo Google como um projeto de código aberto em 2016 como resultado de melhorias em sua arquitetura de comunicação interna baseada em RPC (Remote Procedure Call) chamada Stubby.

O que é RPC e gRPC?
Quais suas vantagens e limitações?
Quando devemos utilizar o gRPC?

Neste artigo vamos explorar um pouco sobre a história do gRPC, sua arquitetura e vantagens técnicas. Faremos observações sobre sua dependência de HTTP/2, cenários de implementação mais comuns e sua comunidade ativa.

gRPC

O gRPC é um framework RPC (Remote Procedure Call), moderno, de código aberto e alto desempenho que pode ser executado em qualquer ambiente. O gRPC pode conectar serviços de forma eficiente dentro e entre datacenters com suporte plugável para balanceamento de carga, rastreamento, verificação de integridade e autenticação. Também tem sido utilizado nas etapas finais da computação distribuída para conectar dispositivos, aplicativos móveis e navegadores a serviços de backend.

O gRPC foi criado pelo Google, como resultado do aperfeiçoamento de sua infraestrutura RPC interna de uso geral chamada Stubby, utilizada por mais de uma década para conectar o grande número de microsserviços executados dentro e entre seus data centers.

Em 2016, o Google criou uma versão atualizada do Stubby e a tornou um projeto de código aberto. O resultado foi o gRPC, que agora é usado por muitas organizações para suportar casos de uso que vão desde a comunicação entre microsserviços até a computação final por smartphones, web e Internet das Coisas.

O que é RPC?

O que é RPC ou Remote Procedure Call?

O RPC é um modelo de comunicação que remonta a meados dos anos 1970. Bruce Jay Nelson em 1981, que trabalhava na Xerox PARC, utilizou essa nomenclatura para descrever a comunicação entre dois processos dentro do mesmo sistema operacional. Sim: isso ainda é utilizado.

Uma chamada de procedimento remoto (RPC) ocorre quando um procedimento é executado em um espaço de endereço diferente do endereço local (geralmente em outro computador ou numa rede compartilhada), como se fosse executado localmente, sem que o programador necessite codificar explicitamente os detalhes para a interação remota.

Na programação orientada a objetos, RPCs são representados por invocações de métodos remotos (RMIs). O modelo RPC implica em transparência de localização, ou seja, os procedimentos de chamada são praticamente os mesmos, sejam locais ou remotos, todavia não são idênticos, portanto as chamadas locais podem ser diferenciadas das chamadas remotas. As chamadas remotas geralmente são mais lentas e menos confiáveis do que chamadas locais, logo é importante distingui-las.

Uma chamada de procedimento local é uma chamada de função dentro de um processo para executar algum código.

Uma chamada de procedimento remoto permite que uma máquina invoque procedimentos em outra máquina como se fosse executado de forma local sob a ótica do usuário.

Organizações que usam o gRPC

O gRPC é uma implementação popular do modelo RPC.
Muitas organizações adotaram o gRPC como seu mecanismo RPC preferido para conectar um grande número de microsserviços em execução dentro e entre seus datacenters.

Popularidade do gRPC

O que torna o gRPC tão popular?

O gRPC possui um respeitado e crescente ecossistema de desenvolvimento.
Isso facilita o desenvolvimento de APIs seguras, com qualidade de produção e que escalam muito bem.

Visão geral do gRPC

No gRPC, uma aplicação cliente pode chamar diretamente métodos de uma aplicação servidor localizada máquinas diferentes como se fosse um objeto local, facilitando a criação de aplicações e serviços distribuídos.

Como em muitos sistemas RPC, o gRPC é baseado na ideia de definição de um serviço onde se especifica os métodos que podem ser chamados remotamente com seus parâmetros e tipos de retorno. A interface é implementada no servidor gRPC para lidar com as chamadas do cliente. O cliente possui um stub (referido apenas como stub cliente em algumas linguagens) que fornece os mesmos métodos do servidor.

Os clientes e servidores gRPC podem ser executados e se comunicarem através de vários ambientes, desde servidores dentro de um provedor de nuvem até sua área local de trabalho, e podem ser escritos em qualquer linguagem suportada pelo gRPC. Assim, por exemplo, você pode criar facilmente um servidor gRPC em Java com clientes em Go, Python ou Ruby. As APIs do Google mais recentes possuem versões gRPC de suas interfaces, permitindo que você incorpore facilmente funcionalidades do Google em seus aplicativos.

Mecanismos gRPC

O núcleo do ecossistema gRPC é o uso de Buffers de Protocolo ou Protocol Buffers ou simplesmente ProtoBuf, como formato de troca de dados.

Buffers de Protocolo é uma Linguagem de Definição de Interfaces (IDL) e um mecanismo agnóstico, independente de linguagens de programação e plataformas usado para codificação de dados estruturados.

O gRPC usa Buffers de Protocolo como padrão para codificar e enviar dados pela rede. Embora o gRPC possa utilizar outros formatos de codificação de dados como JSON, Buffers de Protocolo fornece várias vantagens que o torna o formato de codificação preferido para o gRPC. Buffers de Protocolo oferecem suporte a definições de esquemas fortemente tipados.

A estrutura dos dados a ser transitada pela rede é definida em um arquivo do tipo proto. Um arquivo do tipo proto é um arquivo de texto comum com uma extensão .proto. Os dados são estruturados como mensagens, onde cada mensagem é um pequeno registro lógico de informações contendo uma série de pares nome-valor chamados campos.

Suporte aos Buffers de Protocolo

Buffers de Protocolo fornecem um amplo suporte de ferramentas para transformar o esquema dos arquivos do tipo proto em classes de acesso a dados para as linguagens de programação mais populares.

Um serviço gRPC também é definido num arquivo do tipo proto especificando-se os parâmetros do método RPC e os tipos de retorno.

As mesmas ferramentas são usadas para gerar os códigos do cliente e servidor gRPC a partir do arquivo do tipo proto. Os desenvolvedores usam essas classes geradas no cliente para fazer solicitações RPC, e no servidor para atender às solicitações RPC.

Razões para a popularidade do gRPC

Ao oferecer suporte a muitas linguagens de programação, o cliente e o servidor podem escolher de forma independente qual a linguagem de programação e ecossistema mais adequados para seus casos de uso. Tradicionalmente, esse não é um cenário de aplicação para a maioria dos outros frameworks RPC.

A segunda razão pela qual o gRPC é tão popular é porque ele entrega alto desempenho de forma padrão sem necessidade de configurações adicionais.

Dois fatores contribuem para seu desempenho.

O primeiro fator é que Buffers de Protocolo possuem um formato de codificação binária muito eficiente e bem mais rápido que o JSON.

O segundo fator é que o gRPC é construído sobre o HTTP/2 utilizando todos os fundamentos de alto desempenho para cenários que exigem escalabilidade.

Toda mensagem serializada com o ProtoBuf é transformada e enviada em formato binário, de forma que a velocidade de transmissão para o receptor é muito mais elevada que o texto puro, já que ocupa menos banda e como o dado é comprimido pelo HTTP/2, o uso de CPU também é muito menor.

Sobre HTTP/2

O uso do HTTP/2 traz muitos benefícios. Os principais benefícios oferecidos pelo HTTP/2 e aproveitados pelo gRPC são:

• Multiplexação de solicitação: HTTP 1.1 é um protocolo sequencial. Assim, podemos enviar uma única solicitação por vez. O HTTP/2, por sua vez, permite enviar requisições e receber respostas de forma assíncrona. Dessa forma, podemos fazer várias solicitações ao mesmo tempo usando uma única conexão
• Priorização de solicitações: com o HTTP/2, podemos definir uma priorização numérica em um lote de solicitações. Assim, podemos ser explícitos em que ordem esperamos as respostas, como obter um CSS de página da Web antes de seus arquivos JS
• Compactação automática: na versão anterior do HTTP (1.1), devemos exigir explicitamente a compactação de solicitações e respostas. HTTP/2, no entanto, executa uma compactação GZip automaticamente
• Redefinição de conexão: funcionalidade que permite fechar uma conexão entre um servidor e um cliente por algum motivo, abrindo imediatamente uma nova
• Server push: para evitar que um servidor receba muitos pedidos, o HTTP/2 introduziu uma funcionalidade de server push. Com isso, o servidor tenta prever os recursos que serão solicitados em breve. Portanto, o servidor envia proativamente esses recursos para o cache do cliente
• Protocolo Binário: o HTTP/2 tornou-se um protocolo binário, substituindo as versões anteriores de texto simples do HTTP

Para mais detalhes sobre o funcionamento do HTTP, dê uma olhada neste artigo e neste vídeo onde discutimos anteriormente sobre o assunto.

O gRPC usa fluxos de dados HTTP/2 ou HTTP/2 Streams. O HTTP/2 possibilita o uso de múltiplos streams em uma única conexão TCP de longa duração.
Isso permite ao framework gRPC lidar com um elevado número de chamadas RPC simultâneas com um baixo número de conexões TCP entre clientes e servidores.

Fluxo de uso do gRPC

Para entender como o gRPC funciona, vamos percorrer um fluxo típico de um cliente gRPC para um servidor gRPC. No exemplo a seguir, o Serviço de Pedido é o cliente gRPC, e o Serviço de Pagamento é o servidor gRPC.

Quando o Serviço de Pedido faz uma chamada gRPC para o Serviço de Pagamento, ele invoca o código do cliente gerado pelo conjunto de ferramentas gRPC no momento da compilação. Esse código de cliente é chamado de stub cliente.

O gRPC codifica os dados passados para o stub cliente em Buffers de Protocolo e os envia para a camada de transporte. O gRPC envia os dados pela rede como um quadro ou frame de dados HTTP/2.

Em razão da codificação binária e da otimização de rede, é estimado que o gRPC seja 5 vezes mais rápido que o JSON.

O serviço de pagamento recebe os pacotes de rede, decodifica-os e invoca o servidor de aplicações.

O resultado retornado pelo servidor de aplicações é codificado em Buffers de Protocolo e enviado para a camada de transporte. O Serviço de Pedido recebe os pacotes, decodifica-os e envia o resultado para o aplicativo cliente.

Adoção do gRPC

Como podemos ver no exemplo de fluxo acima, em teoria o gRPC é muito fácil de implementar.
Mas se é tão fácil, por que não vemos o uso generalizado de gRPC entre clientes e servidores web?
Um dos motivos é que o gRPC depende do HTTP/2, você não pode chamar um serviço gRPC diretamente de um navegador web pois atualmente nenhum navegador moderno acessa quadros HTTP/2 e não fornecem o nível de controle necessário às requisições Web para suportar um cliente gRPC.

Alternativas para uso do gRPC na Web

É possível fazer chamadas gRPC a partir de um navegador com a ajuda de um proxy. Essa tecnologia é chamada de gRPC-Web. No entanto, o conjunto de funcionalidades do gRPC-Web não é totalmente compatível com o gRPC e seu uso deixa a desejar em comparação ao gRPC.

A maioria dos navegadores usa HTTP/1.1 como padrão, enquanto o gRPC só funciona com HTTP/2. Você pode usar serviços como nginx, envoy ou traefik para executar o HTTP/2 por trás de um proxy reverso, muito semelhante a como os websockets são frequentemente usados por trás de um proxy reverso (neste caso, o HTTP/1.1 é atualizado para uma conexão de websockets). O proxy reverso enviará a solicitação gRPC enviada como HTTP/1.1 para um backend HTTP/2 e vice-versa.

Quando utilizar gRPC?

Então, onde o gRPC se destaca e quando devemos usá-lo?

O gRPC é o mecanismo de comunicação entre microsserviços preferido pelos data centers. Seu amplo suporte a muitas linguagens de programação e idiomas permite que os provedores de serviços escolham suas linguagens preferidas e desenvolvam ecossistemas mais adequados para seus casos de uso.

Um dos maiores pontos fortes dos microsserviços em contraste com a arquitetura monolítica é a capacidade de usar tecnologias diferentes e de forma independente para cada serviço — o que for mais adequado. Os microsserviços devem ser compatíveis com a API na troca de dados, formato de dados, padrões de erro, balanceamento de carga e muito mais. E como o gRPC permite descrever um contrato de serviço em formato binário, os programadores têm uma maneira padrão de especificar esses contratos independente da linguagem e que garante interoperabilidade.

Há também o uso crescente de gRPC nos clientes móveis nativos. Sua eficiência e desempenho fazem muito sentido em ambientes com restrições de energia e largura de banda tipicamente aplicáveis aos dispositivos móveis.

Resumo

O gRPC é um framework RPC (Remote Procedure Call), moderno, de código aberto e alto desempenho que pode ser executado em qualquer ambiente. O gRPC pode conectar serviços de forma eficiente dentro e entre datacenters com suporte plugável para balanceamento de carga, rastreamento, verificação de integridade e autenticação. Também vem sendo utilizado nas etapas finais da computação distribuída para conectar dispositivos, aplicativos móveis e navegadores com serviços de backend.

Outro interessante caso de uso é a geração de bibliotecas cliente mais eficientes.

Principais cenários de uso:

• Comunicação entre microsserviços em ambientes multi-linguagem
• Conexão entre dispositivos móveis nativos
• Conexão de navegadores cliente a serviços de backend
• Geração de bibliotecas de clientes mais eficientes

Principais recursos:

• Bibliotecas em 11 idiomas
• Eficiência de rede e definição de estrutura de serviço simples
• Streaming bidirecional com transporte baseado em HTTP/2
• Autenticação conectável, rastreamento, balanceamento de carga e verificação de integridade

Quem está usando o gRPC:

• Google
• Slack
• Square
• Netflix
• CoreOS
• CockRoach Labs
• Cisco
• Juniper Networks

Conclusão

Neste artigo, falamos sobre gRPC. Exploramos sobre seu histórico, arquitetura técnica e vantagens de uso. Iniciamos contando como o framework gRPC implementa RPC (Remote Procedure Call), destacamos o uso de ProtoBuf e dependências do HTTP/2. Também destacamos os principais casos de uso e empresas estão utilizando o gRPC na entrega de seus serviços. O gRPC possui uma comunidade e ecossistemas muito competente e ativo e sua adoção caminha a passos largos para resolver problemas específicos ligados principalmente a performance.