SERVIÇOS DE MENSAGERIA

Com uma necessidade cada vez mais crescente das aplicações se comunicarem entre si, soluções tecnológicas vão surgindo para nos apoiar nessas situações. O uso de um middleware de mensageria simplifica esses desafios e uma infraestrutura de comunicação comum que pode facilmente ser escalável para atender as condições mais exigentes. Essas comunicações podem acontecer das mais variadas formas, e os middleware de mensageria dão suporte a essas diversas formas (E. S. Pramukantoro, J. Ratna Wulandari, W. Yahya and H. Nurwarsito - 2018).

Um método de comunicação usado pelos middlewares de mensageria é um que usa um Message Broker. Com um Message Broker, o aplicativo de origem (produtor) envia uma mensagem para um processo do servidor que pode fornecer empacotamento,

roteamento, tradução de mensagens, persistência e entrega de dados para todos os destinos apropriados (consumidores), como podemos observar na Figura 6. A característica definidora de um Message Broker é que o próprio broker é um serviço discreto. Produtores e consumidores se comunicam com o broker usando protocolos padrão ou proprietários.

Figura 6 - Diagrama de sequência para representar o padrão Message Broker

Fonte: Imagem retirada do site wikipedia6.

O Message Broker normalmente fornece todo o gerenciamento e rastreamento de estado dos clientes, para que aplicativos individuais não precisem assumir essa responsabilidade e a complexidade da entrega de mensagens é incorporada por ele (E. S. Pramukantoro, J. Ratna Wulandari, W. Yahya and H. Nurwarsito - 2018). Existem duas formas básicas de comunicação com um Message Broker:

6 Disponível em: <https://en.wikipedia.org/wiki/Message_broker#/media/File:Message_Broker.png>. Acesso em: 13 Jun. 2020.

Publish and Subscribe (Topics)

Em um sistema do tipo publish/subscribe, os produtores enviam mensagens sobre um tópico. Nesse modelo, o produtor é conhecido como editor e o consumidor é conhecido como assinante. Um ou muitos editores podem publicar no mesmo tópico, e uma mensagem de vários editores pode ser recebida por muitos assinantes. Os assinantes assinam tópicos, e todas as mensagens publicadas no tópico são recebidas por todos os assinantes no tópico. Esse modelo fornece entrega simples orientada a interesses, com base nos tópicos em que os aplicativos se inscrevem (G. Cugola, A. Margara and M. Migliavacca - 2009).

Point-to-Point (Queues)

As comunicações ponto a ponto, na sua forma mais simples, têm um produtor e um consumidor. Esse estilo de mensagem geralmente usa uma fila para armazenar mensagens enviadas pelo produtor até que sejam recebidas pelo consumidor. O produtor da mensagem envia a mensagem para a fila; o consumidor da mensagem recupera mensagens da fila e envia uma confirmação de que a mensagem foi recebida. Mais de um produtor pode enviar mensagens para a mesma fila e mais de um consumidor pode recuperar mensagens da mesma fila. Quando vários consumidores são usados, cada consumidor geralmente recebe uma parte do fluxo de mensagens para permitir o processamento simultâneo (Järvelä, A., & Lindmark, S. - 2019).

Portanto, foi necessária buscar na literatura os serviços de mensagerias mais utilizados na comunidade, realizar uma análise sobre as características de cada um, para que possamos escolher o que melhor se adequa a nossas pretensões.

2.5.1.1 Redis

O Redis é um software de código aberto de armazenamento de estrutura de dados em memória, usado como banco de dados, cache e mediador de mensagens. Ele suporta estruturas de dados como strings, hashes, listas, conjuntos, conjuntos classificados com consultas de intervalo, bitmaps, hiperloglog, índices geoespaciais com consultas e fluxos de raio. O Redis possui replicação embutida, scripts Lua, descarte de mensagens mais antigas (less recently used - LRU), transações e diferentes níveis de persistência em disco

e fornece alta disponibilidade via Redis Sentinel e particionamento automático com Redis Cluster (RedisLabs - 2017).

Ele trabalha com um conjunto de dados na memória. Dependendo do seu caso de uso, você pode persistir um conjunto de dados no disco de vez em quando ou escrevendo cada comando a um log. A persistência pode ser opcionalmente desabilitada, se você precisar apenas de um cache rico em recursos, em rede, na memória.

O Redis também suporta replicação assíncrona trivial de configuração

master-slave, com primeira sincronização muito rápida, reconexão automática com

ressincronização parcial na divisão da rede. 2.5.1.2 RabbitMQ

O RabbitMQ é um software open source de mensageria. Fornece uma forma de comunicação assíncrona de dados entre processos, aplicações ou servidores. É um dos

brokers de mensagens mais utilizados e implementa o protocolo AMQP Advanced

Message Queueing Protocol. O AMQP nasceu da necessidade de interoperabilidade de

diferentes middlewares de mensagens assíncronas. Sendo mais específico, embora existissem vários padrões de middleware para mensagens síncronas (por exemplo, IIOP, RMI, SOAP, etc.), o mesmo não se aplicava ao mundo das mensagens assíncronas, além de vários produtos proprietários usarem seus próprios protocolos fechados, por exemplo, IBM Websphere MQ e Microsoft Message Queuing (S. Vinoski - 2006).

O RabbitMQ vai além das garantias da AMQP em vários aspectos: possui um mecanismo de reconhecimento mais eficiente para os editores, um comportamento transacional mais bem definido, um melhor suporte à transferência assíncrona de lotes, um certo grau de engajamento entre produtores e consumidores (RabbitMQ - 2020).

Este sistema de mensageria é implementado em Erlang, o que implica que ele usa o Actor Model (modelo de atores) como comunicação primária entre processos Erlang. Portanto, ele se beneficia da infraestrutura da Open Telecom Platform (OTP) dessa linguagem, que facilita muito a criação e o gerenciamento de arquiteturas de alta disponibilidade. Erlang e o modelo de ator são as principais razões para os recursos de escalabilidade do RabbitMQ em termos de número de tópicos e filas, e trazem recursos de cluster com uma sobrecarga muito baixa (RabbitMQ - 2020).

2.5.1.3 Apache Kafka

O Apache Kafka é uma plataforma distribuída de transmissão de dados que é capaz de publicar, subscrever, armazenar e processar fluxos de registro em tempo real. Essa plataforma foi desenvolvida para processar fluxos de dados provenientes de diversas fontes, bem como para entregá-los a vários clientes. Em resumo, o Apache Kafka movimenta volumes imensos de dados não apenas do ponto A ao ponto B, mas também de A a Z e para qualquer outro local que você precisar simultaneamente.

Ele é uma alternativa aos sistemas de mensageria corporativos tradicionais que, inicialmente, foi desenvolvido pela LinkedIn para processar 1,4 trilhão de mensagens por dia, mas agora é uma solução de transmissão de dados open source aplicável a variadas necessidades corporativas (K. Goodhope - 2012).

Comparado aos sistemas tradicionais de publish/subscribe (pub/sub), a noção de consumidor do Kafka é generalizada como um grupo de processos cooperativos em execução como um cluster. Cada mensagem no tópico é entregue a um consumidor em cada um desses grupos de consumidores. Como resultado, a partição é a unidade de paralelismo do tópico e controla o paralelismo máximo dos consumidores. Além disso, como cada partição possui um único consumidor em seu grupo, o processo de consumo pode preguiçosamente registrar sua própria posição, em vez de marcar cada mensagem imediatamente, o que é essencial para o desempenho. Se o processo travar antes que a posição seja registrada, apenas reprocessará um pequeno número de mensagens.

2.5.1.4 Análise sobre os serviços de mensageria

Segundo Itzkovich (2019), para escolher um broker que irá trabalhar executando tarefas assíncronas, devemos levar em consideração as seguintes características:

Broker Scale: o número de mensagens enviadas por segundo no sistema; Data persistency: capacidade de recuperar mensagens;

Consumer Capability: capacidade do broker em gerenciar mensagens um para um e/ou um para muitos.

A Tabela 1 apresenta um comparativo das características dos brokers para subsidiar o processo de escolha. As informações coletadas levam em consideração

informações de documentação oficial dos softwares em questão, e informações comparativas realizadas por Itzkovich (2019).

Tabela 1 - Análises sobre os serviços de mensageria

Broker Broker Scale Data Persistency Consumer Capability Redis pode enviar até um

milhão de mensagens por segundo basicamente não, é um armazenamento em memória suporta ambos Apache Kafka

pode enviar até milhões de mensagens por segundo

sim suporta apenas um para

muitos RabbitMQ a estimativa é de cerca de 50k de mensagens por segundo são suportadas mensagens persistentes e transitórias suporta ambos

Fonte: Elaborada pelo autor baseada nas informações de Itzkovich (2019).

2.5.2 Discussão sobre as análises

O Kafka se mostrou um serviço de mensageria de alto desempenho, com a capacidade de armazenamento de uma grande quantidade de dados por um longo período. Ele é ideal para situações em que o fluxo de mensagens é extremamente alto. Dada as características observadas e considerando o contexto do trabalho, esse broker seria subutilizado na solução do problema.

O Redis tem características semelhantes ao Kafka, suportando milhões de mensagens por segundo, além de ter muitos outros recursos, como um sistema de cache em memória. Na tabela de comparação entre as ferramentas de mensageria, podemos observar que o Redis persiste seus dados em memória, e isso pode ser um problema, segundo FARIA (2019). Essa caracter stica de manter os dados em mem ria perfeita para processamento de dados em tempo real, mas, em casos de shutdown, a chance de perda de mensagens muito grande . Logo, embora o Redis possua recursos para ser uma escolha interessante para o projeto, assim como o Kafka, seria subutilizado para o que pretendemos. Outro ponto em desfavor é o fato da persistência em memória, onde não podemos aceitar uma chance tão grande de perda de mensagens.

O RabbitMQ é um broker mais antigo, porém maduro e com muitos recursos. Ele também suporta comunicação de roteamento complexo quando a taxa necessária não é alta (mais do que algumas dezenas de milhares de mensagens por segundo). O protocolo

AMQP, que é implementado pelo RabbitMQ, permite a troca de mensagens assíncronas entre diferentes aplicações e/ou serviços. Por persistir seus dados, é resiliente a falhas de qualquer ponto do sistema. Devido a essas características, vamos utilizá-lo neste trabalho como parte integrante do projeto.