Quais são as diferenças entre o envio de mensagens empresarial e o streaming de eventos – IBM Developer

Quais são as diferenças entre o envio de mensagens empresarial e o streaming de eventos

Tecnologias de envio de mensagens empresarial, como IBM MQ, RabbitMQ e ActiveMQ, fazem a comunicação assíncrona dentro de aplicativos e entre aplicativos há muitos anos. Recentemente, tecnologias de streaming de eventos (como o Apache Kafka) cresceram em popularidade. Eles também fornecem comunicação assíncrona.

Desenvolvedores e arquitetos podem presumir, incorretamente, que uma troca entre esses dois tipos de tecnologias é algo trivial ou razoável. Como ocorre em muitas situações, depois que você se aprofunda e realmente entende por que essas tecnologias foram criadas, bem como para quais casos de uso cada uma é adequada, logo fica evidente que as tecnologias de envio de mensagens empresarial e as tecnologias de streaming de eventos são, na verdade, complementares, e não concorrentes.

Neste artigo, analisaremos dois casos de uso assíncronos, ‘solicitação de processamento’ e ‘dados empresariais de acesso’, com o objetivo de ajudar você a entender melhor as tecnologias de envio de mensagens empresarial e streaming de eventos. Em seguida, falaremos sobre os principais recursos a considerar no momento de selecionar a tecnologia certa para sua solução de comunicação assíncrona.

Casos de uso assíncronos

Para entender quando usar qual tecnologia, vamos começar com os casos de uso relacionados à comunicação assíncrona:

  • Solicitação de processamento: esse caso de uso tem um aplicativo que faz uma solicitação a outro sistema ou serviço para concluir uma ação. O resultado poderá ser a devolução de uma mensagem de resposta ao solicitante. Esse padrão existe desde o início da TI e é provável que continue entre nós para sempre. Para uma comunicação síncrona com baixa qualidade de serviço, o HTTP é a escolha natural em função da disponibilidade da tecnologia. Já o envio de mensagens assíncrono é a escolha natural para a comunicação crítica. Para mais discussões sobre quando usar a comunicação síncrona e a assíncrona, leia o artigo “Uma introdução a APIs e ao envio de mensagens“.

  • Dados empresariais de acesso: nesse caso de uso, os componentes dentro da empresa podem emitir dados que descrevem o estado atual deles. Esses dados não contêm, normalmente, uma instrução direta para que outro sistema conclua uma ação. Em vez disso, os componentes permitem que outros sistemas obtenham insights sobre seus dados e status. Pode ser um mecanismo eficiente para distribuir e consumir dados empresariais.

Caso de uso de solicitação de processamento

As tecnologias de envio de mensagens empresarial são excelentes no caso de uso de solicitação de processamento e incluem muitos recursos que fazem delas a escolha natural:

  • Envio de mensagens de conversação. A tecnologia de envio de mensagens inclui a capacidade de concluir uma interação de solicitação/resposta. Isso permite que os aplicativos interajam em um padrão de somente solicitação (disparar e esquecer) ou de solicitação/resposta, o que for mais adequado para o cenário.
  • Entrega confiável direcionada. Quando uma mensagem é enviada, ela é deliberadamente direcionada à entidade que vai processá-la. Diferentes níveis de confiabilidade da mensagem podem ser usados, dependendo do aplicativo e da importância da mensagem. No caso da comunicação crítica, deve ser a entrega garantida do tipo somente uma vez. A entrega no máximo uma vez ou pelo menos uma vez pode ser considerada para sistemas capazes de aceitar perda ou duplicação.
  • Persistência de dados transitórios. Os dados ficam armazenados somente até o consumidor processar a mensagem ou ela expirar. Os dados não precisam de uma persistência maior do que a necessária. Esse fato é benéfico do ponto de vista dos recursos do sistema.

Caso de uso de dados empresariais de acesso

O mecanismo de publicação/assinatura (pub/sub) é central ao caso de uso de dados empresariais de acesso. Nesse mecanismo, aplicativos de publicação emitem dados a um tópico, enquanto os aplicativos de assinatura se registram em um ou mais tópicos para receber os dados do aplicativo de publicação. O mecanismo de pub/sub é responsável pela distribuição, garantindo que todos recebam os dados esperados. Ele também funciona como uma camada de abstração que permite que a disponibilidade dos aplicativos de publicação e assinatura seja diferente.

Mecanismo de publicação/assinatura

Os mecanismos de pub/sub existem há muitos anos. Por exemplo, a especificação JMS 1.0 lançada em 1998 incluía esse recurso, muitos anos antes do lançamento inicial do Apache Kafka em 2011. As tecnologias de envio de mensagens empresarial e de streaming de eventos fornecem um mecanismo de pub/sub. Isso causa confusão na hora de determinar qual é mais adequada para determinado projeto.

Muitas tecnologias de streaming de eventos fornecem esse mecanismo de pub/sub, mas também têm recursos adicionais que são ideias para casos de uso específicos, ajudando a distinguir quando uma solução de envio de mensagens empresarial pode ser útil. Por exemplo, o Apache Kafka é excelente em:

  • Histórico de stream. O Apache Kafka armazena eventos publicados em um tópico e os remove apenas quando foram configurados para expirar ou quando as limitações dos recursos do sistema foram alcançadas. Isso permite que os assinantes reproduzam eventos, não apenas os publicados mais recentemente. Trata-se da imagem espelhada da tecnologia de envio de mensagens com a característica de persistência de dados transitórios.
  • Assinaturas escaláveis. O histórico de stream permite que o Apache Kafka aumente o número de assinantes em um método leve. Cada assinante tem um ponteiro no histórico de stream do tópico que representa sua posição, o que minimiza a sobrecarga de um novo assinante. Isso libera o Apache Kafka para oferecer suporte a milhares (potencialmente dezenas de milhares) de assinantes da mesma assinatura, com o mínimo de impacto.

Escolhendo entre as tecnologias de envio de mensagens empresarial e streaming de eventos

Como descrito acima, as tecnologias de envio de mensagens empresarial e streaming de eventos têm recursos diferentes em que são excelentes, mas também possuem recursos em comum. Selecionar a tecnologia certa para sua solução é o segredo para garantir que o ajuste não seja forçado.

Para facilitar essa avaliação, considere estes critérios de seleção principais no momento de selecionar a tecnologia certa para sua solução:

  • Histórico de eventos
  • Assinaturas refinadas
  • Consumo escalável
  • Comportamento transacional

Histórico de eventos

A solução precisa ser capaz de recuperar eventos históricos, seja em situações normais e/ou de falha? Em um modelo pub/sub de envio de mensagens, o evento é publicado em um tópico. Depois de ser recebido pelo assinante, ele se torna responsável por armazenar tais informações para o futuro. Existem situações em que o modelo pub/sub pode reter a última publicação. No entanto, é certamente incomum fazer com que a tecnologia de envio de mensagens armazene eventos históricos. Para o Apache Kafka, o armazenamento do histórico de eventos é fundamental à arquitetura. Resta saber o quanto e por quanto tempo. O armazenamento desse histórico é crítico em muitos casos de uso. Em outros, pode ser indesejável do ponto de vista da segurança e dos recursos do sistema.

Assinaturas refinadas

Quando um tópico é criado no Apache Kafka, criam-se uma ou mais partições dentro da solução. Trata-se de um conceito arquitetural fundamental dentro do Apache Kafka, fornecendo a capacidade de ampliar a solução para lidar com uma enorme quantidade de eventos. Cada partição consome recursos. Normalmente, é aconselhável limitar o número de tópicos a centenas, ou talvez milhares, dentro de um único cluster.

Assinaturas refinadas

As tecnologias pub/sub de envio de mensagens têm um mecanismo mais flexível em que o tópico pode ser uma estrutura hierárquica, como /viagem/voos/companhia aérea/número do voo/assento, permitindo mais pontos de assinatura. Isso permite que os aplicativos de assinatura selecionem os eventos com uma granularidade mais fina. Além disso, seletores pub/sub de envio de mensagens podem ser usados para refinar ainda mais os eventos de interesse.

Os aplicativos que assinam sistemas pub/sub de envio de mensagens são muito menos propensos a receber eventos irrelevantes para eles. Já os aplicativos que assinam o Apache Kafka e querem apenas uma pequena proporção de eventos provavelmente precisarão que um filtro de descarte seja aplicado no início do processamento.

Consumo escalável

Se 100 consumidores assinassem todos os eventos em um tópico, uma tecnologia de envio de mensagens poderia criar 100 mensagens para cada evento publicado. É possível armazenar cada uma e, se necessário, persisti-la em disco usando os recursos do sistema. No caso do Apache Kafka, o evento é escrito uma vez e cada consumidor tem um índice correspondente a onde ele está no histórico de eventos. Os provedores de envio de mensagens, como o IBM MQ, são altamente escaláveis. Dependendo do número de eventos emitidos pelo editor e do número de assinantes, isso poderá ou não ser um fator ao decidir a tecnologia mais adequada.

Comportamento transacional

Tanto as tecnologias de envio de mensagens empresarial, como o IBM MQ, quanto as tecnologias de streaming de eventos, como o Apache Kafka, fornecem APIs transacionais para processar eventos. Porém, as duas implementações trabalham de forma diferente e, portanto, não podem ser trocadas automaticamente. O IBM MQ fornece as propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade), mas elas não são garantidas da mesma maneira no Apache Kafka. Muitas vezes, em uma solução pub/sub, o comportamento transacional específico do IBM MQ não é tão crítico quanto em um caso de uso de solicitação de processamento. Por isso, é importante estar ciente da diferença.

Resumo e próximas etapas

Em resumo, embora as tecnologias de envio de mensagens empresarial e as tecnologias de streaming de eventos possam inicialmente parecer sobrepostas, os casos de uso e os cenários em que são adequadas são diferentes. As tecnologias de envio de mensagens são excelentes no cenário de solicitação de processamento, enquanto as de streaming de eventos especializam-se em fornecer um histórico de stream a um mecanismo de pub/sub. As duas tecnologias têm uma natureza verdadeiramente complementar. Por isso, muitas vezes, os clientes precisam de ambas.

Para uma comparação mais profunda das duas tecnologias, consulte os slides “MQ e Kafka: qual é a diferença?” (e talvez assista a uma reprodução do vídeo) que foram apresentados na TechCon 2020.

É possível explorar mais artigos, tutoriais e padrões de código no IBM Developer: