Forem: Vitor Araujo

Introdução à Mensageria com RabbitMQ (Parte 1 – Conceitos)

Vitor Araujo — Wed, 10 Sep 2025 03:44:14 +0000

Ao final deste artigo, espera-se que você seja capaz de:

Definir mensageria e entender seu objetivo;
Explicar a relação entre mensageria, sistemas de mensagem e um message broker;
Identificar os componentes fundamentais de um sistema de mensagem;
Reconhecer e diferenciar os termos message broker, producer, consumer, exchange, queue, binding, listener, mensagem e topologia;

Introdução

Quando navegamos na Internet, realizamos constantemente trocas de informações: recebemos o conteúdo de um site, enviamos dados por meio de formulários ou acionamos serviços ao clicar em botões.

Em determinadas situações, a prioridade é a velocidade da transmissão, mesmo correndo o risco de perda de pacotes.

Por exemplo, em videoconferências, para garantir comunicação em tempo real, voz e vídeo são enviados via protocolo UDP, que não assegura a entrega íntegra dos pacotes, o que pode resultar em queda de qualidade de imagem ou distorções de áudio.

Já em outras situações, como em arquiteturas de microsserviços, a prioridade é garantir a entrega da informação de um serviço ao outro e é nesse ponto que a mensageria ganha destaque.

O que é mensageria, sistema de mensagem e message broker?

O termo Mensageria é utilizado para descrever o processo de comunicação entre sistemas, componentes de software ou serviços através do envio e recebimento de mensagens.

Ao utilizarmos esse termo, não estamos fazendo referência a uma ferramenta específica mas sim ao mecanismo que possibilita a comunicação síncrona ou assíncrona entre sistemas distribuídos.

As mensagens enviadas e recebidas são blocos de dados (geralmente binários ou em formatos como JSON) definidos pelo desenvolvedor.

Para implementar essa comunicação em um sistema real, precisamos de uma infraestrutura capaz de aplicar esse mecanismo na prática.

E é aí que entra o sistema de mensagem que oferece recursos para:

Criação, transmissão, armazenamento e entrega de mensagens entre aplicações
Protocolos de transporte (AMQP, MQTT, STOMP)
APIs e SDKs para produção e consumo
Suporte a filas, tópicos e roteamento.
message broker

Como exemplo de sistema de mensagens, temos o RabbitMQ que suporta os protocolos AMQP, MQTT e STOMP. E também possui um message broker, componente responsável por receber, armazenar e encaminhar as mensagens entre os produtores e consumidores.

Na imagem abaixo, temos a interface visual do RabbitMQ que mostra em tempo real o que acontece dentro do message broker:

Observação: Tecnicamente, o message broker do RabbitMQ é apenas uma parte do sistema de mensagens. Mas no dia a dia, costuma-se chamar o RabbitMQ diretamente de broker.

Diagrama de um Sistema de Mensagem

Agora que entendemos os principais conceitos, fica mais fácil visualizar esse processo em funcionamento. No diagrama abaixo, é possível acompanhar o caminho percorrido por uma mensagem: da aplicação produtora, passando pelo message broker (exchange e queue), até chegar ao consumidor que processa a informação e retorna o resultado para a aplicação final.

1 - A camada de negócio chama o componente produtor
2 - O produtor envia a mensagem para uma exchange do message broker
3 - A exchange roteia a mensagem para uma ou mais filas
4 - O consumidor lê da fila e processa a mensagem
5 - O resultado do processamento é utilizado pela aplicação

No diagrama observamos o fluxo da mensagem desde o produtor até o consumidor. Dentro do próprio message broker, como você deve ter percebido, existem elementos que fazem esse processo acontecer de forma organizada.

Componentes dentro do Message Broker

A exchange recebe as mensagens enviadas pelo produtor e decide para onde cada uma deve seguir. Ela não armazena dados, apenas encaminha a mensagem com base em regras definidas.

Em seguida, temos a queue, que funciona como uma fila de espera. As mensagens ficam armazenadas nela até que algum consumidor esteja disponível para processá-las.

A ligação entre uma exchange e uma fila é chamada de binding. É através dessa configuração que o broker entende quais mensagens devem ser direcionadas para cada fila. Essa organização envolve as exchanges que estão presentes e o tipo de cada uma delas, como direct, fanout, topic ou headers (tópico que possivelmente será discutido em alguma postagem futura).

Consumo de mensagens na aplicação

A mensagem que chega à fila é processada por um consumidor. Na aplicação, esse papel costuma ser implementado por um listener que escuta a fila e, ao receber uma nova mensagem, executa a lógica de negócio. Com o processamento bem-sucedido, o consumidor envia um ACK ao broker, que então remove a mensagem da fila.

Observação: ACK é um sinal confirmando o processamento com sucesso da mensagem.

Essa relação entre exchange, queue, binding e listener e a forma como eles se organizam dentro do sistema de mensagem é chamada de topologia. A topologia mostra quais exchanges existem e seus tipos, quais filas recebem mensagens, como os bindings conectam cada exchange às filas e quais consumidores estão ligados a cada uma delas.

Com isso, conseguimos modelar desde cenários simples, em que existe apenas uma fila consumida por um único serviço, até arquiteturas complexas, em que várias exchanges distribuem mensagens para diferentes filas e consumidores especializados.

Pensar na topologia é essencial porque ela define o caminho da informação dentro do sistema e garante que cada mensagem chegue ao destino correto.

Conclusão

Nesta primeira parte, organizamos os conceitos: produtor, exchange, fila, binding, listener e topologia. Com os termos claros e o percurso da mensagem bem entendido, implementar a topologia em código fica muito mais simples. Na parte dois, vamos para a prática com Java e RabbitMQ.

Referências:

Como começar a lidar com código duplicado em Microsserviços

Vitor Araujo — Sun, 24 Aug 2025 17:03:24 +0000

Esse artigo é um guia introdutório sobre técnicas de reutilização de código em microsserviços, voltado principalmente para desenvolvedores iniciantes e intermediários que estão começando a lidar com arquitetura distribuída. É mais um um mapa inicial para quem deseja entender os trade-offs entre diferentes técnicas de reutilização em microsserviços.

Na minha postagem anterior, comentei sobre duplicação de código em microsserviços e que uma das possibilidades de resolvê-la seria a criação de uma biblioteca compartilhada.

Recentemente recebi o livro Arquitetura de software: as partes difíceis (https://amzn.to/4oPp4cD, link de associado caso queira comprar). A primeira coisa que fiz foi analisar o sumário para ver os tópicos abordados já que comprei pelo título do livro e pelas avaliações rs.

Um dos capítulos aborda exatamente as técnicas de reutilização de código entre microsserviços, descrevendo com diagramas, trade-offs e as situações que cada técnica é mais adequada.

Não sei vocês, mas eu amo de paixão quando consigo conectar diferentes informações e de fato começar a entender algo mais profundamente... e foi isso que aconteceu ao ler esse capítulo haha.

O livro traz 4 técnicas que os desenvolvedores utilizam:

Replicação de Código
Biblioteca Compartilhada
Serviço Compartilhado
Side-cars com malha de serviços

Vou falar brevemente sobre cada uma e deixo pros senhores e senhoras se aprofundarem por conta própria :)

Replicação de Código

Nome autoexplicativo, o desenvolvedor replica o mesmo trecho de código em todos os microsserviços. Essa solução é a menos recomendada (rs) pois a depender do tipo de código que você está replicando, terá um retrabalho enorme sempre que haver modificações... tendo que dar ctrl v em todos os projeto, trabalhar dessa forma aumenta muito as chances de cometer erro.

A melhor aplicação dessa técnica, é quando estamos tratando de códigos que mudam muito pouco ou que são específicos para cada projeto. Por exemplo, uma classe Útil que fez o tratamento de strings ou formatação de datas... Todos os projetos podem possuir uma classe "DataUtil" mas cada um teria apenas os métodos necessários.

Biblioteca Compartilhada

A biblioteca compartilhada é bem interessante. Você cria um projeto a parte que vai armazenar toda a lógica que será reutilizada pelos outros serviços. No caso citado na minha postagem anterior, temos um serviço que é responsável pelo tratamento de exceção. Como trabalhamos com java, sempre que a versão é alterada, é gerado um novo .jar e esse arquivo é copiado para os outros projetos.

Você instala ele como se fosse uma biblioteca interna e tem acesso ao código do projeto. Você tem acesso as classes em tempo de compilação, então consegue executar os testes e verificar se a nova versão causou ou não problemas no projeto.

Um ponto negativo seria justamente o controle de versão dessa biblioteca e a quantidade de projetos que a utilizam... Por exemplo, se ela for altamente acoplada, ou seja, uma modificação nela afeta muitos outros projetos... você precisa ter um plano de atualização de versão da biblioteca.

No livro, é feita uma discussão entre a criação de uma única biblioteca compartilhada que armazena toda lógica duplicada nos serviços vs criação de bibliotecas mais especializadas como, biblioteca de autorização, de logging, de tratamento de exceção...

Levando em consideração os seus conhecimentos... Qual das opções seria mais vantajosa no desenvolvimento de software? Tira um tempinho pra pensar a respeito dos pontos positivos, pontos negativos e impactos de cada uma dessas duas opções.

Bom, normalmente a melhor opção é evitar a criação de bibliotecas grandes em que as alterações afetem muitos serviços... dê preferência sempre a criação de bibliotecas menores e mais especializadas... dessa forma, o impacto das alterações dessas bibliotecas menores não vai atingir muitos serviços, diminuindo o tempo gasto em testes.

Serviço Compartilhado

Nessa técnica, temos a criação de um serviço que vai armazenar a lógica duplicada. Diferente da biblioteca compartilhada, que você tem acesso ao código em tempo de compilação, no serviço compartilhado você terá acesso em tempo de execução.

As alterações nesse serviço, afetam todos os outros que o utilizam. Então caso ele fique fora do ar, todos os outros ficarão sem acesso ao mesmo.

Outro ponto é que os serviços que utilizam esse serviço compartilhado precisam realizar requisições para ele, essas requisições levam um tempo por conta da latência de rede e segurança.

E aqui vem um ponto interessante, há um tempo atrás eu estava estudando a respeito de Remote Procedure Call (RPC), que é uma forma de comunicação entre serviços. Eu havia entendido o que era RPC mas não tinha em mente uma situação interessante para utilizá-lo. Uma das características do RPC é que as chamadas tendem a ser mais rápidas que as chamadas para API's REST... então nessa situação do serviço compartilhado, a utilização de RPC seria mais vantajosa.

E além disso, essa técnica é recomendada também quando temos um projeto de microsserviços que utilizam linguagens diversas... porque, caso a gente prefira utilizar a técnica de biblioteca compartilhada, teríamos que criar a biblioteca em diferentes linguagens, o que já não acontece com o serviço compartilhado... que para acessá-lo, basta realizar chamadas/requisições.

Side Cars com Malha de Serviço

Por fim, temos os Side Cars e as Malhas de Serviços. Essas técnicas são bem mais complexas do que as anteriores e eu não pretendo explicá-las sem a devida profundidade que merece rs.

Então, fica como recomendação de tópico para aprofundamento para caso você se interesse.

Alguns links de vídeos que resumem bem essas técnicas:

Julguei esse conteúdo interessante de ser compartilhado e talvez eu aborde de forma mais aprofundada no futuro algumas dessas soluções :P

minha trajetória como desenvolvedor jr

Vitor Araujo — Wed, 13 Aug 2025 22:54:46 +0000

Essa postagem é pra compartilhar pontos interessantes na minha trajetória como desenvolvedor

Tenho dois anos de experiência profissional como desenvolvedor backend com Java. Nesses dois anos trabalhei com projetos bem diferentes:

6 meses em um sistema legado em Java 7, JSF, Primefaces e SVN
1 ano e 6 meses com microsserviços em Java 21, Spring e git

Trabalhar com um sistema legado me fez ter contato com muitos problemas citados pelo Martin Fowler no seu livro de Refatoração como por exemplo:

Classes e métodos grandes realizando diversas funções
Duplicação de código
Nomes misteriosos
Lista longa de parâmetros

E por causa disso, eu tinha medo de alterar uma vírgula e o sistema parar de funcionar kkk. Por não ter pra onde correr, já que escolhi como profissão ser um desenvolvedor de software, precisei superar essas inseguranças. E foi através do trabalho desenvolvido em cima desse sistema, que ganhei confiança ao atuar como desenvolvedor e subir modificações em produção.

Como eu ganhei essa segurança testando localmente os caminhos felizes e os edge cases, e resolvendo os eventuais BO's que apareciam. Isso me ajudou a melhorar a qualidade do código e diminuiu consideravelmenteas chances de erros em produção.

Depois disso, comecei a trabalhar com microsserviços... e foi aqui que comecei a aprender sobre desenvolvimento de software na atualidade... tendo contato com tópicos como:

Versionamento com git, Docker, Kubernetes, AWS, SOLID, Clean Code, testes de software, integração de APIs, Design Patterns
Mensageria, paralelismo e concorrência

Eu sinto que isso abriu um universo dentro da minha cabeça, porque até então eu só tinha trabalhado com monolitos tanto profissionalmente quanto academicamente.

Ao trabalhar com microsserviços, os prós e contras dele se comparado com os monolitos tornaram-se mais evidentes. Fora que também percebi a importância de gerenciamento de recursos como memória e até mesmo a utilização de logs nos projetos.

Um outro ponto interessante é que existem trechos de códigos que se repetem em todos os projetos. Por exemplo, você quer que seu tratamento de exceção seja padronizado. Então, se o projeto x retornar um código de erro "5x5x5x5" que significa "Dados de excel não encontrado", se o projeto y, retornar esse mesmo código de erro, deve ter o mesmo significado.

Caso você não tire um tempo pra extrair essa duplicação e criar uma “biblioteca interna“, sempre que você alterar esse código em um projeto, você vai ter que alterar em todos os outros projetos e as chances de dar errado são grandes. (problema clássico da duplicação de código)

Se você parar pra pensar, é algo óbvio mas apesar disso, eu só percebi a dimensão do problema depois de ter tido contato na prática rs.

Bom, além do trabalho, estou sempre estudando alguma coisa… Atualmente estou lendo o livro Fundamentos da Arquitetura de Software: uma Abordagem de Engenharia e estou achando bem legal.

Espero terminar de ler até o final do ano. Comprei ele recentemente pela amazon, caso você queira comprar também aqui está meu link de associado https://amzn.to/45xrlAi… caso você compre pelo link, vai estar me ajudando a comprar mais livros e matar minha sede por conhecimento!!!

Fora isso, também estou fazendo meu TCC do curso de ADS do Instituto Federal do Piauí… estou construindo um aplicativo m-health com React Native mas quero dar mais detalhes só quando ele tiver mais encaminhado.

Bom, acho que com essa breve postagem deu pra você conhecer um pouco mais sobre minha pessoa e sobre minha carreira.

E por fim, o objetivo dessas postagens é compartilhar pensamentos e conhecimentos que eu julgar interessante de serem compartilhados. Uma das próximas postagens será sobre uma introdução a mensageria e uma proposta de implementação em Java com RabbitMQ.