Entendendo os Corretores de Mensagens. Aprendendo a mecânica das mensagens através do ActiveMQ e Kafka. Capítulo 1

Olá pessoal!

Começou a traduzir um pequeno livro:
" Entendendo os Message Brokers ",
autor: Jakub Korab, editor: O'Reilly Media, Inc., data de publicação: junho de 2017, ISBN: 9781492049296.

Desde a introdução do livro:
"... Este livro ensinará você a falar sobre sistemas de mensagens em corretores comparando e contrastando duas tecnologias populares de corretores: Apache ActiveMQ e Apache Kafka. Aqui você encontrará exemplos de incentivos de uso e desenvolvimento que levaram seus desenvolvedores a usar abordagens completamente diferentes para na mesma área - envio de mensagens entre sistemas com um intermediário intermediário. Analisaremos essas tecnologias do zero e destacaremos a influência de várias opções de design ao longo do caminho. Você obterá um entendimento profundo dos dois produtos, uma compreensão de como eles devem e não devem ser usados, e uma compreensão do que procurar ao considerar outras tecnologias de mensagens no futuro ... "

Peças traduzidas até a data:
Capítulo 1. Introdução
Capítulo 2. ActiveMQ
Capítulo 3. Kafka

Tradução concluída: tele.gg/middle_java

Vou postar os capítulos completos à medida que forem traduzidos.

CAPÍTULO 1

1. Introdução

As mensagens entre sistemas são uma das áreas menos compreendidas da TI. Como desenvolvedor ou arquiteto, você pode estar familiarizado com várias estruturas e bancos de dados. No entanto, é provável que você tenha apenas um conhecimento passageiro de como as tecnologias de mensagens baseadas em broker funcionam. Se você se sente assim, não se preocupe, está em boa companhia.

As pessoas geralmente têm contato muito limitado com a infraestrutura de mensagens. Muitas vezes, eles se conectam a um sistema criado há muito tempo ou fazem o download de um kit de distribuição da Internet, instalam-no no PROM e começam a escrever o código para ele. Após o lançamento da infraestrutura no PROM, os resultados podem ser misturados: perda de mensagens durante falhas, o envio não funciona como o esperado ou os corretores "suspendem" seus produtores ou não enviam mensagens para seus consumidores.

Parece familiar?

Um cenário comum é quando seu código de mensagens funciona bem, por enquanto. Até parar de funcionar. Esse período acalma a vigilância e dá uma falsa sensação de segurança, o que leva a ainda mais código baseado em idéias falsas sobre o comportamento fundamental da tecnologia. Quando algo começa a dar errado, você se depara com uma verdade desconfortável: que realmente não entendeu o comportamento básico do produto ou os compromissos escolhidos pelos autores, como desempenho versus confiabilidade ou transacionalidade versus escalabilidade horizontal.

Sem uma compreensão profunda de como os corretores funcionam, as pessoas fazem declarações aparentemente razoáveis ​​sobre seus sistemas de mensagens, como:

• O sistema nunca perderá mensagens
• As mensagens serão processadas sequencialmente
• A adição de consumidores tornará o sistema mais rápido
• As mensagens serão entregues apenas uma vez.

Infelizmente, algumas dessas declarações são baseadas em suposições que se aplicam apenas em determinadas circunstâncias, enquanto outras são simplesmente incorretas.

Este livro ensinará como falar sobre sistemas de mensagens baseados em broker comparando e contrastando duas tecnologias populares de broker: Apache ActiveMQ e Apache Kafka. Aqui, descreveremos exemplos de incentivos de uso e desenvolvimento que levaram seus desenvolvedores a usar abordagens completamente diferentes para o mesmo campo - mensagens entre sistemas com um intermediário intermediário. Examinaremos essas tecnologias do zero e destacaremos o impacto de várias opções de design ao longo do caminho. Você obterá um profundo entendimento de ambos os produtos, um entendimento de como eles devem e não devem ser usados ​​e um entendimento do que procurar ao considerar outras tecnologias de mensagens no futuro.

Antes de começarmos, vamos ao básico.

O que é um sistema de mensagens e por que é necessário

Para que dois aplicativos se comuniquem, eles devem primeiro definir uma interface. A definição dessa interface inclui a seleção de um transporte ou protocolo, como HTTP, MQTT ou SMTP, e a negociação dos formatos de mensagens que os sistemas trocarão. Pode ser um processo rigoroso, como definir um esquema XML com os requisitos de carga útil de uma mensagem ou pode ser muito menos formal, por exemplo, um acordo entre dois desenvolvedores de que alguma parte da solicitação HTTP conterá um identificador de cliente .

Enquanto o formato da mensagem e a ordem de envio entre os sistemas forem consistentes, eles poderão interagir entre si sem se preocupar com a implementação de outro sistema. As partes internas desses sistemas, como uma linguagem de programação ou estrutura usada, podem mudar com o tempo. Enquanto o contrato em si for suportado, a interação poderá continuar inalterada do outro lado. Os dois sistemas são efetivamente desconectados (separados) por essa interface.

Os sistemas de mensagens, como regra, prevêem a participação de um intermediário entre dois sistemas que interagem para liberar ainda mais (separar) o remetente do destinatário ou destinatários. Ao mesmo tempo, o sistema de mensagens permite que o remetente envie uma mensagem sem saber onde está o destinatário, se ele está ativo ou quantos estão.

Vejamos algumas analogias das variedades de problemas que um sistema de mensagens resolve e introduzimos alguns termos básicos.

Ponto a ponto

Alexandra vai ao correio para enviar um pacote a Adam. Ela caminha até a janela e entrega um pacote ao empregado. O funcionário pega o pacote e entrega um recibo a Alexandra. Adam não precisa estar em casa no momento do envio do pacote. Alexandra está confiante de que o pacote será entregue a Adam em algum momento no futuro e poderá continuar fazendo suas próprias coisas. Mais tarde, em algum momento, Adam recebe o pacote.

Este é um exemplo de um modelo de mensagens ponto a ponto . Os correios aqui atuam como um mecanismo de distribuição de encomendas, garantindo que cada encomenda seja entregue uma vez. O uso dos correios separa o ato de enviar o pacote da entrega do pacote.
Nos sistemas de mensagens clássicos, o modelo ponto a ponto é implementado através de filas . A fila atua como um buffer FIFO (primeiro a entrar, primeiro a sair) no qual um ou mais consumidores podem se inscrever. Cada mensagem é entregue a apenas um dos consumidores inscritos . As filas geralmente tentam distribuir mensagens de maneira justa entre os consumidores. Apenas um consumidor receberá esta mensagem.

O termo "durável" é aplicado às filas. A confiabilidade é um recurso do serviço que garante que o sistema de mensagens salve as mensagens quando não houver assinantes ativos até que o consumidor assine a fila para entrega de mensagens.

Confiabilidade é frequentemente confundida com persistência e, embora os dois termos sejam usados ​​de forma intercambiável, eles executam funções diferentes. A persistência determina se a mensagem é trocada pelo sistema de mensagens em qualquer tipo de armazenamento entre o recebimento e o envio ao consumidor. As mensagens enviadas para a fila podem ou não ser persistentes.
As mensagens ponto a ponto são usadas quando um caso de uso requer uma ação única com uma mensagem. Um exemplo é depositar fundos em uma conta ou concluir uma ordem de entrega. Discutiremos mais tarde por que o próprio sistema de mensagens não é capaz de fornecer entrega única e por que as filas podem, na melhor das hipóteses, fornecer uma garantia de entrega pelo menos uma vez .

Assinante do editor

Gabriella disca o número da conferência. Enquanto está conectada à conferência, ela ouve tudo o que o orador diz, junto com os outros participantes da chamada. Quando ela desliga, ela pula o que é dito. Quando reconectada, ela continua a ouvir o que eles dizem.

Este é um exemplo de um modelo de mensagens de publicação-assinatura . A conferência atua como um mecanismo de transmissão. A pessoa que fala não se importa com quantas pessoas estão participando da chamada no momento - o sistema garante que qualquer pessoa conectada no momento ouça o que está sendo dito.
Nos sistemas de mensagens clássicos, o modelo de mensagens de publicação-assinatura é implementado por meio de tópicos . O tópico fornece o mesmo método de transmissão que o mecanismo de conferência. Quando uma mensagem é enviada ao tópico, ela é distribuída a todos os usuários inscritos .

Os tópicos geralmente não são confiáveis ​​(não duráveis) . Como um ouvinte que não ouve o que é dito na chamada em conferência, quando o ouvinte é desconectado, os assinantes do tópico ignoram todas as mensagens enviadas quando estão offline. Por esse motivo, pode-se dizer que os tópicos fornecem uma garantia de entrega não mais que uma vez para cada consumidor.

O sistema de mensagens com assinatura de publicação geralmente é usado quando as mensagens são de natureza informativa e a perda de uma mensagem não é particularmente significativa. Por exemplo, um tópico pode transmitir leituras de temperatura de um grupo de sensores uma vez por segundo. Um sistema que esteja interessado na temperatura atual e que assine o tópico não se preocupará se perder uma mensagem - outro chegará no futuro próximo.

Modelos híbridos

O site da loja coloca as mensagens do pedido na fila de mensagens. O principal consumidor dessas mensagens é o sistema executivo. Além disso, o sistema de auditoria deve ter cópias dessas mensagens de pedido para rastreamento subsequente. Ambos os sistemas não podem ignorar mensagens, mesmo se os sistemas em si não estiverem disponíveis por algum tempo. Um site não deve estar ciente de outros sistemas.

Os cenários de uso geralmente exigem a combinação de modelos de mensagens de publicação-assinatura e ponto a ponto, por exemplo, quando vários sistemas exigem uma cópia da mensagem e confiabilidade e persistência são necessárias para evitar a perda de mensagens.

Nesses casos, é necessário um destino (um termo geral para filas e tópicos), que distribui as mensagens principalmente como tópico, para que cada mensagem seja enviada para um sistema separado que esteja interessado nessas mensagens, mas também no qual cada sistema possa definir vários consumidores que recebem mensagens recebidas, mais parecidas com uma fila. O tipo de leitura neste caso é uma vez para cada parte interessada . Esses destinatários híbridos geralmente exigem durabilidade; portanto, se o consumidor for desconectado, as mensagens enviadas nesse momento serão recebidas após a reconexão do consumidor.

Os modelos híbridos não são novos e podem ser usados ​​na maioria dos sistemas de mensagens, incluindo o ActiveMQ (através de destinos virtuais ou compostos que combinam tópicos e filas) e o Kafka (implicitamente, como uma propriedade fundamental do design de seu destinatário).

Agora que temos uma terminologia básica e um entendimento do que um sistema de mensagens pode ser útil, vamos aos detalhes.

Tradução concluída: tele.gg/middle_java

Próxima parte: Capítulo 2. ActiveMQ

Para continuar ...