Vamos começar? Que tal de fato olharmos para o RabbitMQ para nos acostumarmos com ele, e dar vida ao que falamos até agora?
Subindo RabbitMQ com docker
Há diversas formas de subir uma instância do RabbitMQ, uma delas é com Docker, e está aqui um exemplo com Docker Compose. A propósito, ela vem do tutorial sobre EnterpriseApplicationLog, que citei no post Don’t Do That – Forçar IP’s nos Containers Docker.
version: '2.3'
services:
rabbitmq:
container_name: RabbitMQ
image: rabbitmq:3-management-alpine
volumes:
- mq_data:/var/lib/rabbitmq/mnesia
ports:
- "15672:15672"
- "5672:5672"
networks:
- log
environment:
RABBITMQ_DEFAULT_USER: logUser
RABBITMQ_DEFAULT_PASS: logPwd
RABBITMQ_DEFAULT_VHOST: EnterpriseLog
volumes:
mq_data:
networks:
log:
driver: bridge
Esse é um docker-compose.yaml, basta rodar docker-compose up e seu ambiente nasce!
Não entendeu nada? Bom, então vou te ajudar: Que tal dar uma olhada na série sobre Docker que fiz aqui no site?
Acessando seu RabbitMQ pela primeira vez
Vamos acessar seu RabbitMQ usando o endereço http://localhost:15672/ no navegador. Use o usuário logUser e senha logPwd.
Uma vez que tenhamos uma instância do RabbitMQ no ar, podemos agora montar uma estratégia de uso. Nesse exemplo temos o vhost EnterpriseLog mas poderia ser qualquer outro, inclusive o default.
Você verá algo assim:
Percorra todas as tabs para se ambientar. Poste suas dúvidas, nos comentários do post.
Você deve ter percebido que nas Exchanges aparecem algumas exchanges padrão por lá, né?
São 7 exchanges default. Eu já falei sobre isso, mas vale lembrar. O motivo de você achar que envia uma mensagem para uma fila, e exatamente pela existência dessa exchange (AMQP default). Essa exchange possui o papel de fazer você achar isso.
Criando os primeiros recursos
Eu criei aqui, via a interface de gerenciamento do RabbitMQ uma exchange, duas filas e associei ambas com um binding com uma routing key.
- Exchange: Exchange1
- Type: Topic
- Durability: Durável
- Auto delete: Não
- Internal: Não
- Fila: Fila1
- Durável: Sim
- Auto delete: Não
- Fila: Fila2
- Durável: Sim
- Auto delete: Não
Configurei o binding associando exchange e filas assim:
- Exchange1
- Fila1 – Routing Key a
- Fila2 – Routing Key b
- Fila1 – Routing Key c
- Fila2 – Routing Key c
Eu usei essa estratégia para mostrar mensagens que vão apenas para uma fila e mensagens que vão para diversas filas. A Routing Key de uma Exchange do tipo Topic determina a distribuição. Cada tipo de exchange possui um comportamento específico.
Note que não há um json, ou um objeto, apenas um texto. É assim que funciona, você escolhe a melhor estratégia para encoding da mensagem, pois o conteúdo é irrelevante para o RabbitMQ. O que importa são os cabeçalhos, pois são eles que determinam como as rotas funcionarão e podem inclusive permitir que sua infraestrutura trabalhe com diversos tipos de formato para a mesma mensagem (imagine um caso em que você tem a mesma mensagem sendo enviada com formato json, bson e xml).
Você tem o controle sobre isso e trabalha da forma que melhor lhe atender. Texto simples também é uma possibilidade, incomum, mas é possível.
Conclusão
Embora seja extremamente simples, talvez até por isso gere confusão, RabbitMQ oferece um modelo de escalabilidade para suas aplicações de forma extremamente robusta. O profissionalismo com soluções assim, mudam de patamar e podemos de fato pensar em escala horizontal. Nunca vi alguém se arrepender de adicionar RabbitMQ em uma solução. É uma solução robusta, simples, especialista, que poupa muito trabalho. A entrega única de mensagem entre outras features como as Exchanges que abstraem as rotas pra filas, são seus pontos fortes que dão imensa flexibilidade.
Essa série poderia ser resumida em um post, mas separar em doses menores lhe permite entender melhor como cada coisa funciona, como os pontos se conectam. Já vi muita gente falar besteira por mero desconhecimento, e também já vi muita gente tomando decisões erradas por medo, receio, e puro desconhecimento.
No próximo post vamos mostrar algo mais programático.
0 comentários