0

Conhecendo o RabbitMQ

Gabriel Faraday
Gabriel Faraday

Existem situações que queremos dar mais resiliência ao software, ou queremos tratar algum processo de forma assíncrona, ou queremos “disparar um evento” após alguma ação na aplicação para notificar outras aplicações que queiram se beneficiar da informação de que aquele dado evento ocorreu. Para isso é comum utilizarmos um Message Broker.


Isso é bem comum, na verdade, no mundo de micro serviços e essas práticas são conhecidas como mensageria.


Segundo https://www.ibm.com/cloud/learn/message-brokers, um message broker é “um software que permite que aplicativos, sistemas e serviços se comuniquem entre si e troquem informações”. Ainda complementa que o message broker “faz isso traduzindo mensagens entre protocolos de mensagens formais. Isso permite que serviços interdependentes “falem” uns com os outros diretamente, mesmo que tenham sido escritos em linguagens diferentes ou implementados em plataformas diferentes”.


Em outras palavras, o message broker permite a troca de informações entre sistemas, geralmente essas informações serão enviadas e recebidas em formato json, estruturando um objeto com informações, mas isso não é uma regra.


Existe uma série de padrões que podem se utilizar de um message broker, dentre eles os conhecidos patterns Event Notification, Event-Carried State Transfer e Event-Sourcing, mas não iremos entrar a fundo neles neste artigo. Caso queira saber mais sobre, recomendo este artigo do Martin Fowler: https://martinfowler.com/articles/201701-event-driven.html


Existem diversas ferramentas de message broker no mercado, dentre elas Azure Service Bus, Apache ActiveMQ, Apache Kafka, Mosquitto, Google Cloud Pub/Sub, AWS SQS, mas hoje iremos falar da talvez mais famosa e utilizada delas, o RabbitMQ!


O RabbitMQ pode se utilizar de alguns protocolos de comunicação, mas o mais comum é o AMQP, que é o protocolo mais utilizado para mensageria.


Sendo assim, teremos um Produtor, que é uma dada aplicação, que envia ao broker uma Mensagem.


Essa mensagem entra numa espécie de “fila”, onde outras mensagens do mesmo tipo estão aguardando para serem processadas.


Existe do outro lado um ou mais Consumidores, que irão consumir as mensagens desta “fila” no broker. Os consumidores são outras aplicações que pegam a mensagem e após processá-la dão um OK ao broker para que este possa eliminar a mensagem.



O interessante é que se o consumidor não der um OK, a mensagem poderá voltar para a “fila” e ser consumida por outro consumidor. Isso faz com que eu crie resiliência e possa chegar ao ponto de garantir que uma mensagem será processada.


Obviamente esta garantia depende de uma série de fatores e configurações no broker e nas aplicações envolvidas.


Subindo um RabbitMQ com Docker


Para utilizar o RabbitMQ você pode instalar ele e configurar na sua máquina, mas a forma mais fácil de subir um RabbitMQ, seja para estudo ou testes, é através do Docker.


Precisamos ter o Docker instalado e se você não conhece Docker, sugiro que veja meu artigo sobre o assunto:

https://digitalinnovation.one/artigos/conhecendo-o-docker


Para subirmos o RabbitMQ, teremos basicamente 2 serviços:

  • O RabbitMQ em si
  • Uma ferramenta de administração, onde será possível interagir e configurar o RabbitMQ


Basta executar o seguinte comando na command line e teremos os 2 serviços executando:


docker run --rm --name rabbitmq -p 5672:5672 -p 15672:15672 rabbitmq:3-management


Aqui estamos dizendo ao docker: rode um container da imagem rabbitmq:3-management (que está no docker hub) e link a porta 5672 do container com a porta 5672 do host (aqui acessaremos o RabbitMQ em si) e link a porta 15672 do container com a porta 15672 do host (aqui acessaremos a ferramenta admin). O “-rm” é usado para dizer ao docker limpar automaticamente o container e remover o sistema de arquivos quando o container finalizar.


Pronto, em poucos segundos temos um server de RabbitMQ de pé em nossa máquina:



E conseguimos acessar nossa ferramenta de admin via browser http://localhost:15672



Por padrão o username e a senha são “guest”. Ao fazer o acesso será exibido um alerta sobre alterar essa senha, mas não se preocupe, estamos apenas estudando!



Ao acessar o admin, vemos algumas coisas interessantes e que valem ser comentadas:


  • O RabbitMQ é opensource e é desenvolvido em Erlang. No topo da página é possível ver tanto a versão do RabbitMQ em si quanto do Erlang utilizada.
  • A primeira aba de Overview nos mostra informações gerais sobre nosso server RabbitMQ
  • A aba de Connections mostrará posteriormente as conexões abertas com nosso RabbitMQ
  • A aba Channels mostrará posteriormente os channels abertos com nosso RabbitMQ. E aqui cabe uma explicação: o ideal é que cada aplicação ao utilizar o RabbitMQ abra uma única connection e reutilize a mesma em todo seu ciclo, porém é possivel ou até necessário que channels separados sejam utilizados dependendo do caso. Entenda o channel como uma repartição dentro de uma connection.
  • A aba Exchanges mostra as exchanges, que são como portas de entrada para as filas. Existem tipos diferentes de exchanges, que direcionam para uma única fila, ou que direcionam a mensagem para múltiplas filas e aí pode ser com base em um header na mensagem ou com base em um padrão textual, enfim, caberia um artigo só para falar de exchanges e seus tipos, mas é um dos pontos cruciais a se entender no RabbitMQ, pois elas te darão ferramentas certas para cada situação
  • A aba Queues mostra as filas, que são onde as mensagens são entregues pelas exchanges para aguardarem serem consumidas e é de onde as aplicações Consumidoras irão pegar as mensagens
  • A aba Admin traz diversas funcionalidades de administração do server, como gestão de usuários, de limites, de políticas, etc


Para finalizar o nosso server RabbitMQ, basta pressionar Ctrl+c na janela da command line que ele está rodando e depois rodar o comando docker stop para o nosso container (já explicado como fazer no artigo de Docker https://digitalinnovation.one/artigos/conhecendo-o-docker).


Atenção: como usamos a diretiva “-rm” ao subir o container, automaticamente o container será limpo. E quando um container é encerrado, qualquer coisa que tínhamos criado será removida também. Para evitar que isso aconteça, podemos usar “volumes” no docker, mas isso é assunto para outro artigo.


Recapitulando


Ferramentas de message broker permitem aplicarmos práticas de mensageria, que são bastante úteis em diversos cenários, principalmente em casos com micro serviços.


O RabbitMQ é um dos principais message brokers no mercado atualmente, que apesar de parecer ser muito complexo, vimos que ele possui poucos conceitos e que pode ser facilmente utilizado em conjunto com Docker.



0
0

Comentários (4)

0
Airam Almeida

Airam Almeida

07/04/2021 09:17

Show Gabriel, Obrigado por compartilhar, vou botar aqui na fila pra testar!!! Sucesso!!!

0
Isaias Bueno

Isaias Bueno

07/04/2021 08:17

Ótimas dicas/ensinamentos como sempre! Muito obrigado Gabriel!

0
Alexsander Rossi

Alexsander Rossi

06/04/2021 12:50

Excelente artigo manão, de noite vou testar aqui top demais!

1
Rosemeire Deconti

Rosemeire Deconti

06/04/2021 12:05

Adorei o artigo! Para variar mais um item importante para a minha caixa de ferramentas! Agradecida por compartilhar!