Este blog faz parte da série em que discutimos 101 conceitos do Marco Zero para um público com conhecimento inicial limitado. Este artigo vem na Série de Nível Intermediário, pois envolve a compreensão dos fundamentos dos Princípios de Design de Mensagens, principalmente o caso de uso da arquitetura baseada em Editor-Assinante usada na Comunicação Assíncrona.

Alguns dos blogs anteriores da Série 101 são os seguintes:

API 101
Comunicação Assíncrona 101 Bancos de Dados 101 Projeto de Banco de Dados 101

O que é Pub Sub?

No caso de arquitetura distribuída, para desacoplar a fonte geradora de eventos da fonte receptora de eventos e desbloquear os sistemas end-2-end executados em escala, o padrão de mensagens editor-assinante é projetado para. O remetente também chamado de publicador transmite as mensagens como eventos como formato de mensagem predefinido em um agente de camada intermediária ( Kafka, EventHub, Barramento de serviço etc ) no qual assinantes únicos/múltiplos podem ouvir dependendo da política de assinatura escolhida.

O modelo Pub-Sub é compatível com casos de uso Unicast e Broadcast , ao contrário de um padrão de fila de mensagens , que é compatível apenas com casos de uso baseados em Unicast .

Termos comuns

• Publicador — Clientes que geram a mensagem e as enfileiram na Infraestrutura de Mensagens.
• Assinante — Clientes que recebem a mensagem e as enfileiram na Infraestrutura de Mensagens.
• Message Broker — A camada intermediária que lida com solicitações de publicação e leitura de mensagens de clientes variados. Ele mantém os dados replicados em um cluster na forma de tópicos entre réplicas e partições.
• Tópico — Categorias lógicas exclusivas dentro do broker que atende mensagens/eventos relacionados a um caso de uso de aplicativo/negócio específico.
• Partição — Os tópicos podem ser divididos em unidades lógicas chamadas partições para permitir o processamento paralelo de mensagens. Cada partição contém registros exclusivos identificados por deslocamentos.
• QOS- Um acordo entre o editor e o assinante que informa quantas vezes uma mensagem real deve ser entregue - pelo menos uma vez, no máximo uma vez, exatamente uma vez.

O modelo Publisher-Subscriber é utilizado para casos de uso de aplicativos que requerem grande volume de eventos gerados e a garantia imediata de mensagens não é de suma importância. Os aplicativos que se enquadram em determinados buckets são bons candidatos para esse padrão.

• Os aplicativos em que a consistência forte não é necessária para eventos entre o remetente e o destinatário e a ordenação de dados/eventos não têm impacto nos negócios. Este é um padrão de design eventualmente consistente.
• Aplicativos em que a resposta em tempo real dos assinantes não afeta o fluxo de negócios real.
• Assinantes pertencentes a diferentes tópicos são independentes e podem ter diferentes métricas de disponibilidade e tempo de atividade.

Para dimensionar um assinante de editor para os SLAs corretos de confiabilidade e disponibilidade para atender aos casos de uso de negócios de ponta a ponta, as seguintes considerações de design são recomendadas.

• Assinantes Idempotentes - Dependendo do conjunto geral de QOS e em casos de falhas, vários assinantes podem enviar a mesma mensagem mais de uma vez. Portanto, os assinantes são obrigados a manter a idempotência , ou seja, não processar mensagens repetidas mais de uma vez e ter tratamento de mensagens duplicadas.
• Ordenação de mensagens e prioridade - As mensagens podem ser processadas em uma linha do tempo diferente da sua criação, dependendo de vários fatores, como partições, grupos de consumidores. Portanto, cada mensagem deve ser independente no fluxo geral de negócios/aplicativos.
• Dead Letter Queue — Dependendo da configuração do TTL nas mensagens e da disponibilidade/tratamento de erros dos consumidores, algumas das mensagens podem acabar na Dead Letter Queue . Essas mensagens devem ser reprocessadas pelos editores para evitar qualquer impacto nos negócios.
• Segurança — Diferentes tópicos nos mediadores de mensagens devem ser políticas de autorização independentes para garantir que os clientes acidentalmente não troquem informações de um tópico diferente. Certificados de cliente e TLS mútuo são algumas boas políticas de segurança.

Resumo

Pub-Sub é um padrão de design comum e simples que é usado em sistemas distribuídos baseados em Aysnc, pois ajuda a escalar para milhões de clientes sem a necessidade de manter uma semântica de entrega complexa. No entanto, para casos de uso complexos em que as mensagens/eventos precisam ter padrões de roteamento dinâmico, outros padrões de design, como Priority Queue Based, Request-Reply Based, Queue Based Load Leveling etc. Tentaremos abordá-los nos próximos 101 blogs sobre aprendizagem de arquitetura funcional.

Para feedback, envie uma mensagem para amit[dot]894[at]gmail[dot]com ou entre em contato com qualquer um dos links em https://about.me/amit_raj .