Olá a todos!
Comecei a traduzir um pequeno livro:
««,
autor: Jakub Korab, editor: O'Reilly Media, Inc., data de publicação: junho de 2017, ISBN: 9781492049296.
Da introdução do livro:
"... Este livro ensinará como pensar sobre sistemas de mensagens de corretores, comparando e contrastando duas tecnologias de corretoras populares: Apache ActiveMQ e Apache Kafka. Ele descreverá os casos de uso e os incentivos ao desenvolvimento que levaram seus desenvolvedores a adotar abordagens muito diferentes para a mesma área – mensagens entre sistemas com um corretor intermediário. Analisaremos essas tecnologias desde o início e destacaremos o impacto de várias opções de design ao longo do caminho. Você obterá uma compreensão profunda de ambos os produtos, uma compreensão de como eles devem ou não ser usados e uma compreensão do que procurar ao considerar outras tecnologias de mensagens no futuro. ... "
Partes traduzidas até agora:
Postarei os capítulos concluídos à medida que forem traduzidos.
CAPÍTULO 1
Introdução
As mensagens de sistema para sistema são uma das áreas menos compreendidas da TI. Como desenvolvedor ou arquiteto, você pode estar familiarizado com vários frameworks e bancos de dados. No entanto, é provável que você tenha apenas uma familiaridade superficial com o funcionamento das tecnologias de mensagens baseadas em corretores. Se você se sente assim, não se preocupe, você está em boa companhia.
As pessoas normalmente têm contato muito limitado com a infraestrutura de mensagens. Freqüentemente, eles se conectam a um sistema criado há muito tempo ou baixam uma distribuição da Internet, instalam-na no PROM e começam a escrever código para ela. Após rodar a infraestrutura em PROM, os resultados podem ser mistos: mensagens são perdidas por falhas, o envio não funciona como você esperava, ou os corretores “travam” seus produtores ou não enviam mensagens aos seus consumidores.
Soa familiar?
Um cenário comum é aquele em que seu código de mensagens funciona bem, por enquanto. Até parar de funcionar. Este período acalma a guarda com uma falsa sensação de segurança, levando a mais códigos baseados em falsas crenças sobre o comportamento fundamental da tecnologia. Quando as coisas começam a dar errado, você se depara com uma verdade inconveniente: que você realmente não entendeu o comportamento subjacente do produto ou as compensações escolhidas pelos autores, como desempenho versus confiabilidade, ou transacionalidade versus escalabilidade horizontal .
Sem uma compreensão profunda de como funcionam os corretores, as pessoas fazem declarações aparentemente razoáveis sobre os seus sistemas de mensagens, tais como:
- O sistema nunca perderá mensagens
- As mensagens serão processadas sequencialmente
- Adicionar consumidores tornará o sistema mais rápido
- As mensagens serão entregues apenas uma vez
Infelizmente, algumas destas declarações baseiam-se em suposições que só se aplicam em determinadas circunstâncias, enquanto outras são simplesmente incorretas.
Este livro ensinará como pensar sobre sistemas de mensagens baseados em corretores, comparando e contrastando duas tecnologias de corretoras populares: Apache ActiveMQ e Apache Kafka. Ele descreverá os casos de uso e os incentivos ao desenvolvimento que levaram seus desenvolvedores a adotar abordagens muito diferentes para a mesma área – mensagens entre sistemas com um corretor intermediário. Analisaremos essas tecnologias desde o início e destacaremos o impacto de várias opções de design ao longo do caminho. Você obterá uma compreensão profunda de ambos os produtos, uma compreensão de como eles devem ou não ser usados e uma compreensão do que procurar ao considerar outras tecnologias de mensagens no futuro.
Antes de começarmos, vamos repassar o 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 desta interface envolve a seleção de um transporte ou protocolo, como HTTP, MQTT ou SMTP, e a negociação dos formatos de mensagens que serão trocadas entre os sistemas. Este pode ser um processo rigoroso, como definir um esquema XML com requisitos de custo de carga útil da mensagem, ou pode ser muito menos formal, como um acordo entre dois desenvolvedores de que alguma parte da solicitação HTTP conterá o identificador do cliente.
Desde que o formato das mensagens e a ordem em que são enviadas sejam consistentes entre os sistemas, eles poderão comunicar-se entre si sem se preocupar com a implementação do outro sistema. Os componentes internos desses sistemas, como a linguagem de programação ou estrutura utilizada, podem mudar com o tempo. Enquanto o contrato em si for mantido, a interação pode continuar sem alterações por parte do outro lado. Os dois sistemas são efetivamente desacoplados (separados) por esta interface.
Os sistemas de mensagens normalmente envolvem um intermediário entre dois sistemas que interagem para desacoplar (separar) ainda mais o remetente do destinatário ou destinatários. Neste caso, o sistema de mensagens permite ao remetente enviar uma mensagem sem saber onde está o destinatário, se está ativo ou quantas instâncias existem.
Vejamos algumas analogias para os tipos 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 para Adam. Ela vai até a janela e entrega o pacote ao funcionário. A funcionária pega o pacote e entrega um recibo a Alexandra. Adam não precisa estar em casa quando o pacote for enviado. Alexandra está confiante de que o pacote será entregue a Adam em algum momento no futuro e poderá continuar cuidando de seus negócios. Mais tarde, em algum momento, Adam recebe um pacote.
Este é um exemplo de 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. A utilização dos correios separa o ato de envio de um 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) que pode ser assinado por um ou mais consumidores. Cada mensagem é entregue apenas para um dos consumidores inscritos. As filas normalmente tentam distribuir mensagens de forma justa entre os consumidores. Apenas um consumidor receberá esta mensagem.
O termo “durável” é aplicado a filas. Confiança é uma propriedade de serviço que garante que o sistema de mensagens persistirá as mensagens na ausência de assinantes ativos até que um consumidor se inscreva na fila para entregar mensagens.
Confiabilidade é muitas vezes confundida com persistência e embora os dois termos sejam usados indistintamente, eles desempenham funções diferentes. A persistência determina se o sistema de mensagens grava uma mensagem em algum tipo de armazenamento entre recebê-la e enviá-la ao consumidor. As mensagens enviadas para a fila podem ou não ser persistentes.
Mensagens ponto a ponto são usadas quando o caso de uso requer uma ação única na mensagem. Os exemplos incluem depositar fundos em uma conta ou concluir um pedido de entrega. Discutiremos mais tarde por que o sistema de mensagens por si só não é capaz de fornecer entrega única e por que as filas podem, na melhor das hipóteses, fornecer garantia de entrega pelo menos uma vez.
Editor-Assinante
Gabriella disca o número da conferência. Enquanto ela está conectada à conferência, ela ouve tudo o que o palestrante diz, junto com o restante dos participantes da chamada. Quando ela desliga, ela perde o que é dito. Quando reconectada, ela continua a ouvir o que está sendo dito.
Este é um exemplo de modelo de mensagens publicar-assinar. A chamada em conferência atua como um mecanismo de transmissão. A pessoa que fala não se importa com quantas pessoas estão na chamada - o sistema garante que qualquer pessoa conectada ouvirá o que está sendo dito.
Nos sistemas de mensagens clássicos, o modelo de mensagens publicar-assinar é implementado por meio de tops. O tópico fornece o mesmo método de transmissão que o mecanismo de conferência. Quando uma mensagem é enviada para um tópico, ela é distribuída para todos os usuários inscritos.
Os tópicos geralmente são não confiável (não durável). Assim como um ouvinte que não consegue ouvir o que é dito em uma teleconferência quando se desconecta, os assinantes do tópico perdem qualquer mensagem enviada enquanto estão offline. Por isso, podemos dizer que os tópicos oferecem garantia de entrega não mais de uma vez para cada consumidor.
As mensagens de publicação-assinatura são normalmente usadas 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 está interessado na temperatura atual e que assina um tópico não se preocupará se perder uma mensagem – outra chegará em um futuro próximo.
modelos híbridos
O site da loja coloca mensagens de pedidos em uma “fila de mensagens”. O principal consumidor destas mensagens é o sistema executivo. Além disso, o sistema de auditoria deve ter cópias dessas mensagens de pedidos para posterior rastreamento. Ambos os sistemas não podem permitir a passagem de mensagens, mesmo que os próprios sistemas fiquem indisponíveis por algum tempo. O site não deve ter conhecimento de outros sistemas.
Os casos de uso geralmente exigem uma combinação de modelos de mensagens de publicação-assinatura e ponto a ponto, como quando vários sistemas exigem uma cópia de uma mensagem e tanto a confiabilidade quanto a persistência são necessárias para evitar a perda de mensagens.
Esses casos requerem um destino (termo geral para filas e tópicos) que distribua mensagens basicamente como um tópico, de forma que cada mensagem seja enviada para um sistema separado interessado nessas mensagens, mas também em que cada sistema possa definir vários consumidores que recebem mensagens recebidas. mensagens, que é mais como uma fila. O tipo de leitura neste caso é uma vez para cada parte interessada. Esses destinos híbridos geralmente exigem durabilidade para que, se um consumidor ficar offline, as mensagens enviadas naquele momento sejam recebidas após o consumidor se reconectar.
Os modelos híbridos não são novos e podem ser usados na maioria dos sistemas de mensagens, incluindo tanto o ActiveMQ (por meio de destinos virtuais ou compostos que combinam tópicos e filas) quanto o Kafka (implicitamente, como uma propriedade fundamental do design de seu destino).
Agora que temos alguma terminologia básica e uma compreensão de para que poderíamos usar um sistema de mensagens, vamos aos detalhes.
Tradução feita:
A seguinte parte traduzida:
Para ser continuado ...
Fonte: habr.com