Por que você deveria utilizar mensageria na sua aplicação

Por Capa, Dicas, Ferramentas, Tecnologia

Por que você deveria utilizar mensageria na sua aplicação

Por que você deveria utilizar mensageria na sua aplicação

No atual cenário de arquitetura de software, existem pelo menos 2 paradigmas comuns para resolver a comunicação entre diferentes serviços: síncrona e assíncrona. A primeira forma de comunicação pode ser implementada utilizando o modelo mais comum de chamadas entre serviços que é a troca de requisições HTTP. A segunda, por sua vez, é mais frequentemente implementada utilizando brokers de mensageria.

Ambos padrões de comunicação apresentam seus prós e contras – e é sobre esses tradeoffs que a gente vai falar um pouquinho aqui.


Por que você deveria utilizar mensageria na sua aplicaçãoComunicação síncrona: modelo HTTP convencional

O protocolo HTTP está entre nós há décadas e, portanto, no mundo do desenvolvimento de software, ele já é amplamente conhecido e é basicamente a peça fundamental para o acesso a todo tipo de conteúdo na internet.

mensageria na sua aplicaçãEntre os prós que o modelo de comunicação entre serviços síncrono usando HTTP pode oferecer, podemos destacar:

  • Facilidade de implementação;
  • Atende bem grande parte dos cenários de comunicação entre serviços que não demandam uma alta taxa de concorrência;
  • Possui um universo vasto de documentação, bibliotecas e exemplos para se inspirar e implementar.

Por outro lado, como pontos de atenção, vale citar:

  • De maneira geral, não é um modelo que escala para altos níveis de concorrência ( > 1K TPS, por exemplo);
  • Exige implementação de retentativas por parte de quem envia uma requisição;
  • Por padrão, é síncrono, portanto, caso haja degradação do lado que recebe a comunicação, o fluxo todo pode ser interrompido.

Mas, felizmente, há alternativas para todo mundo ficar feliz 😉


Por que você deveria utilizar mensageria na sua aplicaçãoComunicação assíncrona: utilizando eventos e mensageria

Neste modelo, entra em cena uma estrutura independente das aplicações: os brokers de mensageria.

Esse tipo de middleware oferece estruturas de comunicação e dados que permitem que diferentes serviços conversem entre si de forma assíncrona, segura, replicada e altamente tolerante a falhas.

mensageria na sua aplicaçãoExistem diversas soluções comerciais e opensource que provêm deste tipo de estrutura: IBM MQ, Rabbit MQ, Active MQ e, o nosso favorito e sobre o qual vamos falar mais, o Apache Kafka.

Nesse paradigma de comunicação – e especificamente no Apache Kafka – existem alguns conceitos básicos muito importantes:

  • Brokers -> componentes do cluster de mensageria, que permitem a comunicação com os serviços, armazenam, replicam e fornecem toda garantia de integridade dos dados.
  • Tópicos -> estruturas de dados que armazenam as mensagens produzidas e consumidas por serviços. Eles são criados de forma a fazerem sentido para a vida real como, por exemplo, tópico para eventos de compras em um e-commerce e novos pedidos em um aplicativo de delivery. Muitos chamam os tópicos de filas, mas isso fica para outro post!
  • Produtores -> serviços que produzem mensagens no broker, indicando que um novo evento aconteceu. Seguindo o exemplo usado nos tópicos, o serviço de checkout de um e-commerce pode produzir eventos com mensagens a cada nova compra realizada numa loja on-line.
  • Consumidores -> serviços que consomem mensagens no broker, iniciando um novo fluxo de processos de acordo com a sua missão. Um exemplo pode ser um serviço de ordem de produção, que consome eventos produzidos pelo checkout de um e-commerce, dando início ao processo e, ainda pode produzir um novo evento para outros serviços realizarem atividades específicas como produção, logística, fiscal. E, já respondendo a dúvida que acabou de pipocar na sua cabeça, serviços podem sim ser produtores e consumidores de diferentes tópicos!

Mas quais os prós de utilizar o Apache Kafka ou uma solução semelhante?

  • Por natureza, o cluster de mensageria é assíncrono, distribuído e escalável, tornando-o tolerante a falhas.
  • Permite uma enorme visibilidade do fluxo, devido à forma como se organizam os tópicos e às métricas que são coletadas.
  • Diferentes times podem consumir os mesmos eventos para gerar diferentes informações. Por exemplo, times de operações podem consumir eventos de pedidos para medir throughput na plataforma e graficar possíveis gargalos, times de big data podem consumir os mesmos eventos para gerar insights de negócios e, claro, os times de dev consomem os eventos que foram originalmente direcionados a suas aplicações para dar andamento nos fluxos dos processos.
  • Pode-se integrar eventos gerados em outras fontes de dados, como bancos relacionais, sensores de IoT etc.

Só que nada é perfeito, não é mesmo?

Então, um dos principais contras desse tipo de arquitetura é justamente a entrada de novos componentes de infraestrutura – como servidores e storage – para atender o cluster de mensageria e, como consequência, o custo do seu projeto pode ter um incremento que precisa ser considerado.

E aí, como está a arquitetura da sua aplicação e qual modelo de comunicação você utiliza?


Leia também: O que é IaC (Infrastructure as Code)?


Autor


Guilherme Ribeiro
Guilherme Ribeiro

Senior professional working on IT since 1999 and currently working as IT Operations Lead, I have experience in private and public cloud infrastructure, automation, provisioning and scaling. Also have advanced skills in application performance, monitoring and metrics. In 21 years of IT experience, I have 10 years background as front and backend software developer and another 11 as system administrator. My current mission is to lead IT Operations and Platform Workloads at Dinamize - a first class player in Marketing Automation in Brazil. Monitoring, infrastructure automation, performance and software architectute are my highest level skills. I'm absolutely optimistic, friendly and I love to code in Golang + InfluxDB and broadcast that to everyone.

Veja conteúdos do Autor