Autor: Rodrigo G. Tavares
Veja a Parte 2: O que é gRPC - Como usar os Protocol Buffers
Nem tudo são APIs Rest quando falamos de comunicação entre aplicações.
Introdução
Pensando em reduzir a latência e otimizar a comunicação nas aplicações atuais, o Google criou o sistema gRPC, que é uma implementação do modelo RPC.
No gRPC são usados proto buffers para definição das funcionalidades e a comunicação é feita usando o protocolo HTTP/2.
Nessa série de artigos veremos todos os detalhes do sistema gRPC: Seus principais componentes, funcionamento, pra que serve, onde e como usar.
Lembrando que essa aqui é só a primeira parte!
Nessa série além de vermos os detalhes do sistema gRPC, ao fim faremos uma implementação passo a passo, usando gRPC com Java e Spring Boot.
Componentes do gRPC
Antes de falarmos de gRPC, precisamos entender dois dos seus principais componentes.
Modelo RPC
O RPC, Remote Process Call, como o próprio nome diz, é uma padronização para execução de funcionalidades remotas simulando uma função local, ou seja, isso simplifica muito as integrações entre sistemas.
Também podemos dizer que na maioria dos casos, o RPC está relacionado à interoperabilidade, isso quer dizer que utilizando uma IDL, Interface Definition Language, podemos especificar uma ou mais funcionalidades detalhando seus tipos, parâmetros e retornos. Isso permite a interpretação dessas instruções por qualquer linguagem de programação.
Em resumo, o intuito da interoperabilidade é justamente garantir que programas escritos em linguagens de programação distintas possam se comunicar.
Padrão CORBA
Uma das mais antigas implementações de RPC é o CORBA, Common Object Request Broker Architecture, que simplificando, consiste na implementação de um módulo chamado ORB, responsável pela comunicação entre clientes e o servidores.
Java RMI
Em Java a implementação mais famosa do RPC é o RMI, sigla em inglês para Remote Method Invocation.
O RMI é a base do famoso Enterprise Java Beans, também conhecido como EJB.
Sua implementação requer a criação de stubs, que são um conjunto de interfaces que definem as assinaturas dos métodos, parâmetros e retornos.
Depois de criarmos os stubs, eles são implementados do lado do servidor e distribuídos em uma biblioteca para todos os clientes que invocarão os métodos remotos.
Uma informação interessante, é que no caso do RMI não há uma IDL para criação dos stubs, eles são escritos na própria linguagem, então isso quer dizer que o foco não é a interoperabilidade e sim a integração entre sistemas distribuídos feitos em Java mesmo.
SOAP
Por último e provavelmente a implementação RPC mais conhecida de todas, amplamente utilizada pelas mais diversas linguagens, vamos falar do modelo SOAP, Simple Object Access Protocol.
Exemplo de contrato WSDL da Nota Fiscal Eletrônica
Nesse modelo usamos o padrão WSDL, Web Services Description Language, que usando instruções por meio de tags e atributos XML, define o contrato do serviço.
Esse contrato é composto pelos tipos de dados, funcionalidades, parâmetros e retornos.
Para fazer a comunicação com os clientes, é usado protocolo http ou https, e pra acessar os métodos remotos no padrão SOAP, as linguagens fazem a interpretação do contrato WSDL, gerando as interfaces stubs com seus parâmetros para entrada e retorno.
Uma vez gerados, os stubs são distribuídos para os clientes que queiram invocar as funcionalidades SOAP remotas.
Agora que entendemos o que é RPC e vimos alguns exemplos, percebam que todas as implementações citadas acima precisam distribuir algum tipo de biblioteca para os clientes.
Guarda essa informação pois vamos precisar dela adiante.
Protocolo de comunicação
O gRPC utiliza o protocolo HTTP2 para comunicação, mas para entendermos melhor o motivo pelo qual precisamos dele, veremos os déficits do protocolo HTTP/1.x.
O que falta no HTTP/1.x
A definição do protocolo HTTP/1.x é muito simples e essa simplicidade tem um preço, que é redução do desempenho das aplicações.
A perda de desempenho acontece devido ao protocolo HTTP/1.x não ter compactação de dados e da impossibilidade de priorizar os recursos.
Normalmente são necessárias várias conexões simultâneas para completar uma requisição que atenda o negócio.
Lá no começo isso não fazia diferença nenhuma e o protocolo HTTP/1.x atendia muito bem os seus propósitos, só que hoje, a complexidade das aplicações modernas, precisando de cada vez mais recursos, contornar os problemas de latência é um grande desafio para os desenvolvedores.
O Protocolo HTTP2
O protocolo HTTP2 foi criado pelo Google e aprovado no início de 2015 pelo IESG, Grupo de Gestão de Engenharia para Internet, e ele é uma evolução de um protocolo experimental chamado SPDY, também criado pelo Google.
A primeira grande melhoria do protocolo HTTP2, é o formato dos dados transmitidos.
Enquanto o HTTP/1.x usa o formato de texto simples para comunicação, o protocolo HTTP2 usa um formato binário compactado e isso reduz drasticamente o tamanho da requisição e resposta.
Comunicação com HTTP2
A comunicação do protocolo HTTP2 é dividida em três partes:
- Stream;
- Mensagem;
- Frame.
O Stream
Em uma mesma conexão TCP/IP podemos trafegar diversos streams e eles são bidirecionais, ou seja, por eles podemos tanto enviar mensagens como receber sem que seja necessário desconectar. Muito diferente do protocolo HTTP/1.x que só aceita uma requisição e uma resposta por conexão.
A Mensagem
É sequência completa de uma requisição e ela transita dentro do stream.
Como eu já mencionado anteriormente, o protocolo HTTP2 permite a troca de diversas mensagens dentro de um stream e essas mensagens são divididas em frames.
Os Frames
Por fim temos os frames, eles são a menor parte e compõem a mensagem. Nos frames temos informações dos cabeçalhos e os dados de requisição e resposta.
Recapitulando
- Uma mesma conexão pode transferir vários streams;
- Dentro de cada stream podemos ter várias mensagens;
- Essas mensagens são divididas em frames;
- Os frames transitam os dados efetivos da requisição.
Vimos até aqui, quais são os componentes de comunicação do protocolo HTTP2, agora veremos algumas vantagens de desempenho importantes que ele tem.
Múltiplas requisições
No protocolo HTTP/1.x, se quisermos fazer solicitações paralelas para minimizar a latência, é necessário efetuar várias conexões simultâneas.
Quando usamos os frames binários do protocolo HTTP2, temos o que chamamos de multiplexação completa de requisição e respostas, que basicamente é a capacidade do protocolo fazer requisições simultâneas, síncronas e assíncronas usando a mesma conexão.
Além disso também é possível alternar entre as requisições sem bloqueá-las.
Essa requisição elimina o custo de efetuar novas conexões e tudo isso permite a redução da latência geral, otimizando a utilização da rede.
Priorização de Stream
Outro avanço importante do protocolo HTTP2 é a possibilidade de alterar a prioridade dos streams.
Esse processo e feito atribuindo um número inteiro entre 1 e 256 a cada stream.
No protocolo HTTP2, você também pode atribuir uma dependência entre os Streams, ou seja, você poderia por exemplo dizer explicitamente que em uma requisição, a imagem B só será baixada depois da imagem A e isso sem a necessidade de efetuar uma nova conexão.
O que vem a seguir?
Pronto, agora que já entendemos os componentes base do sistema gRPC, podemos seguir para o próximo artigo onde veremos o funcionamento do Protocol Buffer, que é a linguagem usada pelo gRPC como IDL pra definição de funcionalidades, parâmetros e retornos.
Veja a Parte 2: O que é gRPC - Como usar os Protocol Buffers
E se você chegou até aqui, deixe o seu gostei no artigo e já aproveita pra seguir o canal ExpertosTech em todas redes sociais:
https://linktr.ee/expertostech
Referencias:
- Wikipedia
- Google Developers
- Receita Federal
Top comments (0)