Padrão Editor-Assinante

Permita que uma aplicação anuncie os eventos para vários consumidores interessados de forma assíncrona, sem acoplar os remetentes aos destinatários.

Também chamado: Mensagens pub/sub

Contexto e problema

Em aplicativos distribuídos e baseados em nuvem, os componentes do sistema geralmente precisam fornecer informações para outros componentes à medida que os eventos acontecem.

As mensagens assíncronas são uma maneira eficaz de separar remetentes de consumidores e evitar bloquear o remetente para aguardar uma resposta. No entanto, o uso de uma fila de mensagens dedicada para cada consumidor não é dimensionado efetivamente para muitos consumidores. Além disso, alguns dos consumidores podem estar interessados apenas num subconjunto da informação. Como pode o remetente anunciar eventos a todos os consumidores interessados sem conhecer as suas identidades?

Solução

Introduza um subsistema de mensagens assíncrono que inclua o seguinte:

• Um canal de mensagens de entrada usado pelo remetente. O remetente empacota eventos em mensagens, usando um formato de mensagem conhecido, e envia essas mensagens através do canal de entrada. O remetente nesse padrão também é chamado de editor.

  Nota

  Uma mensagem é um pacote de dados. Um evento é uma mensagem que notifica outros componentes sobre uma alteração ou uma ação que ocorreu.

• Um canal de mensagens de saída por consumidor. Os consumidores são conhecidos como assinantes.

• Um mecanismo para copiar cada mensagem do canal de entrada para os canais de saída para todos os assinantes interessados nessa mensagem. Essa operação geralmente é manipulada por um intermediário, como um agente de mensagens ou barramento de eventos.

O diagrama a seguir mostra os componentes lógicos desse padrão:

As mensagens pub/sub têm os seguintes benefícios:

• Ele separa subsistemas que ainda precisam se comunicar. Os subsistemas podem ser geridos de forma independente e as mensagens podem ser geridas corretamente mesmo que um ou mais recetores estejam offline.

• Aumenta a escalabilidade e melhora a capacidade de resposta do remetente. O remetente pode enviar rapidamente uma única mensagem para o canal de entrada e, em seguida, retornar às suas principais responsabilidades de processamento. A infraestrutura de mensagens é responsável por garantir que as mensagens sejam entregues aos assinantes interessados.

• Melhora a fiabilidade. As mensagens assíncronas ajudam os aplicativos a continuarem a funcionar sem problemas sob cargas maiores e a lidar com falhas intermitentes de forma mais eficaz.

• Permite o processamento adiado ou agendado. Os subscritores podem esperar para receber mensagens até fora das horas de ponta, ou as mensagens podem ser encaminhadas ou processadas de acordo com um horário específico.

• Ele permite uma integração mais simples entre sistemas usando diferentes plataformas, linguagens de programação ou protocolos de comunicação, bem como entre sistemas locais e aplicativos executados na nuvem.

• Ele facilita fluxos de trabalho assíncronos em toda a empresa.

• Melhora a teestabilidade. Os canais podem ser monitorados e as mensagens podem ser inspecionadas ou registradas como parte de uma estratégia geral de teste de integração.

• Ele fornece separação de preocupações para seus aplicativos. Cada aplicativo pode se concentrar em seus recursos principais, enquanto a infraestrutura de mensagens lida com tudo o que é necessário para rotear mensagens de forma confiável para vários consumidores.

Problemas e considerações

Na altura de decidir como implementar este padrão, considere os seguintes pontos:

• Tecnologias existentes. É altamente recomendável usar produtos e serviços de mensagens disponíveis que suportem um modelo de publicação-assinatura, em vez de criar o seu próprio. No Azure, considere usar o Service Bus, Hubs de Eventos ou Grade de Eventos. Outras tecnologias que podem ser usadas para mensagens pub/sub incluem Redis, RabbitMQ e Apache Kafka.

• Tratamento de assinaturas. A infraestrutura de mensagens deve fornecer mecanismos que os consumidores possam usar para assinar ou cancelar a assinatura dos canais disponíveis.

• Segurança. A conexão com qualquer canal de mensagem deve ser restringida pela política de segurança para evitar escutas por usuários ou aplicativos não autorizados.

• Subconjuntos de mensagens. Normalmente, os subscritores só estão interessados no subconjunto das mensagens distribuídas por um editor. Os serviços de mensagens geralmente permitem que os assinantes restrinjam o conjunto de mensagens recebidas por:

  • Tópicos. Cada tópico tem um canal de saída dedicado, e cada consumidor pode se inscrever em todos os tópicos relevantes.
  • Filtragem de conteúdo. As mensagens são inspecionadas e distribuídas com base no conteúdo de cada mensagem. Cada assinante pode especificar o conteúdo em que está interessado.

• Assinantes curinga. Considere permitir que os assinantes se inscrevam em vários tópicos por meio de curingas.

• Comunicação bidirecional. Os canais num sistema de publicação-subscrição são tratados como unidirecionais. Se um assinante específico precisar enviar confirmação ou comunicar o status de volta ao editor, considere usar o padrão de solicitação/resposta. Esse padrão usa um canal para enviar uma mensagem ao assinante e um canal de resposta separado para se comunicar com o editor.

• Ordenação de mensagens. A ordem na qual as instâncias do consumidor recebem mensagens não é garantida e não reflete necessariamente a ordem em que as mensagens foram criadas. Projete o sistema para garantir que o processamento de mensagens seja idempotente para ajudar a eliminar qualquer dependência da ordem de tratamento de mensagens.

• Prioridade da mensagem. Algumas soluções podem exigir que as mensagens sejam processadas em uma ordem específica. O padrão de fila de prioridade fornece um mecanismo para garantir que mensagens específicas sejam entregues antes de outras.

• Mensagens venenosas. Uma mensagem incorretamente formada ou uma tarefa que requer acesso a recursos indisponíveis pode fazer com que uma instância de serviço falhe. O sistema deve impedir que essas mensagens sejam devolvidas à fila. Em vez disso, capture e armazene os detalhes dessas mensagens em outro lugar para que possam ser analisadas, se necessário. Alguns agentes de mensagens, como o Barramento de Serviço do Azure, oferecem suporte a isso por meio de sua funcionalidade de fila de mensagens mortas.

• Mensagens repetidas. A mesma mensagem pode ser enviada mais de uma vez. Por exemplo, o remetente pode falhar depois de publicar uma mensagem. Em seguida, uma nova instância do remetente pode iniciar e repetir a mensagem. A infraestrutura de mensagens deve implementar deteção e remoção de mensagens duplicadas (também conhecidas como de-duping) com base em IDs de mensagens, a fim de fornecer entrega de mensagens no máximo uma vez. Como alternativa, se estiver usando uma infraestrutura de mensagens que não elimine a duplicação de mensagens, verifique se a lógica de processamento de mensagens é idempotente.

• Expiração da mensagem. Uma mensagem pode ter um tempo de vida limitado. Se não for processado dentro deste período, pode deixar de ser relevante e deve ser eliminado. Um remetente pode especificar um tempo de expiração como parte dos dados na mensagem. Um recetor pode examinar essas informações antes de decidir se deseja executar a lógica de negócios associada à mensagem.

• Agendamento de mensagens. Uma mensagem pode ser temporariamente embargada e não deve ser processada até uma data e hora específicas. A mensagem não deve estar disponível para um recetor até este momento.

• Dimensionamento de assinantes. Se um determinado assinante não conseguir acompanhar a taxa de mensagens que está recebendo, use o padrão Consumidores concorrentes para dimensioná-lo.

Quando utilizar este padrão

Utilize este padrão quando:

• Um aplicativo precisa transmitir informações para um número significativo de consumidores.

• Um aplicativo precisa se comunicar com um ou mais aplicativos ou serviços desenvolvidos de forma independente, que podem usar diferentes plataformas, linguagens de programação e protocolos de comunicação.

• Uma aplicação pode enviar informações aos consumidores sem exigir respostas em tempo real dos consumidores.

• Os sistemas que estão sendo integrados são projetados para suportar um eventual modelo de consistência para seus dados.

• Um aplicativo precisa comunicar informações a vários consumidores, que podem ter requisitos de disponibilidade ou cronogramas de tempo de atividade diferentes do remetente.

Este padrão poderá não ser prático quando:

• Um aplicativo tem apenas alguns consumidores que precisam de informações significativamente diferentes do aplicativo de produção.

• Uma aplicação requer interação quase em tempo real com os consumidores.

Design da carga de trabalho

Um arquiteto deve avaliar como o padrão Editor/Assinante pode ser usado no design de sua carga de trabalho para abordar as metas e os princípios abordados nos pilares do Azure Well-Architected Framework. Por exemplo:

Como em qualquer decisão de design, considere quaisquer compensações em relação aos objetivos dos outros pilares que possam ser introduzidos com esse padrão.

Exemplo

O diagrama a seguir mostra uma arquitetura de integração corporativa que usa o Service Bus para coordenar fluxos de trabalho e a Grade de Eventos para notificar os subsistemas sobre eventos que ocorrem. Para obter mais informações, consulte Integração empresarial no Azure usando filas de mensagens e eventos.

Próximos passos

As orientações a seguir podem ser relevantes ao implementar esse padrão:

• Escolha entre os serviços do Azure que entregam mensagens.

• Asynchronous Messaging Primer (Manual Básico de Mensagens Assíncronas). As Filas de mensagens são um mecanismo de comunicação assíncrono. Se um serviço de consumidor precisar de enviar uma resposta para uma aplicação, poderá ser necessário implementar alguma forma de mensagem de resposta. O Manual Básico de Mensagens Assíncronas fornece informações sobre como implementar mensagens de pedido/resposta com filas de mensagens.

Os seguintes padrões podem ser relevantes ao implementar esse padrão:

• Padrão do observador. O padrão Publicar-Subscrever baseia-se no padrão Observador ao dissociar assuntos de observadores através de mensagens assíncronas.

• Padrão do Message Broker. Muitos subsistemas de mensagens que suportam um modelo de publicação-assinatura são implementados por meio de um agente de mensagens.

Esta postagem no blog descreve diferentes maneiras de lidar com mensagens que chegam fora de ordem.

Recursos relacionados

• O estilo de arquitetura orientada a eventos é um estilo de arquitetura que usa mensagens pub/sub.
• Processamento de mensagens idempotente
• Integração empresarial no Azure usando filas de mensagens e eventos