RabbitMQ #1 – O que são sistemas de mensageria?

English version: RabbitMQ #1 – Messaging Systems

 Contudo, você sabe o que é um sistema de mensageria? Como ele funciona? Existe mais de um tipo de arquitetura que define o fluxo de mensagens dentro do sistema?  Qual o protocolo de comunicação que define a operação do RabbitMQ?

Tutorial RabbitMQ:

Artigo 01: RabbitMQ #1 – O que são sistemas de mensageria?

Artigo 02: RabbitMQ #2 – RabbitMQ no docker-compose

Artigo 03: RabbitMQ DLX com Java Spring

Além disso, quais as linguagens de programação com suporte ao RabbitMQ. Esse artigo descreve a teoria por trás do RabbitMQ. Além disso, descrevemos uma visão geral sobre o protocolo de comuicação AMQP.

Em artigos futuros iremos aplicar o conhecimento ao criar um cenário utilizando a API java spring-rabbitmq. 

Se quiser saber sobre outro protocolo de comunicação, o HTTP acesse:

• Protocolo HTTP – Como funciona?
• Métodos HTTP
• Cookies – HTTP Protocol
• Apache HTTPS Server configurar

O que é um sistema de mensageria? 

Esse conceito de mensageira está fundamentado na matéria de sistemas distribuídos dentro da computação. Caracteriza-se por uma comunicação orientada a mensagem, onde podem ser classificadas como persistentes ou transientes.

Dessa forma, sistemas de mensageria (messaging systems) podem ser clusterizados, possuem escalabilidade, são tolerantes a falhas, com comunicação assíncrona. Além disso, é intuitivo dizer que opera como sistema distribuído. 

Definição de sistemas distribuídos

Um sistema distribuído opera com seus componentes localmente dispersos. Consequentemente, existe um alinhamento entre os componentes. Dessa forma, na comunicação os dispositivos coordenam suas ações conjuntamente. Contudo, o usuário percebe o sistema (ex: RabbitMQ) como um único componente provedor de serviços. 

Comunicação orientada a mensagem 

Em sistemas de comunicação orientada a conteúdo temos o conceito de middleware services, geralmente conhecido como sistema de filas de mensagens. Ainda assim, o middleware também possui a nomenclatura MOM – Message-Oriented Middleware.

Existem algumas formas distintas de implementação de sistemas de orientada a mensagem. Contudo, o sistema de de filas provê um suporte extensivo para comunicações persistentes assíncronas.

Consequentemente, o sistema é mais indicado para cenários com variação no status das partes envolvidas. 

Muito bem… então como ocorre essa comunicação assíncrona? O sistema de mensageria realiza a intermediação do envio e recebimento de requisições. Dessa forma, as partes envolvidas não precisam estar operacionais ao mesmo tempo.

Neste caso, temos um sistema que tolera minutos ao invés de segundos ou milissegundos.  

Arquitetura de fluxo de mensagens 

A arquitetura que determina o fluxo de comunicação entre as partes, são classificadas como: sistema de filas e publisher/subscriber. Cada arquitetura possui um esquema de intermediação. Contudo, ambos cenários utilizam a abstração de filas. A ideia básica da operação de uma fila é o sistema FIFO – First In First Out. 

A ideia principal desse sistema consiste em estabelecer conexões entre as partes envolvidas. Dessa forma, o sistema fica responsável pelo roteamento e armazenamento das mensagens. Consequentemente, as aplicações de usuários se comunicam de maneira transparente. 

As mensagens trafegadas dentro das filas são roteadas de acordo com algum critério. O fluxo de controle de mensagem define o tipo de roteamento que será aplicado as mensagens. Consequentemente, o fluxo de mensagens depende da arquitetura do sistema. Além disso, há ainda o armazenamento de mensagens.

O roteamento consiste em analisar a partir de critérios previamente estabelecidos para quem será entregue a mensagem. Por sua vez, o armazenamento da mensagem ocorre na fila que conecta o sistema ao destino. Caso a aplicação que irá consumir o conteúdo esteja offline (seja qual for o motivo), a mensagem será armazenada até ser requisitada. 

Protocolos de comunicação 

Os protocolos de comunicação são os responsáveis pela operação do sistema. Consequentemente, o modelo define as diretrizes principais de operação do protocolo. Contudo, a aplicação poderá ainda definir outras features além das que são abordadas no modelo. 

Nosso foco será o protocolo de comunicação AMQP na sua versão 0.9.1. Apesar de parecer contraditório, a versão 1.0 do AMQP implementa um outro modelo de comunicação. Sendo assim, a versão 1.0 não é a evolução do protocolo. 

Existem outros protocolos de comunicação, como HTTP, STOMP, e o próprio AMQP 1.0. Cada um deles implementa um modelo diferenciado de comunicação. Assim, cabe ao profissional de computação verificar qual atenderá suas necessidades.  

Dentro desse contexto, uma das aplicações mais utilizadas atualmente em sistemas de mensageria é o RabbitMQ. Dessa forma, sua base está no modelo AMQ e sua operação no protocolo AMQP 0.9.1. 

Quando esse tipo de sistema se torna interessante? 

O modo de operação de um sistema tradicional requer uma comunicação síncrona, ou seja, o lado do receptor deve estar executando no mesmo momento do envio da requisição. Dessa forma, caso a ponta da comunicação que receberá a mensagem esteja offline, o pacote não será entregue. 

Um exemplo desse cenário se encontra justamente no estabelecimento da comunicação TCP. Dessa forma, para que uma conexão TCP seja estabelecida, as partes devem realizar o handsake antes de efetuar o envio de pacotes. 

Falando ainda em TCP … podemos descrever dois cenários. No primeiro, o cliente envia diversos pacotes de início de conexão. Entretanto, não terá resposta devido a falha no servidor. Diferentemente do primeiro, o segundo cenário que poderá ocasionar a falha na conexão.  

Suponha diversos clientes realizando requisições ao mesmo tempo. Haverá um fluxo enorme de pacotes que poderá ocasionar diferentes problemas, como: lentidão no servidor, queda de performance, atraso na resposta das requisições, e por fim queda (falha) do servidor. 

Em um sistema de mensageria, a comunicação não fica comprometida caso haja falha em um nó destino. O sistema é responsável por gerenciar as mensagens até estas serem entregues aos seus respectivos destinatários.

O leitor pode receber então, que existem cenários em que essa comunicação alternativa é necessária. Assim sendo, sistemas orientados a mensagem são uma solução viável. 

Protocolo AMQP

O AMQP 0-9-1 é um protocolo de mensageria binário, ou seja, onde existem duas partes envolvidas. Dessa forma, as duas pontas da comunicação são denominadas produtores e consumidores. As mensagens recebidas pelos consumidores são enviadas pelos produtores. 

Outra nomenclatura é a de publisher (editor) e subscriber (assinante). Esta por sua vez está associada apenas ao modelo Pub/Sub. Contudo, a primeira nomenclatura pode ser utilizada em sistemas de filas e Pub/Sub. Trataremos este tema futuramente em outro artigo. 

Continuando … o AMQP é então binário, e um framework de semântica para micro serviços, e mensageria de empresas. Ele define como será o fluxo de mensagens dentro do sistema de comunicação assíncrona. Assim como a função dos componentes do sistema. 

“Semântica: num sistema linguístico, o componente do sentido das palavras e da interpretação das sentenças e dos enunciados.” 

oxford language 

O que seria então um framework de semântica? 

O conceito de semântica está atrelado ao sentido das palavaras. Consequentemente, podemos extrapolar para nosso contexto como sentido, ou papel de um componente dentro do sistema. Dessa forma, o AMQP define a estrutura, e componentes do sistema.

Cada componente tem sua ordem dentro da estrutura de comunicação. Vamos utilizar o RabbitMQ para exemplificação. Um produtor se comunica com o message-broker enviando as mensagens. Por sua vez, um consumidor estabelece comunicação através das filas.

As permissões, limites, função dentro do sistema e quais features cada componente poderá modificar são definidas pelo protocolo.

AMQP versão 0.9.1

Como mencionei anteriormente, apesar de nomes semelhantes, o AMQP 0-9-1 e AMQP 1.0 são protocolos completamente diferentes. Portanto, o AMQP 1.0 possui um escopo e modelo de topologia diferentes da versão 0.9.1.

O RabbitMQ, foco do nosso artigo, opera com base no AMQP 0-9-1. Contudo, fornece suporte via plugins aos protocolos de comunicação AMQP 1.0, MQTT e STOMP.  

O AMQP realiza a interoperabilidade entre clientes e servidores do tipo messaging middleware servers (brokers). O objetivo do protocolo é permitir que a indústria e os desenvolvedores adotem a padronização referente a tecnologia de messaging middleware.

Assim, diminuir custos das empresas e integração de sistemas, e fornecer integração de serviço à nível de indústria a um público mais amplo. 

Interoperabilidade

Para garantir a interoperabilidade do sistema, protocolos de rede e de semântica devem ser especificados nos serviços do lado do servidor. O AMQP implementa os protocolos definindo um conjunto de recursos de mensagens, e um protocolo denominado network wire-level. 

A base do protocolo AMQP está fundamentada em um conjunto definido de recursos de mensagens denominado “Advanced Message Queuing Model “(modelo AMQ). O modelo AMQ consiste em um conjunto de componentes que roteiam e armazenam mensagens dentro do serviço do broker.

Além disso, há ainda um conjunto de regras para conectar esses componentes. Um protocolo wire-level network, AMQP, que permite que aplicativos clientes conversem com o servidor e interajam com o modelo AMQ que ele implementa. 

RabbitMQ – breve descrição

O RabbitMQ é uma aplicação open source de message-broker (intermediário) de comunicação e troca de mensagens entre as partes. Por ter sido desenvolvido em erlang, é muito leve e eficiente. A linguagem erlang foi desenvolvida pela Ericson, com foco em sistemas distribuídos.

Além disso, diferentemente de sistemas tradicionais, o RabbitMQ opera estabelecendo comunicações assíncronas. Consequentemente, as partes envolvidas não precisam estar operacionais ao mesmo tempo para a comunicação ser efetuada.

O RabbitMQ é uma aplicação do protocolo AMQP na versão 0.9.1. Neste caso, o servidor de produção (de mensagens) estará conectado à uma exchange, ao invés de estar conectado à fila diretamente. A exchange é similar a um correio que direciona as mensagens de acordo com seu endereçamento.

Existem outras aplicações de mensageria no mercado. Contudo, e o que define cada uma delas está relacionado ao fluxo das mensagens dentro do sistema. Em outras palavras, a forma como a mensagem se move pelo sistema.

Características do RabbitMQ

No RabbitMQ, essa informação faz parte dos metadados. Assim, o desenvolvedor tem bastante controle da forma como a mensagem se move pelo sistema ao invés do administrador do broker.

Outro benefício do RabbitMQ é ser cloud friendly. Podendo ser implementado em ambientes como AWS. Ainda assim, pode ser implementado no docker ou outro sistema de containers.

Além disso, o RabbitMQ pode ser clusterizado. Como trata-se de uma aplicação de sistema distribuído, existem vários benefícios, como: full tolerance, high available, high throughput e a clusterização.

O RabbitMQ ainda possui cross-language communication. Isso  significa dizer que a mensagem pode ser consumida por um servidor em javascript ou em python. Portanto, a operação do RabbitMQ independe da linguagem de aplicação.

Um produtor pode ter sua aplicação em uma linguagem diferente da aplicação do consumidor, ainda assim o sistema continua operante.

Outra característica atrativa do RabbitMQ está ligada à segurança. Possui suporte a protocolos de segurança como SSL, TLS (3° versão do SSL), de autenticação e autorização como LDAP.

Tutorial RabbitMQ:

Artigo 01: RabbitMQ #1 – O que são sistemas de mensageria?

Artigo 02: RabbitMQ #2 – RabbitMQ no docker-compose

Artigo 03: RabbitMQ DLX com Java Spring

Artigos relacionados

• RabbitMQ #2 – RabbitMQ no docker-compose
• Docker Instalação

Referências Bibliográficas 

Especificação do protocolo de comunicação AMQP 

Tanenbaum, Andrew S., and Steen V. Maarten. “Distributed Systems: Principles and Paradigms” Pearson – 2° edição.