O RabbitMQ ganha vida
O sistema de mensagens ou enfileiramento de mensagens é um método de comunicação entre aplicativos ou componentes. Graças às filas de mensagens, esses aplicativos podem permanecer completamente separados enquanto processam suas tarefas individuais.
As mensagens são geralmente pequenas solicitações, respostas, atualizações de status ou mesmo apenas informações. Uma fila de mensagens fornece um local temporário para essas mensagens, permitindo que os aplicativos as enviem e recebam conforme necessário.
O RabbitMQ é um agente de mensagens de código aberto que atua como intermediário ou intermediário para aplicativos independentes, fornecendo-lhes uma plataforma comum para se comunicarem. RabbitMQ usa principalmente uma implementação baseada em Erlang do Protocolo de Enfileiramento de Mensagens Avançado (AMQP), que oferece suporte a recursos avançados, como clustering e roteamento complexo de mensagens.
Este artigo inclui informações sobre como começar a usar RabbitMQ e por que ele beneficiaria um arquitetura. Este livro segue uma agência de táxi fictícia, Complete Car (CC), para demonstrar como eles implementaram o RabbitMQ na arquitetura. Este capítulo mostra como instalar e configurar o RabbitMQ para que seja fácil colocar tudo em funcionamento.
O que vamos aprender?
- Explicando filas de mensagens
- Descobrindo AMQP e RabbitMQ
- Usando RabbitMQ na vida real
- Explorando os benefícios do enfileiramento de mensagens
- Um cenário RabbitMQ
- Se preparando para o RabbitMQ
Explicando filas de mensagens
Sinais de fumaça, mensageiros, pombos-correio e semáforos: se isso fosse um enigma, as palavras mensagens viriam imediatamente à mente. A humanidade sempre teve a necessidade de se conectar, encontrando novas maneiras de desafiar os desafios colocados pela distância entre os diferentes grupos de pessoas que precisam se comunicar.
A humanidade já percorreu um longo caminho com as tecnologias modernas, mas, essencialmente, o básico permanece. Remetentes, destinatários e mensagens estão no centro de todas as nossas infraestruturas de comunicação. Os aplicativos de software têm as mesmas necessidades; os sistemas precisam se comunicar e enviar mensagens entre si.
Às vezes, eles precisam ter certeza de que a mensagem enviada chegou ao seu destino e, às vezes, precisam receber uma resposta imediata. Em alguns casos, eles podem até precisar receber mais de uma resposta. Com base nessas diferentes necessidades, surgiram diferentes estilos de comunicação entre os sistemas. AMQP, o protocolo padrão do RabbitMQ, é explicado na próxima seção.
Descobrir o AMQP e o enfileiramento RabbitMQ
Message é um estilo de comunicação unilateral que fornece interação assíncrona entre sistemas. À medida que este capítulo continua a descrever como funcionam as filas de mensagens, os benefícios se tornarão claros. Algumas informações sobre o padrão de troca de mensagens de solicitação-resposta esclarecerão como o RabbitMQ funciona.
O padrão de troca de mensagens de solicitação-resposta
Há muitos tipos de padrões de troca de mensagens, mas o estilo de solicitação-resposta é o mais comum. Um sistema, atuando como um cliente, interage com outro sistema remoto, que está atuando como um servidor. O cliente envia uma solicitação de dados e o servidor responde à solicitação, conforme mostrado no diagrama a seguir:
Quer tome a forma de uma chamada de procedimento remoto, uma chamada de serviço da Web ou consumo de um recurso, o modelo é o mesmo: um sistema envia uma mensagem para outro e aguarda a resposta da parte remota.
Os sistemas comunicam-se uns com os outros de forma ponto a ponto, onde eventos e processos ocorrem simultaneamente ou têm dependências ou eventos relacionados com o tempo; a interação entre o cliente e o servidor é síncrona.
Um por lado, esse estilo de solicitação-resposta oferece aos desenvolvedores um modelo de programação simples, pois tudo acontece de maneira processual. Por outro lado, o acoplamento estreito entre as duas partes tem um impacto profundo na arquitetura de todo o sistema, pois é difícil evoluir, escalar e distribuir em versões independentes.
Padrão de troca de enfileiramento de mensagens
O enfileiramento de mensagens é um estilo unilateral de interação em que um sistema interage de forma assíncrona com outro sistema por meio de mensagens, geralmente por meio de um corretor de mensagens. Um sistema solicitante em modo de comunicação assíncrona não espera por uma resposta ou requer uma informação de retorno; ele continua processando, não importa o quê. O exemplo mais comum de tal interação é um e-mail.
A questão é que a comunicação assíncrona não envolve esperar por uma resposta para continuar o processamento. Na verdade, pode não haver resposta ou pode levar algum tempo para que uma resposta seja enviada. Seja qual for o caso, o sistema não depende de uma resposta para continuar o processo.
As mensagens fluem em uma direção, do editor para o corretor e, finalmente, para o consumidor:
Os sistemas e aplicativos desempenham a função de publicadores (produtores) e consumidores de mensagens (assinantes). Um publicador publica uma mensagem para um corretor de quem ele confia para entregar os dados ao consumidor pretendido. Se uma resposta for necessária, ela chegará em algum ponto no tempo por meio do mesmo mecanismo, mas invertida (as funções de consumidor e produtor serão trocadas).
Uma arquitetura fracamente acoplada
Uma grande vantagem da abordagem de enfileiramento de mensagens é que os sistemas ficam fracamente acoplados entre si. Eles não precisam saber a localização de outros nós na rede; um mero nome é suficiente para alcançá-los. Os sistemas podem, portanto, ser desenvolvidos de maneira independente sem nenhum impacto uns sobre os outros, pois a confiabilidade da entrega da mensagem é confiada a um corretor.
O diagrama a seguir ilustra um acoplamento fraco entre o editor e o consumidor:
Se um sistema estiver inativo por qualquer motivo, a outra parte do sistema ainda pode operar, e as mensagens que deveriam ser enviadas entre eles aguardam na fila. A arquitetura representada por meio do enfileiramento de mensagens permite o seguinte:
- Os editores ou consumidores podem ser atualizados um a um, sem impactar uns aos outros.
- O desempenho de cada lado não é afetado.
- Os editores ou consumidores podem falhar sem impactar uns aos outros.
- O número de instâncias de editores e consumidores escala e para acomodar sua carga de trabalho com total independência.
- Mistura de tecnologia entre consumidor e editores.
A principal desvantagem dessa abordagem é que os programadores não podem confiar no modelo mental de programação procedural, onde os eventos ocorrem um após o outro. Nas mensagens, as coisas acontecem com o tempo.
Os sistemas devem ser programados para lidar com isso. Se tudo isso ficar um pouco confuso, use o exemplo de um protocolo bem conhecido, Simple Mail Transfer Protocol (SMTP). Neste protocolo, os emails são publicados (enviados) para um servidor SMTP. Esse servidor inicial então armazena e encaminha o e-mail para o próximo servidor SMTP e assim por diante até que o servidor de e-mail do destinatário seja alcançado.
Nesse ponto, a mensagem é enfileirada em uma caixa de entrada, aguardando para ser recebida pelo consumidor (normalmente, via POP3 ou IMAP). Com o SMTP, o editor não tem ideia de quando o e-mail será entregue ou se será entregue. No caso de falha na entrega, o editor é notificado sobre os problemas posteriormente. O único fato certo é que o corretor aceitou com sucesso a mensagem que foi enviada inicialmente.
Todo esse processo pode ser visto no diagrama a seguir:
Além disso, se uma resposta for necessária, ela chegará de forma assíncrona usando o mesmo mecanismo de entrega, mas com as funções de editor e consumidor invertidas.
Com essas noções fundamentais estabelecidas, é o momento perfeito para mergulhar no protocolo de mensagens que será usado neste livro , que é AMQP.
Conheça o AMQP
AMQP é um protocolo de padrão aberto que define como um sistema pode trocar mensagens. O protocolo define um conjunto de regras que devem ser seguidas pelos sistemas que irão se comunicar entre si. Além de definir a interação que ocorre entre um consumidor / produtor e um corretor, também define a representação das mensagens e comandos que estão sendo trocados.
AMQP é verdadeiramente interoperável, pois especifica o formato de transmissão para mensagens, não deixando nada aberto à interpretação por um fornecedor ou plataforma de hospedagem em particular. Por ser de código aberto, a comunidade AMQP é prolífica e tem implementações de broker e cliente em uma ampla variedade de idiomas.
O RabbitMQ foi desenvolvido com base na especificação AMQP 0-9-1, mas há plug-ins disponíveis que suportam AMQP 1.0.
A seguir está uma lista dos principais conceitos do AMQP, que serão explicados em detalhes nos próximos artigos:
Broker ou broker de mensagem: Um broker é uma parte do software que recebe mensagens de um aplicativo ou serviço e as entrega a outro aplicativo, serviço ou broker.
Host virtual, vhost: Existe um vhost dentro do broker. É uma maneira de separar aplicativos que estão usando a mesma instância do RabbitMQ, semelhante a um contêiner lógico dentro de um corretor; por exemplo, separar ambientes de trabalho em desenvolvimento em um vhost e temporariedade em outro, mantendo-os dentro do mesmo broker em vez de configurar vários brokers. Usuários, trocas, filas e assim por diante são isolados em um vhost específico. Um usuário conectado a um determinado vhost não pode acessar nenhum recurso (fila, troca e assim por diante) de outro vhost. Os usuários podem ter diferentes privilégios de acesso a diferentes vhosts.
Conexão: Conexão de rede física (TCP) entre o aplicativo (editor / consumidor) e um corretor. Quando o cliente se desconecta ou ocorre uma falha do sistema, a conexão é fechada.
Canal: Um canal é uma conexão virtual dentro de uma conexão. Ele reutiliza uma conexão, dispensando a necessidade de reautorizar e abrir um novo fluxo TCP. Quando as mensagens são publicadas ou consumidas, isso é feito em um canal. Muitos canais podem ser estabelecidos em uma única conexão.
Troca: A entidade de troca é responsável por aplicar as regras de roteamento das mensagens, garantindo que as mensagens cheguem ao seu destino final. Em outras palavras, a troca garante que a mensagem recebida acabe nas filas corretas. A fila em que a mensagem vai parar depende das regras definidas pelo tipo de troca. Uma fila precisa ser vinculada a pelo menos uma central para receber mensagens. As regras de roteamento incluem trocas diretas (ponto a ponto), tópico (publicar-assinar), fanout (multicast) e cabeçalhos.
Fila: Uma fila é uma sequência de itens; neste caso, mensagens. A fila existe dentro do corretor.
Ligação: Uma ligação é um link virtual entre uma troca e uma fila dentro do corretor. Ele permite que as mensagens fluam de uma troca para uma fila.
O diagrama a seguir ilustra uma visão geral de alguns dos conceitos no AMQP:
O broker de código aberto mostrado em detalhes neste livro foi construído do zero para oferecer suporte a AMQP, mas muitos outros protocolos também são suportados pelo RabbitMQ, como MQTT, HTTP e STOMP.
Agora, é hora de voltar o foco para RabbitMQ.
O Broker RabbitMQ
RabbitMQ é uma implementação Erlang de um corretor AMQP. Ele implementa a versão 0-9-1 do AMQP com extensões personalizadas, conforme permitido pelo protocolo. Erlang foi escolhido devido ao seu suporte intrínseco para a construção de aplicativos altamente confiáveis e distribuídos. Na verdade, Erlang é usado para executar comutadores de telecomunicações em vários grandes sistemas de telecomunicações, e a disponibilidade total do sistema de nove noves foi relatada (isso significa apenas 32 milissegundos de tempo de inatividade por ano).
Erlang é capaz de rodar em qualquer sistema operacional. Para persistência de dados, RabbitMQ conta com Mnesia, o banco de dados embutido em memória / arquivo persistido de Erlang. Mnesia armazena informações sobre usuários, trocas, filas, ligações e assim por diante. O índice da fila armazena posições de mensagens e informações sobre se uma mensagem foi entregue ou não. As mensagens são armazenadas no índice da fila ou no armazenamento de mensagens, um armazenamento de valor-chave compartilhado entre todas as filas.
Para clustering, ele depende principalmente das habilidades de clustering arraigadas de Erlang. O RabbitMQ pode ser facilmente estendido com a adição de plug-ins. Por exemplo, um console de administração baseado na web pode ser implantado no RabbitMQ graças a este mecanismo.
Os corretores RabbitMQ podem ser conectados usando diferentes técnicas, como federação e pás, a fim de formar topologias de mensagens com roteamento de mensagens inteligentes entre corretores e a capacidade de abranger vários centros de dados.
A captura de tela a seguir mostra a federação entre corretores RabbitMQ localizados em diferentes lugares ao redor o mundo:
Nenhum comentário:
Postar um comentário