Comparando Message Brokers

Quando estamos usando comunicação assíncrona é comum usarmos um message broker. O broker garante comunicação entre diferentes micro-serviços é confiável e estável, que as mensagens são gerenciadas e monitoradas com um sistema que não deixa mensagens se perderem. São muitos message broker para você escolher, variando de acordo com a escala e a capacidade de dados. Por isso, compararemos os principais: RabbitMQ, Kafka e Redis.

Comunicação de Micro-serviços: Síncrono e Assíncrono

Tem dois caminhos possíveis no desenvolvimento de micro-serviços: síncrono e assíncrono. Em uma comunicação síncrona, o requisitante espera uma resposta antes de enviar uma mensagem de resposta, e isso opera como um REST utilizando o processo HTTP. Ao contrário do assíncrono, em que as mensagens são enviadas sem esperar por uma resposta, que, por sua vez, é adequada para um sistema distribuído e normalmente requer um message broker para gerenciar as mensagens.

O tipo de comunicação escolhido deve considerar diferentes parâmetros, tal como a estrutura do micro-serviço, qual o local que está sua infraestrutura, latência, escala, dependências e o propósito daquela comunicação. Comunicação assíncrona pode ser mais complicada para estabelecer e requer adição de mais componentes na stack, mas as vantagens da comunicação assíncrona se sobressai as desvantagens.

Vantagens da comunicação assíncrona

• Primeiro e mais importante, a comunicação assíncrona é não-bloqueante por definição.
• Escala melhor que uma comunicação síncrona.
• Caso o micro-serviço falhe, possui mecanismos variáveis para recuperação de dados e de modo geral melhora a verificação de erros.
• Quando usa broker voltado para um protocolo REST, ela não precisa saber como ele funciona, podendo ser adicionada em um serviço que já existe.

Escolhendo o message broker

Comunicação assíncrona é normalmente gerenciada passando por um message broker. Tem outros caminhos, mas dificilmente serão tão escaláveis e normalmente serão mais escassos e limitados.

Ao escolher uma comunicação assíncrona você deve ter em mente:

• Escala do broker: o número de mensagens enviados por segundo em um sistema.
• Persistência de dados: a habilidade de recuperar mensagens.
• Capacidade de consumo: se o broker é capaz de gerenciar o consumo de one-to-one e/ou one-to-many.

One-to-one

O message broker recebe a mensagem de uma aplicação e essa mensagem se destina apenas a uma aplicação.

One-to-many

O message broker recebe a mensagem de uma aplicação e essa mensagem deve ser distribuída para diversas aplicações.

RabbitMQ (AMQP)

Escala: baseado em configurações e recursos, consegue lidar com cerca de 50 mil mensagens por segundo.
Persistência: persistência e transmissão de mensagens são suportados.
Capacidade de consumo: one-to-one e one-to-many

Detalhes:

• Primeiro message broker
• Criado em 2007
• Open-source
• Envia mensagem ponto-a-ponto e com métodos pub-sub por implementação AMPQ, protocolo avançado de fila de mensagens.
• Suportado por diversas linguagens (Python, Java, .NET, JavaScript, Go…)

Observação:

• É esperado algum problema no modo de persistência

Kafka

Escala: pode enviar milhões de mensagens por segundo.
Persistência: sim.
Capacidade de consumo: apenas one-to-many

Detalhes:

• Criado pelo LinkedIn em 2011.
• Alta taxa de transferência (throughput).
• Baixa latência.
• Replica um serviço de pub-sub.
• Alta qualidade na troca de mensagens.
• Possui gerenciamento em SaaS como o Azure, AWS e Confluent.
• Suportado por diversas linguagens (Python, Java, .NET, JavaScript, Go…).

Redis

Escala: pode enviar milhões de mensagens por segundo.
Persistência: basicamente, não (feita em memória).
Capacidade de consumo: one-to-one e one-to-many
Detalhes:

• Um pouco diferente do RabbitMQ e do Kafka.
• Gravação de dados em memória.
• Considerado um banco noSQL de chave-valor
• Bem performático para processamento de dados em real-time.
• Inicialmente não tinha suporte pub-sub. Implementada na v5.

Message broker por casos de usos

RabbitMQ, Kafka e Redis são muito bons no que fazem, mas cada um deles tem suas característica e o melhor modo de utilização. Então há algumas recomendações de uso abaixo.

Mensagens curtas ao vivo

Alternativa: Redis

Por conta do Redis é um banco em memória, perfeito para envio de mensagens curtas e que não precisam de persistência. Inclusive, após a versão 5.0, podemos utilizar também o potencial do pub-sub.

Grande quantidade de dados

Alternativa: Kafka

O ideal para soluções que precisem garantir o armazenamento das mensagens por um tempo e tenha uma grande quantidade de dados, o ideal é utilizar o Kafka. E isso pode acarretar em um custo maior que as outras soluções levando em consideração os recursos utilizados.

Roteamento complexo

Alternativa: RabbitMQ

O ideal para caso de roteamento complexo onde a quantidade de mensagens não é acima de dezenas de milhares de requisições por segundo.

Considere sua Stack

Se você está procurando uma integração fácil e não quer manter diferentes brokers, verifique qual deles se aplica melhor à sua solução.

Por exemplo, se usa o Celery como Fila de Tarefas, seria interessante utilizar o RabbitMQ ou o Redis.