Olá pessoal hoje iremos falar sobre mensageria utilizando RabbitMQ, iremos passar por conceitos e por alguns casos de uso dessa poderosa ferramenta.
 |
O que é o RabbitMQ
O RabbitMQ é um message broker muito utilizado quando falamos de mensageria, é uma ferramenta construída em Erlang, possui drivers para diferentes tecnologias (Java, C#, Golang, etc), além de contar com um grande número de usuários e empresas que a utilizam.
Suas principais características são:
- Recebimento de mensagens;
- Resiliência de mensagens;
- Roteamento de mensagens.
Diferença entre Message Broker e Event Stream
É muito comum vermos discussões sobre Eventos x Mensagem, ou Apache Kafka vs RabbitMQ, mas será que as ferramentas são concorrentes ? Como podemos chegar a uma conclusão ?
Características do RabbitMQ:
- Possui lógicas para roteamento de mensagens;
- As mensagens não possuem retenção após o consumo;
- Mensagens são consumidas apenas uma vez, por Queue;
- Muito utilizado em regras de negocio que envolvam lógicas complexas;
- Implementação de regras de DLQ direto no broker.
Características do Apache Kafka:
- Retenção de eventos;
- Projetado para altos volumes de dados;
- Alta escalabilidade;
- Ordem de consumo por partição;
- Regras de DLQ deve ser feitas nos consumidores.
Para um exemplo prático, vamos imaginar um cenário onde temos 5 diferentes sistemas que precisam consumir um determinado evento/mensagem, abaixo vamos analisar como seriam as implementações utilizando RabbitMQ e Apache Kafka:
RabbitMQ
No RabbitMQ devemos criar 5 Queues, sendo uma cada consumidor (sistema), também teríamos uma Exchange do tipo Fanout (veremos mais detalhes), onde o produtor envia uma mensagem a Exchange, e esta irá distribuir as mensagens entre todas as Queues.
Apache Kafka
Com Apache Kafka poderíamos ter um único Topic corretamente redimensionado em partições para receber os eventos, e para os sistemas consumidores teríamos Consumer Groups, onde cada sistema pertenceria a um Consumer Group distinto.
Este é apenas um exemplo para ilustrarmos uma forma de atender a um mesmo requisito usando ferramentas com conceitos distintos.
Detalhando o RabbitMQ
Agora vamos passar pelos principais pontos do RabbitMQ, que são os seus componentes internos.
Broker
O broker é uma instância de um serviço RabbitMQ, eles podem trabalhar em um cluster, inclusive essa é uma prática recomendada, porque em casos de falhas em um dos nodes, outros podem continuar trabalhando evitando assim uma indisponibilidade do serviço.
 |
| Interface inicial RabbitMQ. |
Queue
Com certeza as queues são os itens mais famosos do RabbitMQ, porque são onde as mensagens são retidas, as mensagens são armazenadas de forma sequencial e as retiramos da mais antiga para a mais nova.
Uma mensagem também pode possuir Headers, estes são importantes no momento do consumo para identificar qual o tipo de dados estamos lidando.
 |
| Interface administrativa para manipular Queues. |
Algumas configurações são muito importantes, tais como abaixo:
- Durability: Garante que em caso de restart do broker, a Queue continuará existindo;
- Auto expire: Quando não estiver sendo utilizada, define por quanto tempo uma Queue ainda ficara ativa antes de ser deletada.
Exchange
Uma Exchange é basicamente um roteamento para onde o produtor envia as mensagens, este contém lógicas que determinam para qual Queue a mensagem será encaminhada, dentro de um Exchange temos alguns itens importantes:
- Durability: Similar a Queue, garante que em caso de restart do broker, a Exchange continuará existindo;
- Internal: Marca um Exchange como uso interno, ou seja, um produtor não pode enviar mensagens para este roteamento;
- Type: Define o tipo da Exchange (veremos detalhes dos principais tipos).
 | |
|
Tipos de Exchange
Direct
As Direct são as mais utilizadas e as mais comuns, vamos listar algumas características:
- Distribuem mensagens para mais de uma Queue;
- Podem conter regras de distribuição de mensagens (Binding Keys);
- É o tipo default, em caso de não especificar.
Conforme mencionado, as Binding Keys são configurações que determinam para qual Queue uma mensagem deve ser entregue, isto torna a Exchange similar a um roteador de mensagens, onde as mensagens só serão entregues para quem atenda ao mapeamento, em resumo seria:
"Quando uma mensagem chegar com a Binding Key X encaminhe a mensagem para a Queue Y".
 |
| Exchange envia-notificacao binding com queue_sms e key sms. |
Para ilustrar, vamos simular um caso de uso de envio de mensagens, onde temos a necessidade de enviar uma mensagem para um usuário utilizando SMS, E-mail ou Whatsapp, e caso não seja especificado o canal, deve-se mandar por Whatsapp, este caso de uso ficaria da seguinte forma:
 |
| Desenho da solução para atender aos requisitos. |
Criamos os seguintes componentes:
- Exchange envia-notificacao do tipo Direct
- Binding com a Queue: queue_sms
- Routing Key: sms
- Binding com a Queue: queue_email
- Routing Key: email
- Binding com a Queue: queue_whatsapp
- Sem Routing
- Queues queue_sms, queue_emails e queue_whatsapp
Dessa forma temos os cenários de testes cobertos:
- Caso a mensagem tenha Key sms, a mensagem será entregue a Queue: queue_sms;
- Caso a mensagem tenha Key email, a mensagem será entregue a Queue: queue_email;
- Caso a mensagem não tenha uma Key, a mensagem será entregue a Queue: queue_whatsapp.
Aqui conseguimos atender ao caso de uso, utilizando recursos da alguns recursos do tipo Direct.
Fanout
Um outro tipo de Exchange é a Fanout, esta é mais simples que a Direct, porque toda mensagem que chegar deve ser entregue a todas as Queues associadas a Exchange, resumindo seria:
"Quando chegar uma mensagem encaminhe para todas as Queues associadas".
Como exemplo, vamos analisar um caso de uso de geração de pedidos, temos a necessidade que ao gerar um novo um pedido, os microsserviços de estoque e pagamentos sejam notificados, portanto, teríamos o seguinte desenho:
 |
| Desenho da solução para atender aos requisitos. |
Criamos os seguintes componentes:
- Exchange gerar-pedidos do tipo Fanout
- Binding com a Queue: queue_estoque
- Binding com a Queue: queue_pagamentos
- Queues queue_estoque e queue_pagamentos
Quando chegar uma mensagem na Exchange(Fanout) gerar-pedidos, a mensagem será distribuída a todos as Queues associadas (queue_estoque e queue_pagamentos), portanto, os microsserviços que as consomem receberiam as mensagens contendo os dados do novo pedido, atendendo assim ao requisitos propostos.
Ferramentas para RabbitMQ
RabbitMQ Simulator
O RabbitMQ Simulator é uma ferramenta online que permite modelar sua arquitetura de mensagens e validar seu funcionamento, com ela podemos simular um cenário completo envolvendo Queues, Exchanges, Consumer, Producers, Keys, etc.
Executando o RabbitMQ
A Instalação do RabbitMQ é tranquila, caso queria executar da maneira convencional, basta seguir as instruções do site oficial, ou também podemos utilizar Docker/Docker-compose como abaixo:
version: '3.7'
services:
rabbitmq:
image: rabbitmq:3-management
ports:
- 15672:15672
- 5672:5672
environment:
RABBITMQ_DEFAULT_USER: admin
RABBITMQ_DEFAULT_PASS: admin
networks:
- rabbitmq
networks:
rabbitmq:
docker-compose.yml
Para executar basta realizar o seguinte comando:
docker-compose up -d
Outras Ferramentas
As Ferramentas que lidam com mensagens ou eventos, se tornaram muito populares nos dias atuais, isto se deve a evolução das arquiteturas (Microservices, BigData, etc), e também a problemas complexos como Escalabilidade, Performance, Acoplamento, Comunicação, entre outros.
Abaixo vamos listar algumas opções de ferramentas que lidam com mensagens e eventos, vale ressaltar que escolher a ferramenta correta não é uma tarefa simples, mas podemos partir dos pontos abaixo:
- Entendimento do negocio;
- Entendimento do problema;
- Testes das ferramentas;
- Requisitos não funcionais;
- Suporte;
- Comunidade/profissionais que tenham domínio;
- Custos.
Ferramentas disponíveis:
Comentários
Postar um comentário