Veja o que é um serviço gRPC, seus beneficios e vantagens. Descubra também quais foram as motivações do Google para desenvolve-lo e quais seus principios de design.

Speed by night

A Microsoft vai disponibilazr o gRPC para ASP.NET Core junto com o .NET Core 3. Veja como ele pode impactar seu dia-a-dia, quais os beneficios. Atualize e esteja preparado!

O que é

O gRPC é um serviço de alto desempenho para atender chamadas RPC (Remote Call Procedures). Open source e que pode ser executado em qualquer ambiente. Permite que o aplicativo client-server se comuniquem de forma transparente. Com suporte a load balance, tracing, health-check e autenticação. Facilitando a comunicação entre sistemas.

Suporta o protocolo Protobuf por padrão, tornando a comunicação entre serviços ainda mais eficiente. Além de suportar comunicação HTTP2 e QUIC.

Pode também utilizar outros protocolos de mensagens como JSON e XML.

RPC

O RPC é um modelo client-server. O solicitante é um client e quem fornece a informação é um serviço Server side. O RPC é uma operação síncrona e exige que o Client seja suspenso até que o resultado do Server seja retornado.

Google RPC

O Google é o criador do gRPC. O objetivo era conectar os Microsserviços em seus datacenters. O google já utiliza Microsserviços há muito tempo.

Protocol buffer

Protobuf (sigla de Protocol buffers) é um protocolo de mensagem criado e utilizado pelo Google. Para serializar dados estruturados. É agnóstico de linguagem ou plataforma. Tal como o JSON e o XML.

A transferência utilizando o protobuf chega a ser até 6 vezes mais rápido se comparado com JSON.

Beneficios

Os principais benefícios do gRPC são:

  • Estrutura RPC leve e de alto desempenho.
  • Desenvolvimento de API Contract-first, usando Protocol Buffers por padrão.
  • Ferramentas disponíveis para várias linguagens de programação.
  • Suporta chamadas streaming do client, server e bidirecionais.
  • Redução do uso de rede através da serialização do Protobuf.

Esses benefícios tornam o gRPC ideal para:

  • Ambientes com Microsserviços, pois torna a comunicação leve. Onde a eficiência é crítica.
  • Por estar disponivel em diversas linguagens torna os sistemas poliglotas. Novamente beneficiando ambientes com Microsserviços.
  • Serviços real time ponta-a-ponta que precisam lidar com solicitações ou respostas de streaming.

Princípios e Requisitos

O Google criou alguns principios e requisitos tanto para os desenvolvedores que utilizam, quanto para aqueles que implementam sua própria versão do gRPC.

  • Serviços não Objetos, Mensagens e não Referências - Promove a filosofia de design de microsserviços. Com eficiência na troca de mensagens entre sistemas. Evitando as armadilhas de objetos distribuídos e as falácias de ignorar a rede.
  • Cobertura e Simplicidade - O gRPC deve estar disponível em todas as plataformas de desenvolvimento. Deve ser fácil para um dev construir um serviço gRPC. Deve ser viável em dispositivos com CPU e memória limitada.
  • Gratuito e Open Source - Os recursos fundamentais deve ser gratuitos para todos. As funcionalidades serão sempre de dominio público, com licenciamento que deve facilitar e não impedir a adoção.
  • Interoperabilidade e Alcance - O protocolo de comunicação deve ser capaz de suportar à uma infra-estrutura comum de internet.
  • Propósito geral e Performance - O gRPC deve ser aplicável em uma grande gama de cenários. Ao passo que sacrifica muito pouco o desempenho quando comparado a uma tecnologia específica do cenário proposto.
  • Layered (Em camadas) - As principais funções da tecnologia devem ter a habilidade de evoluir de forma independente. A troca do protocolo de comunicação não deve quebrar a camada de aplicação.
  • Payload Agnostic - Serviços podem precisar usar diferentes tipos de mensagem e encode, como Protobuf, JSON, XML e Thrift. O protocolo do comunicação e as implementações devem permitir isso. Da mesma forma, a necessidade de compactação da mensagem varia de acordo com o cenário: o protocolo deve permitir diferentes mecanismos de compactação.
  • Streaming - Sistemas de storage dependem de streaming e de controle de fluxo para expressar grandes conjuntos de dados. Outros serviços, como voice-to-text ou stock-tickers, dependem de streaming para representar mensagens temporalmente relacionadas.
  • Blocking & Non-Blocking - Deve suporta o processamento síncrono e assíncrono das mensagens trocadas por um client-server. Isso é crítico para escalabilidade e lidar com streams em determinadas plataformas.
  • Cancellation & Timeout - As operações podem ser pesadas ou demorar no processamento - Com especificações de cancelamento permite que os servidores recuperem recursos quando os client são bem desenvolvidos. O cancelamento pode ocorrer em cascata. Um client pode indicar um tempo limite para uma chamada. Permitindo que os serviços ajustem seu comportamento às necessidades do cliente.
  • Lameducking - Os servidores devem ter a permissão de desligar, rejeitando novas solicitações, enquanto continuam processando os pedidos em andamento.
  • Controle de Fluxo - O poder de computação e a capacidade de rede são frequentemente desequilibrados entre client e server. O controle de fluxo permite um melhor gerenciamento de buffer, além de fornecer proteção DOS.
  • Pluggable - Um protocolo de comunicação é apenas uma parte da infraestrutura. Grandes sistemas distribuídos precisam de segurança, health check, load balance e failover, monitoramento, tracing e logs, etc. As implementações devem ser extensiveis. Permitindo que o desenvolvedor escolha os componentes desses recursos e, quando útil, implementações padrão.
  • Extensões como APIs - Extensões que exigem colaboração entre serviços devem fazer o uso de APIs em vez de extensões de protocolo, sempre que possível. Extensões desse tipo podem incluir health check, load balance, service introspection e load monitoring.
  • Metadata Exchange - Conceitos comuns de cross-cutting, como autenticação ou trace, dependem da troca de dados que não fazem parte da interface de um serviço. Os deploys dependem de sua capacidade de evoluir esses recursos a uma taxa diferente das APIs expostas pelos serviços.
  • Códigos de status padronizados - Os clients geralmente tratam erros retornados por chamadas de API. O namespace do status code deve ser restrito para tornar o gerenciamento de erros mais claro. Se for necessário um status de erro específico do domínio, o metadados da mensagem pode ser utilizado.

O conteúdo original estará nas referências

Conclusão

O gRPC é mais um aliado na construção de APIs. O foco é a comunicação entre serviços. Por ser agnóstico promete boa adoção em ambientes com Microsserviços.

Espero que este artigo tenha te ajudado a entender mais sobre o gRPC!

Referências