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

Antes de mais nada, vamos começar com uma breve definição do 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, quando falamos (e também implementamos) mensageria em projetos:

• 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.
• Advanced Message Queuing Protocol (AMQP): Um protocolo mais atual 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.
• 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.
• Simple/Streaming Text Oriented Messaging Protocol (STOMP): 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.
• 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.

• IBM MQ Series: Suporta somente o protocolo JMS, visto que é um Broker mais antigo e que veio da época dos Applications Servers corporativos.
• ActiveMQ: 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.
• RabbitMQ: Mais famoso por sua simplicidade de uso e boa capacidade de performance, é mais usado por projetos que usam exclusivamente o protocolo AMQP.
• Kafka: Outro broke muito famoso e também 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.

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.

Este 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.

‍

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.

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 Microsserviç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.

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.

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 aplicação produtora da mensagem não precisa se preocupar se a aplicação consumidora está disponível no momento do envio.
  
  
• 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).
  
  
• É possível tentar consumir a mensagem mesmo após uma falha, devido a mesma estar enfileirada no Broker.
  
  
• 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

• O desenvolvimento de sistemas ou microserviços usando esse tipo de integração, podem ficar mais complexos que o normal.
  
  
• Não adequado para cenários que exijam um modelo mais síncrono na forma de comunicação entre sistemas.

Deseja saber mais? Clique no link e marque uma consulta com nossos especialistas:

https://meetings.hubspot.com/30minute_servicemesh

‍