O que é Mensageria e o que eu ganho com isso?

Se você é um Desenvolvedor ou mesmo um Arquiteto, Mensageria é um assunto que você já deve ter ouvido falar. De fato, mensageria é um tópico bem conhecido se você deseja trabalhar com desenvolvimento de software, desenhar soluções que envolvam sistemas distribuídos, trabalhar de maneira assíncrona ou mesmo, resolver problemas de integração entre sistemas.

Neste artigo, irei compartilhar algumas explicações sobre esse assunto muito presente no dia a dia do desenvolvimento de software, mas antes de mais nada, gostaria de iniciar um uma breve descrição sobre o que é mensageria.

Definição - O que é Mensageria?
“… É uma abordagem de desenvolvimento usando mensagem para estabelecer comunicação / integração síncrona ou assíncrona entre aplicações, usando um Message Broker ou um MOM para tal…”

Message Broker? MOM?
Message Broker ou MOM (Message Oriented Middleware) nada mais é que um servidor (infraestrutura) idealizado únicamente para processar e suportar o envio/recebimento, redirecionamento e também a monitoria das mensagens compartilhadas entre os sistemas integrados por mensagem.

Protocolos para Mensageria
Inicialmente vou falar dos 5 principais protocolos usados hoje em projetos de desenvolvimento. Existem outros, porém esses aqui, provavelmente, são os mais comuns que você pode se deparar no seu dia a dia.

O primeiro, é o Java Message Service (JMS). Como o próprio nome diz, voltado para integrações entre serviços ou componentes desenvolvidos em Java. Muito usado também em Application Servers onde aplicações corporativas desenvolvidas em Java são implantadas.

O próximo  é o Advanced Message Queuing Protocol (AMQP). Um dos protocolos mais atuais e indiferente da linguagem de programação usada no desenvolvimento de aplicações. Se a sua linguagem favorita para desenvolvimento tem suporte a esse protocolo, suas aplicações conseguem se comunicar através de um Broker que usa o mesmo protocolo.

A seguir, gostaria de trazer a vocês o Message Queue Telemetry Transport (MQTT). Muito utilizado para comunicação de dispositivos inteligentes (IoT). Com esse protocolo, fica mais fácil a implementação de objetos se comunicarem em rede e enviarem mensagens, seja entre objetos ou mesmo para outros sistemas que precisam de notificações desses dispositivos.

Em termos de uso, o Simple/Streaming Text Oriented Messaging Protocol (STOMP) é o mais interessante (na minha visão). Mais voltado para Streaming de dados, onde os mesmos são serializados e quando a informação precisa ser entregue praticamente em tempo real para os consumidores.

Por último, porém não menos importante, temos o Microsoft Message Queuing (MSMQ). Esse protocolo, como o nome diz, é uma implementação Microsoft, bastante usado em aplicações desenvolvidas em linguagem proprietária da empresa, teve seu ápice de uso em versões NT do Windows, além da versão 2016 Server e com suporte no Windows 10. Uso muito específico da plataforma Microsoft.

Principais Brokers de Mercado

Podemos listar aqui quais os principais Brokers mais usados hoje em projetos e quais protocolos eles conseguem suportar. Existem muitos outros que não estão aqui mencionados, porém, foquei nos que estão mais em voga nos projetos atuais.

O mais comum em ambientes corporativos, o IBM MQ Series, suporta somente o protocolo JMS, visto que é um Broker mais antigo e que veio da época dos Applications Servers corporativos.

O ActiveMQ é o mais versátil, suporta tanto o JMS quanto o AMQP, ou seja, pode ser usado tanto por aplicações Java mais antigas quanto aplicações que são mais atuais e usam protocolo multilinguagem.

Um dos mais famosos brokers em uso hoje, o RabbitMQ traz simplicidade de uso e boa capacidade de performance, é mais usado por projetos que usam exclusivamente o protocolo AMQP

Outro broker também muito famoso, o Kafka é muito utilizado em projetos de alta performance, usa o protocolo STOMP.

Modelos de Integração

Nessa parte do artigo, vou falar das 3 principais formas de integração usando mensageria e também um message broker.

Modelo Point-to-Point

A troca de informações é baseada em filas, onde a mensagem é enviada por uma aplicação que chamamos de produtor e consumida por um ou mais aplicações que chamamos de consumidores, que “escutam” uma determinada fila.

Nesse modelo é possível somente uma mensagem por consumidor (one-to-one). Sendo assim, mesmo que existam vários consumidores escutando uma mesma fila, cada consumidor vai receber uma única mensagem por vez.

https://www.devmedia.com.br

Modelo Publish/Subscribe

Também conhecido como modelo Pub/Sub, é baseado em tópicos, onde as mensagens são enviadas pela aplicação produtora e entregues para as aplicações consumidoras, que "assinam" um tópico. 

Esse modelo permite que a mensagem seja entregue para vários consumidores (one-to-many), ou seja, nesse caso, consumidores com assinatura durável, podem consumir as mensagens mesmo que as anteriores ainda estejam ativas.

https://www.devmedia.com.br

Dead Letter Queue

O nome “Dead Letter” vem de um padrão de correios, onde uma determinada correspondência não consegue ser entregue, a mesma deve ser enviada para algum departamento responsável por cuidar dessas correspondências não entregues por motivos variados.

Logo, na implementação, podemos usar algo similar. Quando não é possível entregar uma mensagem, é uma opção ter uma “fila” onde podemos enfileirar esses itens para que alguém tome uma ação, visto que a mesma não foi consumida e nem entregue a ninguém.

https://www.devmedia.com.br

Aqui vale um lembrete importante, a DLQ como é comumente chamada, é responsável por receber mensagens não entregues ou não consumidas. Usar a DLQ para enviar mensagens de erro de integração é um padrão errado de uso. Quando temos um erro de integração ou de envio de mensagem, podemos criar ou uma outra fila responsável por tal ou criar alertas de monitoramento dependendo da ferramenta (Broker) que usamos na integração.

Mensageria em Microserviços

O tema mensageria também está muito presente atualmente, quando estamos trabalhando em projetos relacionados a Arquitetura de Microserviços.

Uma vez que cada microserviço deve ser independente um do outro, mas mesmo assim, ainda temos que compartilhar dados ou mesmo enviar dados de um serviço para o outro ou mesmo alertar que uma ação aconteceu.

Usando mensageria, pode resolver vários desses cenários de comunicação entre microserviços sem gerarmos acoplamento entre eles, e assim, continuaremos com eles independentes uns dos outros.

Vamos falar de um padrão chamado Event Sourcing que é muito usado em Arquiteturas Orientadas a Eventos.

https://www.devmedia.com.br

Event Sourcing

Um padrão de desenvolvimento bastante usado na Arquitetura de Microserviços, o Event Sourcing usa mensageria, para que um evento propague dados e seja possível compartilhar informações entre mais de um microserviço, sem perder a consistência.

Também muito atrelado ao padrão CQRS, ajuda ainda mais no baixo acoplamento de sistemas e microserviços.

Abaixo temos um exemplo de uma informação que tem que ser compartilhada entre microserviços de forma a não gerar acoplamento entre eles.

https://microservices.io/

Ok, mas o que eu ganho e o que eu perco?

Nessa parte final do artigo, vamos mencionar algumas das principais vantagens e desvantagens do uso de mensageria em nossos projetos.

Vantagens do Uso de Mensageria

A primeira vantagem que eu gostaria de enaltecer, é que a aplicação produtora da mensagem não precisa se preocupar se a aplicação consumidora está disponível no momento do envio.

O uso de mensageria, provê baixo acoplamento na integração entre sistemas, deixando a comunicação assíncrona.

Dependendo do Protocolo, é possível integrar sistemas de diferentes linguagens (ex: com o AMQP, aplicações Java podem se comunicar com aplicações PHP, Python, etc).

Outra vantagem, é possível tentar consumir a mensagem mesmo após uma falha, devido a mesma estar enfileirada no Broker.

A última vantagem que eu gostaria de listar aqui, é que o uso de eventos para compartilhamento de dados ajuda a manter a consistência de dados e também comunicação assíncrona.

Desvantagens do Uso de Mensageria

Claro, tudo tem sua desvantagem, dependendo das suas escolhas de implementação. No meu ponto de vista, usando mensageria,  o desenvolvimento de sistemas ou microserviços usando esse tipo de integração, podem ficar mais complexos que o normal.

Além disso, o uso de mensageria não é adequado para cenários que exijam um modelo síncrono na forma de comunicação entre sistemas.

Referências de Estudo

Vou deixar alguns links interessantes que eu usei como referência para montar esse artigo, e que também servem para o nosso dia a dia nos projetos que implementamos:

https://www.enterpriseintegrationpatterns.com/patterns/messaging/index.html
https://en.wikipedia.org/wiki/Message_broker
https://www.ibm.com/cloud/learn/message-brokers
https://microservices.io/patterns/data/event-sourcing.html

Este artigo foi escrito por Adriano Mota e publicado originalmente em Prensa.li.