Olá a todos!
Iniciei a tradução de um pequeno livro:
««,
autor: Jakub Korab, editora: O’Reilly Media, Inc., data de publicação: Junho de 2017, ISBN: 9781492049296.
Do prefácio do livro:
«… Este livro ensinará você a pensar sobre sistemas de troca de mensagens em brokers, comparando e contrastando duas tecnologias populares de brokers: Apache ActiveMQ e Apache Kafka. Serão apresentados exemplos de uso e motivos de desenvolvimento que levaram seus criadores a adotar abordagens completamente diferentes para a mesma área — a troca de mensagens entre sistemas com um broker intermediário. Vamos explorar essas tecnologias desde o início e destacar a influência de diversas opções de design ao longo desse caminho. Você obterá uma compreensão profunda de ambos os produtos, saberá como utilizá-los e como não utilizá-los, e entenderá o que deve ser considerado ao avaliar outras tecnologias de troca de mensagens no futuro. …»
Partes traduzidas até o momento:
Publicarei os capítulos finalizados à medida que forem traduzidos.
CAPÍTULO 1
Introdução
A troca de mensagens entre sistemas é uma das áreas menos compreendidas da TI. Como desenvolvedor ou arquiteto, você pode estar bem familiarizado com diferentes frameworks e bancos de dados. No entanto, é bastante provável que você tenha apenas um conhecimento superficial sobre como funcionam as tecnologias de troca de mensagens baseadas em brokers. Se você se sente assim, não se preocupe, você não está sozinho.
As pessoas geralmente interagem com a infraestrutura de troca de mensagens de maneira muito limitada. Muitas vezes, elas se conectam a um sistema criado há muito tempo ou baixam uma distribuição da internet, a instalam em produção e começam a escrever código para ele. Depois que a infraestrutura é implantada em produção, os resultados podem ser ambíguos: perda de mensagens em caso de falhas, o envio não funciona como esperado ou os brokers 'penduram' seus produtores ou não enviam mensagens para seus consumidores.
Soa familiar?
Um cenário comum é que seu código de troca de mensagens funciona bem, até que, de repente, para de funcionar. Esse período cria uma falsa sensação de segurança, levando a um código ainda mais amplo, baseado em representações incorretas do comportamento fundamental da tecnologia. Quando algo começa a dar errado, você se depara com a desconfortável verdade: que você realmente não entendeu o comportamento básico do produto ou os compromissos escolhidos pelos autores, como desempenho contra confiabilidade, ou transacionalidade contra escalabilidade horizontal.
Sem uma compreensão profunda de como os brokers funcionam, as pessoas fazem afirmações que parecem razoáveis sobre seus sistemas de troca de mensagens, como:
- O sistema nunca perderá mensagens
- As mensagens serão processadas de forma sequencial
- Adicionar consumidores tornará o sistema mais rápido
- As mensagens serão entregues apenas uma vez
Infelizmente, algumas dessas afirmações são baseadas em suposições que se aplicam apenas sob certas circunstâncias, enquanto outras são simplesmente falsas.
Este livro ensinará você a pensar sobre sistemas de troca de mensagens baseados em brokers, comparando e contrastando duas tecnologias populares de brokers: Apache ActiveMQ e Apache Kafka. Exemplos de uso e incentivos para o desenvolvimento que levaram seus criadores a adotarem abordagens completamente diferentes para a mesma área — a troca de mensagens entre sistemas com um broker intermediário — serão apresentados. Analisaremos essas tecnologias desde o início e destacaremos a influência de diferentes opções de design ao longo do caminho. Você obterá uma compreensão profunda de ambos os produtos, conhecimento sobre como devem e não devem ser usados, e no que prestar atenção ao considerar outras tecnologias de troca de mensagens no futuro.
Antes de começarmos, vamos revisar os fundamentos.
O que é um Sistema de troca de mensagens e por que ele é necessário
Para que dois aplicativos possam se comunicar, eles devem primeiro definir uma interface. A definição dessa interface inclui a escolha de um transporte ou protocolo, como HTTP, MQTT ou SMTP, e o acordo sobre os formatos de mensagem que os sistemas trocarão. Isso pode ser um processo rigoroso, como a definição de um esquema XML com requisitos para a carga útil da mensagem, ou pode ser muito menos formal, como um acordo entre dois desenvolvedores sobre qual parte da solicitação HTTP conterá o identificador do cliente.
Desde que o formato das mensagens e a ordem de envio entre os sistemas estejam acordados, eles poderão interagir entre si sem se preocupar com a implementação do outro sistema. Os detalhes internos desses sistemas, como a linguagem de programação ou o framework utilizado, podem mudar ao longo do tempo. Enquanto o próprio contrato for mantido, a interação pode continuar sem alterações do outro lado. Esses dois sistemas estão efetivamente desacoplados por meio dessa interface.
Sistemas de troca de mensagens geralmente envolvem um intermediário entre dois sistemas que interagem, para um maior desacoplamento do remetente dos destinatários. Assim, o sistema de troca de mensagens permite que o remetente envie uma mensagem sem saber onde o destinatário está, se ele está ativo ou quantas instâncias existem.
Vamos considerar algumas analogias que ilustram os tipos de problemas que um sistema de troca de mensagens resolve e introduzir alguns termos básicos.
Ponto a Ponto
Alexandra vai ao correio para enviar um pacote para Adam. Ela se aproxima da janela e entrega o pacote ao funcionário. O funcionário pega o pacote e entrega a Alexandra um recibo. Adam não precisa estar em casa no momento da postagem do pacote. Alexandra tem certeza de que o pacote será entregue a Adam em algum momento no futuro e pode continuar com suas atividades. Mais tarde, a qualquer momento, Adam recebe o pacote.
Este é um exemplo de um modelo de troca de mensagens ponto a ponto. O correio aqui atua como um mecanismo de distribuição de pacotes, garantindo que cada pacote seja entregue uma vez. O uso do correio separa o ato de enviar o pacote da entrega do pacote.
Em sistemas clássicos de troca de mensagens, o modelo "ponto a ponto" é implementado por meio de filas. A fila atua como um buffer FIFO (primeiro a entrar, primeiro a sair), ao qual um ou vários consumidores podem se inscrever. Cada mensagem é entregue apenas a um dos consumidores inscritos. As filas geralmente tentam distribuir as mensagens de forma justa entre os consumidores. Somente um consumidor receberá a mensagem em questão.
Ao conceito de filas se aplica o termo "duráveis". Confiabilidade — é uma propriedade do serviço que garante que o sistema de troca de mensagens irá armazenar mensagens na ausência de consumidores ativos, até que um consumidor se inscreva na fila para receber as mensagens.
A confiabilidade é frequentemente confundida com persistência , e embora esses dois termos sejam intercambiáveis, eles cumprem funções diferentes. A persistência define se a mensagem é gravada pelo sistema de troca de mensagens em algum tipo de armazenamento entre seu recebimento e seu envio ao consumidor. Mensagens enviadas para uma fila podem ou não ser persistentes.
A troca de mensagens do tipo "Ponto a Ponto" é usada quando o caso de uso exige uma única ação sobre a mensagem. Um exemplo disso seria a adição de fundos a uma conta ou a realização de um pedido de entrega. Discutiremos mais adiante por que o próprio sistema de troca de mensagens não consegue garantir uma entrega única e por que as filas podem, no melhor dos casos, oferecer uma garantia de entrega pelo menos uma vez.
Publicador-Inscritor
Gabriela disca o número da conferência. Enquanto está conectada à conferência, ela ouve tudo o que o palestrante diz, junto com os demais participantes da chamada. Quando ela se desconecta, perde o que foi dito. Ao se reconectar, ela continua a ouvir o que está sendo dito.
Este é um exemplo de um modelo de troca de mensagens publicação-assinatura. A conferência atua como um mecanismo de difusão. O falante não se preocupa com quantas pessoas estão atualmente conectadas à chamada — o sistema garante que qualquer um que se conecte nesse momento ouvirá o que está sendo dito.
Em sistemas clássicos de troca de mensagens, o modelo de troca de mensagens "publicação-assinatura" é implementado através de tópicosO tópico fornece uma forma de broadcast semelhante ao mecanismo de conferência. Quando uma mensagem é enviada para o tópico, ela é distribuída para todos os usuários inscritos.
Tópicos normalmente são não confiáveis (nondurable). Assim como um ouvinte que não escuta o que está sendo dito em uma chamada de conferência quando se desconecta, os assinantes do tópico perdem quaisquer mensagens enviadas no momento em que estão offline. Por essa razão, pode-se dizer que os tópicos oferecem garantia de entrega não mais de uma vez para cada consumidor.
As mensagens do tipo ‘publicação-assinatura’ são geralmente usadas quando as mensagens têm um caráter informativo, 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. O sistema que está interessado na temperatura atual e que se inscreve no tópico não se preocupará se perder uma mensagem — outra chegará em breve.
Modelos híbridos
O site da loja coloca mensagens de pedidos em uma ‘fila de mensagens’. O principal consumidor dessas mensagens é o sistema executor. Além disso, o sistema de auditoria deve ter cópias dessas mensagens de pedidos para rastreamento posterior. Ambos os sistemas não podem perder mensagens, mesmo que os próprios sistemas estejam indisponíveis por um tempo. O site não deve saber sobre outros sistemas.
Cenários de uso frequentemente requerem a combinação dos modelos de troca de mensagens ‘publicação-assinatura’ e ‘ponto a ponto’, por exemplo, quando vários sistemas precisam de uma cópia da mensagem, e para evitar a perda da mensagem são necessárias tanto a confiabilidade quanto a persistência.
Nesses casos, é necessário um destinatário (destination) (termo genérico para filas e tópicos), que distribui as mensagens principalmente como um tópico, de modo que cada mensagem é enviada para um sistema separado interessado nessas mensagens, mas também onde cada sistema pode definir vários consumidores que recebem as mensagens entrantes, que se assemelham mais a uma fila. O tipo de leitura, nesse caso, é uma vez para cada parte interessadaEsses endereços híbridos frequentemente exigem confiabilidade, então, se o consumidor se desconectar, as mensagens enviadas nesse momento serão recebidas após a reconexão do consumidor.
Modelos híbridos não são novos e podem ser aplicados na maioria dos sistemas de troca de mensagens, incluindo tanto ActiveMQ (através de endereços virtuais ou compostos, que combinam tópicos e filas), quanto Kafka (implicitamente, como uma propriedade fundamental do design de seu destinatário).
Agora que temos alguma terminologia básica e uma compreensão do propósito de um sistema de troca de mensagens, vamos passar para os detalhes.
Tradução realizada:
A próxima parte traduzida:
Continua…
Fonte: habr.com
