Tal
aplicativo funciona em um servidor, como também pode funcionar em várias
instâncias em uma mesma estação ou estações diferentes, o que faz com que
tenhamos uma alta disponibilidade. O padrão arquitetural de mensageria permite evoluir
as aplicações e torná-las mais escaláveis e estáveis, bem como facilita a integração
entre sistemas ou camadas de um mesmo sistema.
Imagine que temos um web service que aceita muitas requisições por segundo e também temos um sistema que processa tais requisições. Se colocarmos uma fila entre o web service e o sistema, dispomos de menos acoplamento entre as duas aplicações, porque agora ambas têm os parâmetros de configuração do gerenciador de mensagens.
Caso tenhamos muitas requisições chegando em um curto espaço de tempo, o sistema irá processar algumas requisições, mesmo se a quantidade de requisições for realmente grande. Claro que precisamos de situações mais complexas onde o número de aplicações é muito maior do que duas e que precisamos gerenciar a comunicação entre elas.
A mensageria é uma técnica que visa solucionar a comunicação entre sistemas completamente diferentes de uma maneira confiável. Podemos ter várias plataformas que precisam se comunicar: um serviço do Windows, um sistema feito em Java, um sistema feito em PHP, uma aplicação ASP.NET MVC, etc. A mensageria faz com que possamos integrar tais sistemas para que eles possam trocar dados de forma desacoplada.
Um Barramento de Mensagens é um dos componentes mais importantes em uma infraestrutura para a mensageria, pois é o mecanismo que coordena o envio e a recepção de mensagens em uma fila.
Os sistemas de mensageria tinham muitas formas de resolver o problema no passado, mas nenhum deles foi unânime de forma que fosse conhecido o largamente utilizado em todas as empresas conhecidas. Sistemas baseados em mensagens eram complexos, caros, difíceis de se conectar e ainda mais difíceis de trabalhar. Também não seguiam nenhum padrão de mensageria em particular, cada um criava o seu.
Para resolver este problema e tentar, de alguma forma, trabalhar de forma pioneira, o protocolo AMQP foi criado. Este protocolo tende a unificar todas as tecnologias envolvidas em todas os sistemas de mensageria existentes, melhorando e estabilizando falhas nestes que porventura foram encontradas pelos criadores do AMQP, de forma a torná-lo robusto, confiável e escalável ao longo do tempo.
Antes de falarmos sobre o RabbitMQ, vamos falar um pouco sobre o AMQP e seu histórico, já que é o padrão adotado pelo RabbitMQ.
O que é o AMQP?
O AMQP é um protocolo de comunicação em rede, tal qual o HTTP, que permite que aplicações se comuniquem.
Soluções para mensageria existem desde a década de 1970 com a ideia de resolver os problemas de integração entre diversos fornecedores. Sem o uso de um middleware de mensagens, a integração heterogênea de sistemas provou ser um processo muito caro e complexo.
Por exemplo, soluções para mensagens, como o IBM Websphere MQ e o TibCO Enterprise Message Service, são muito caras e tendem a ser utilizadas apenas por grandes companhias, especialmente a indústria de serviços financeiros.
Além destes percalços, existem também problemas de interoperabilidade entre estas soluções. Fornecedores, para contornar este problema, criaram seus próprios protocolos para mensageria, logo notamos que não eram integrados com outros fornecedores, já que cada um criava a sua solução, isso se chamava de Lock-in de Fornecedor, que em nosso idioma soa como uma reserva de mercado ou reserva de nicho.
O AMQP tem muitas vantagens, mas duas são mais importantes: produzir um padrão aberto para protocolos de mensageria e permitir a interoperabilidade entre muitas tecnologias e plataformas.
Existem muitos sistemas rodando em muitos Sistemas Operacionais, que são desenvolvidos com múltiplas linguagens de programação, rodando em várias arquiteturas de hardware e máquinas virtuais. AMQP não só torna a integração dentre esses vários sistemas diferentes possível, como também permite que produtos diferentes que implementem este protocolo possam trocar informações e isso faz do AMQP o pioneiro bem como a evolução da mensageria.
O Broker e o seu papel
Brokers de mensagens recebem mensagens de seus criadores (aplicações que publicam mensagens) e as roteiam até seus consumidores (aplicações que processam mensagens).
Tomando o corpo humano como exemplo, os brokers funcionariam com o Sistema Nervoso Central e as aplicações seriam os membros do corpo (braços, pernas, cabeça e afins).
O modelo por trás do AMQP
O modelo do AMQP funciona da seguinte maneira: mensagens são publicadas pelos produtores e enviadas às exchanges. As exchanges distribuem as cópias das mensagens para filas utilizando regras que são chamadas de bindings no jargão do AMQP.
Então brokers AMQP enviam mensagens para consumidores que acessam, ou assinam, as filas, ou consumidores buscam e processam mensagens da fila sob demanda.
Quando publicam uma mensagem, produtores podem especificar vários atributos para ela, também chamados de metadados da mensagem. Alguns destes atributos podem ser utilizados pelo broker, contudo, outros atributos são apenas utilizados pelas aplicações que recebem a mensagem.
Redes não são confiáveis e aplicações podem falhar em processar mensagens, portanto o modelo do AMQP tem a implementação de acknowledgments de mensagens, ou seja, quando uma mensagem é enviada a um consumidor, o consumidor notifica o broker, seja automaticamente, seja desenvolvido posteriormente.
Quando acknowledgements estão sendo utilizados, um broker só removerá a mensagem por completo da fila quando esta tiver recebido uma notificação desta mensagem (ou grupo de mensagens).
Em certas situações, quando uma mensagem não puder ser roteada, ela poderá ser retornada para seu criador, descartada ou se o broker implementar uma extensão chamada de "fila da mensagem morta", ou dead letter queue, os produtores podem escolher como manipular situações como esta apenas selecionando alguns parâmetros.
Filas, Exchanges e Bindings são chamadas de Entidades AMQP.
Na Figura 1 temos um fluxo simples de como o AMQP fu ...
