Opções de mensagens assíncronas no Azure

Este artigo descreve os diferentes tipos de mensagens e as entidades que participam de uma infraestrutura de mensagens. Com base nos requisitos de cada tipo de mensagem, o artigo recomenda os serviços de mensagens do Azure. As opções incluem o barramento de serviço do Azure, a grade de eventose os hubs de eventos.

Em um nível de arquitetura, uma mensagem é um datagrama criado por uma entidade (produtor), para distribuir informações para que outras entidades (consumidores) possam estar cientes e agir de acordo. O produtor e o consumidor podem se comunicar diretamente ou opcionalmente por meio de uma entidade intermediária (agente de mensagens). Este artigo se concentra em mensagens assíncronas usando um agente de mensagem.

Entidades que fazem parte do sistema de mensagens assíncronas

As mensagens podem ser classificadas em duas categorias principais. Se o produtor espera uma ação do consumidor, essa mensagem é um comando. Se a mensagem informar ao consumidor que uma ação foi realizada, a mensagem será um evento.

Comandos

O produtor envia um comando com a intenção de que os consumidores executarão uma operação dentro do escopo de uma transação de negócios.

Um comando é uma mensagem de alto valor e deve ser entregue pelo menos uma vez. Se um comando for perdido, toda a transação comercial poderá falhar. Além disso, um comando não deve ser processado mais de uma vez. Isso pode causar uma transação errada. Um cliente pode obter pedidos duplicados ou ser cobrado duas vezes.

Os comandos são frequentemente usados para gerenciar o fluxo de trabalho de uma transação comercial de várias etapas. Dependendo da lógica de negócios, o produtor pode esperar que o consumidor confirme a mensagem e relate os resultados da operação. Com base nesse resultado, o produtor pode escolher um curso de ação apropriado.

Eventos

Um evento é um tipo de mensagem que um produtor gera para anunciar fatos.

O produtor (conhecido como Publicador neste contexto) não tem expectativas de que os eventos resultarão em qualquer ação.

Os consumidores interessados, podem assinar, ouvir eventos e executar ações dependendo do cenário de consumo. Os eventos podem ter vários assinantes ou nenhum assinante. Dois assinantes diferentes podem reagir a um evento com ações diferentes e não estar cientes uns dos outros.

O produtor e o consumidor são livremente acoplados e gerenciados de forma independente. O consumidor não deve reconhecer o evento de volta para o produtor. Um consumidor que não está mais interessado nos eventos pode cancelar a assinatura. O consumidor é removido do pipeline sem afetar o produtor ou a funcionalidade geral do sistema.

Há duas categorias de eventos:

  • O produtor gera eventos para anunciar fatos discretos. Um caso de uso comum é A notificação de eventos. Por exemplo, Azure Resource Manager gera eventos quando cria, modifica ou exclui recursos. Um assinante desses eventos pode ser um aplicativo lógico que envia emails de alerta.

  • O produtor gera eventos relacionados em uma sequência, ou um fluxo de eventos, em um período de tempo. Normalmente, um fluxo é consumido para avaliação estatística. A avaliação pode ser feita em uma janela temporal ou quando eventos chegam. A telemetria é um caso de uso comum, por exemplo, integridade e monitoramento de carga de um sistema. Outro caso é o streaming de eventos de dispositivos IoT.

Um padrão comum para implementar o Event Messaging é o padrão Publisher-Subscriber .

Padrão de Publisher-Subscriber para mensagens de evento

Função e benefícios de um agente de mensagem

Um agente de mensagens intermediário fornece a funcionalidade de mover mensagens do produtor para o consumidor e pode oferecer benefícios adicionais.

Desacoplamento

Um agente de mensagem separa o produtor do consumidor na lógica que gera e usa as mensagens, respectivamente. Em um fluxo de trabalho complexo, o agente pode incentivar as operações de negócios a serem separadas e ajudar a coordenar o fluxo de trabalho.

Por exemplo, uma única transação de negócios requer operações distintas que são executadas em uma sequência de lógica de negócios. O produtor emite um comando que sinaliza um consumidor para iniciar uma operação. O consumidor reconhece a mensagem em uma fila separada reservada para o alinhamento de respostas para o produtor. Somente depois de receber a resposta, o produtor envia uma nova mensagem para iniciar a próxima operação na sequência. Um consumidor diferente processa essa mensagem e envia uma mensagem de conclusão para a fila de resposta. Usando o sistema de mensagens, os serviços coordenam o fluxo de trabalho da transação entre si.

Produtor-comunicação do consumidor

Um agente de mensagem fornece desacoplamento temporal. O produtor e o consumidor não precisam ser executados simultaneamente. Um produtor pode enviar uma mensagem para o agente de mensagem independentemente da disponibilidade do consumidor. Por outro lado, o consumidor não é restrito pela disponibilidade do produtor.

Por exemplo, a interface do usuário de um aplicativo Web gera mensagens e usa uma fila como o agente de mensagem. Quando estiver pronto, os consumidores poderão recuperar mensagens da fila e executar o trabalho. O desacoplamento temporal ajuda a interface do usuário a permanecer responsiva. Ele não é bloqueado enquanto as mensagens são tratadas de forma assíncrona.

Determinadas operações podem demorar muito para serem concluídas. Depois de emitir um comando, o produtor não deve esperar até que o consumidor o conclua. Um agente de mensagem ajuda o processamento assíncrono de mensagens.

Balanceamento de carga

Os produtores podem postar um grande número de mensagens que são atendidas por vários consumidores. Use um agente de mensagens para distribuir o processamento entre servidores e melhorar a taxa de transferência. Os consumidores podem ser executados em servidores diferentes para distribuir a carga. Os consumidores podem ser adicionados dinamicamente para escalar horizontalmente o sistema quando necessário ou removido de outra forma.

Padrão de consumidores concorrentes

O padrão de consumidores concorrentes explica como processar várias mensagens simultaneamente para otimizar a taxa de transferência, melhorar a escalabilidade e a disponibilidade e equilibrar a carga de trabalho.

Nivelamento de carga

O volume de mensagens geradas pelo produtor ou um grupo de produtores pode ser variável. Às vezes, pode haver um grande volume causando picos nas mensagens. Em vez de adicionar consumidores para lidar com esse trabalho, um agente de mensagens pode atuar como um buffer e os consumidores esvaziam gradualmente as mensagens em seu próprio ritmo, sem enfatizar o sistema.

Padrão de nivelamento de carga baseado em fila

O padrão de nivelamento de carga baseado em fila fornece mais informações.

Sistema de mensagens confiável

Um agente de mensagem ajuda a garantir que as mensagens não sejam perdidas mesmo se a comunicação falhar entre o produtor e o consumidor. O produtor pode postar mensagens no agente de mensagens e o consumidor pode recuperá-las quando a comunicação é restabelecida. O produtor não é bloqueado, a menos que ele perca a conectividade com o agente de mensagem.

Mensagens resilientes

Um agente de mensagens pode adicionar resiliência aos consumidores em seu sistema. Se um consumidor falhar durante o processamento de uma mensagem, outra instância do consumidor poderá processar essa mensagem. O reprocessamento é possível porque a mensagem persiste no agente.

Opções de tecnologia para um agente de mensagens

O Azure fornece vários serviços de agente de mensagens, cada um com uma variedade de recursos. Antes de escolher um serviço, determine a intenção e os requisitos da mensagem.

Barramento de Serviço do Azure

As filas do barramento de serviço do Azure são adequadas para transferir comandos de produtores para consumidores. Aqui estão algumas considerações.

Modelo de pull

Um consumidor de uma fila do barramento de serviço sonda constantemente o barramento de serviço para verificar se há novas mensagens disponíveis. Os SDKs de cliente e o gatilho de Azure Functions para o barramento de serviço abstraim esse modelo. Quando uma nova mensagem estiver disponível, o retorno de chamada do consumidor será invocado e a mensagem será enviada ao consumidor.

Entrega garantida

O barramento de serviço permite que um consumidor Inspecione a fila e bloqueie uma mensagem de outros consumidores.

É responsabilidade do consumidor reportar o status de processamento da mensagem. Somente quando o consumidor marca a mensagem como consumida, o barramento de serviço remove a mensagem da fila. Se ocorrer uma falha, um tempo limite ou falha, o barramento de serviço desbloqueará a mensagem para que outros consumidores possam recuperá-la. Dessa forma, as mensagens não são perdidas na transferência.

Um produtor pode acidentalmente enviar a mesma mensagem duas vezes. Por exemplo, uma instância de produtor falha após o envio de uma mensagem. Outro produtor substitui a instância original e envia a mensagem novamente. As filas do barramento de serviço do Azure fornecem uma funcionalidade interna duping que detecta e remove mensagens duplicadas. Ainda há uma chance de que uma mensagem seja entregue duas vezes. Por exemplo, se um consumidor falhar durante o processamento, a mensagem será retornada para a fila e será recuperada pela mesma ou por outro consumidor. A lógica de processamento de mensagens no consumidor deve ser idempotente para que, mesmo que o trabalho seja repetido, o estado do sistema não seja alterado.

Ordenação de mensagens

Se você quiser que os consumidores obtenham as mensagens na ordem em que são enviadas, as filas do barramento de serviço garantem a entrega ordenada de FIFO (primeiro a entrar, primeiro a sair) usando sessões. Uma sessão pode ter uma ou mais mensagens. As mensagens são correlacionadas com a propriedade SessionID . As mensagens que fazem parte de uma sessão, nunca expiram. Uma sessão pode ser bloqueada para um consumidor para impedir que suas mensagens sejam tratadas por um consumidor diferente.

Para obter mais informações, consulte sessões de mensagens.

Persistência de mensagem

As filas do barramento de serviço dão suporte ao desacoplamento temporal. Mesmo quando um consumidor não está disponível ou não pode processar a mensagem, ele permanece na fila.

Transações de execução longa do ponto de verificação

As transações de negócios podem ser executadas por muito tempo. Cada operação na transação pode ter várias mensagens. Use o ponto de verificação para coordenar o fluxo de trabalho e fornecer resiliência no caso de falha de uma transação.

As filas do barramento de serviço permitem o ponto de verificação por meio do recurso de estado de sessão. As informações de estado são registradas incrementalmente na fila (SetState) para mensagens que pertencem a uma sessão. Por exemplo, um consumidor pode acompanhar o andamento verificando o estado (GetState) a cada momento e depois. Se um consumidor falhar, outro consumidor poderá usar informações de estado para determinar o último ponto de verificação conhecido para retomar a sessão.

Fila de mensagens mortas (DLQ)

Uma fila do barramento de serviço tem uma subfila padrão, chamada de DLQ (fila de mensagens mortas) para manter as mensagens que não puderam ser entregues ou processadas. O barramento de serviço ou a lógica de processamento de mensagens no consumidor pode adicionar mensagens ao DLQ. O DLQ mantém as mensagens até que elas sejam recuperadas da fila.

Aqui estão exemplos de quando uma mensagem pode acabar sendo DLQ:

  • Uma mensagem suspeita é uma mensagem que não pode ser manipulada porque está malformada ou contém informações inesperadas. Em filas do barramento de serviço, você pode detectar mensagens suspeitas definindo a propriedade MaxDeliveryCount da fila. Se o número de vezes que a mesma mensagem é recebida excede o valor da propriedade, o barramento de serviço move a mensagem para o DLQ.

  • Uma mensagem poderá não ser mais relevante se não for processada dentro de um período. As filas do barramento de serviço permitem que o produtor poste mensagens com um atributo de vida útil. Se esse período expirar antes da mensagem ser recebida, a mensagem será colocada no DLQ.

Examine as mensagens no DLQ para determinar o motivo da falha.

Solução híbrida

O barramento de serviço faz a ponte entre sistemas locais e soluções de nuvem. Os sistemas locais costumam ser difíceis de alcançar devido a restrições de firewall. Tanto o produtor quanto o consumidor (podem ser locais ou a nuvem) podem usar o ponto de extremidade da fila do barramento de serviço como a retirada e a localização de redistribuição para mensagens.

Tópicos e assinaturas

O barramento de serviço dá suporte ao padrão de Publisher-Subscriber por meio de tópicos e assinaturas do barramento de serviço.

Esse recurso fornece uma maneira para o produtor transmitir mensagens para vários consumidores. Quando um tópico recebe uma mensagem, ele é encaminhado para todos os consumidores assinados. Opcionalmente, uma assinatura pode ter critérios de filtro que permitem ao consumidor obter um subconjunto de mensagens. Cada consumidor recupera mensagens de uma assinatura de forma semelhante a uma fila.

Para obter mais informações, consulte os Tópicos do barramento de serviço do Azure.

Grade de Eventos do Azure

A grade de eventos do Azure é recomendada para eventos discretos. A grade de eventos segue o padrão de Publisher-Subscriber. Quando as origens do evento disparam eventos, elas são publicadas nos Tópicos da grade de eventos. Os consumidores desses eventos criam assinaturas de grade de eventos especificando tipos de eventos e manipuladores de eventos que processarão os eventos. Se não houver nenhum assinante, os eventos serão descartados. Cada evento pode ter várias assinaturas.

Modelo de push

A grade de eventos propaga mensagens para os assinantes em um modelo de push. Suponha que você tenha uma assinatura de grade de eventos com um webhook. Quando um novo evento chega, a grade de eventos posta o evento no ponto de extremidade do webhook.

Integrado com o Azure

Escolha a grade de eventos se você quiser obter notificações sobre os recursos do Azure. Muitos serviços do Azure atuam como fontes de eventos que têm tópicos de grade de eventos internos. A grade de eventos também dá suporte a vários serviços do Azure que podem ser configurados como manipuladores de eventos. É fácil assinar esses tópicos para rotear eventos para manipuladores de eventos de sua escolha. Por exemplo, você pode usar a grade de eventos para invocar uma função do Azure quando um armazenamento de BLOBs é criado ou excluído.

Tópicos personalizados

Crie tópicos de grade de eventos personalizados, se você quiser enviar eventos de seu aplicativo ou um serviço do Azure que não esteja integrado à grade de eventos.

Por exemplo, para ver o progresso de uma transação comercial inteira, você deseja que os serviços participantes gerem eventos à medida que estão processando suas operações de negócios individuais. Um aplicativo Web mostra esses eventos. Uma maneira é criar um tópico personalizado e adicionar uma assinatura com seu aplicativo Web registrado por meio de um webhook HTTP. À medida que os serviços de negócios enviam eventos para o tópico personalizado, a grade de eventos os envia para seu aplicativo Web.

Eventos filtrados

Você pode especificar filtros em uma assinatura para instruir a grade de eventos para rotear apenas um subconjunto de eventos para um manipulador de eventos específico. Os filtros são especificados no esquema de assinatura. Qualquer evento enviado ao tópico com valores que correspondam ao filtro é encaminhado automaticamente para essa assinatura.

Por exemplo, o conteúdo em vários formatos é carregado no armazenamento de BLOBs. Cada vez que um arquivo é adicionado, um evento é gerado e publicado na grade de eventos. A assinatura de evento pode ter um filtro que envia apenas eventos para imagens para que um manipulador de eventos possa gerar miniaturas.

Para obter mais informações sobre filtragem, consulte filtrar eventos para a grade de eventos.

Alta taxa de transferência

A grade de eventos pode rotear 10 milhões eventos por segundo por região. As primeiras 100.000 operações por mês são gratuitas. Para obter considerações sobre custos, veja quanto custa a grade de eventos?

Entrega resiliente

Embora a entrega bem-sucedida de eventos não seja tão crucial quanto os comandos, você ainda pode querer alguma garantia dependendo do tipo de evento. A grade de eventos oferece recursos que você pode habilitar e personalizar, como políticas de repetição, tempo de expiração e mensagens mortas. Para obter mais informações, consulte entrega e repetição.

O processo de repetição da grade de eventos pode ajudar na resiliência, mas não é seguro. No processo de repetição, a grade de eventos pode entregar a mensagem mais de uma vez, ignorar ou atrasar algumas repetições se o ponto de extremidade não estiver respondendo por um longo tempo. Para obter mais informações, consulte repetir agendamento e duração.

Você pode persistir eventos não entregues em uma conta de armazenamento de BLOBs habilitando mensagens mortas. Há um atraso no fornecimento da mensagem para o ponto de extremidade do armazenamento de BLOBs e, se esse ponto de extremidade não estiver respondendo, a grade de eventos descartará o evento. Para mais informações, consulte Mensagens mortas e políticas de repetição.

Hubs de eventos do Azure

Ao trabalhar com um fluxo de eventos, os hubs de eventos do Azure são o agente de mensagens recomendado. Essencialmente, é um buffer grande capaz de receber grandes volumes de dados com baixa latência. Os dados recebidos podem ser lidos rapidamente por meio de operações simultâneas. Você pode transformar os dados recebidos usando qualquer provedor de análise em tempo real. Os hubs de eventos também fornecem a capacidade de armazenar eventos em uma conta de armazenamento.

Ingestão rápida

Os hubs de eventos são capazes de ingerir milhões de eventos por segundo. Os eventos são anexados apenas ao fluxo e são ordenados por tempo.

Modelo de pull

Assim como a grade de eventos, os hubs de eventos também oferecem recursos de Publisher-Subscriber. Uma diferença importante entre a grade de eventos e os hubs de eventos é a maneira como os dados de evento são disponibilizados para os assinantes. A grade de eventos envia os dados ingeridos para os assinantes, enquanto que o Hub de eventos disponibiliza os dados em um modelo de pull. À medida que os eventos são recebidos, os hubs de eventos os anexam ao fluxo. Um assinante gerencia seu cursor e pode avançar e voltar no fluxo, selecionar um deslocamento de tempo e repetir uma sequência em seu ritmo.

Os processadores de fluxo são assinantes que recebem dados dos hubs de eventos para fins de transformação e análise estatística. Use Azure Stream Analytics e Apache Spark para processamento complexo, como agregação em janelas de tempo ou detecção de anomalias.

Se você quiser agir em cada evento por partição, poderá efetuar pull dos dados usando o host de processamento de eventos ou usando o conector interno, como aplicativos lógicos , para fornecer a lógica de transformação. Outra opção é usar Azure Functions.

Particionamento

Uma partição é uma parte do fluxo de eventos. Os eventos são divididos usando uma chave de partição. Por exemplo, vários dispositivos IoT enviam dados de dispositivo para um hub de eventos. A chave de partição é o identificador do dispositivo. À medida que os eventos são ingeridos, os hubs de eventos os movem para partições separadas. Em cada partição, todos os eventos são ordenados por tempo.

Um consumidor é uma instância de código que processa os dados do evento. Os hubs de eventos seguem um padrão de consumidor particionado. Cada consumidor lê apenas uma partição específica. Ter várias partições resulta em um processamento mais rápido porque o fluxo pode ser lido simultaneamente por vários consumidores.

As instâncias do mesmo consumidor compõem um único grupo de consumidores. Vários grupos de consumidores podem ler o mesmo fluxo com intenções diferentes. Suponha que um fluxo de eventos tenha dados de um sensor de temperatura. Um grupo de consumidores pode ler o fluxo para detectar anomalias, como um pico de temperatura. Outra pode ler o mesmo fluxo para calcular uma temperatura média móvel em uma janela temporal.

Os hubs de eventos dão suporte ao padrão de Publisher-Subscriber, permitindo vários grupos de consumidores. Cada grupo de consumidores é um assinante.

Para obter mais informações sobre o particionamento do hub de eventos, consulte partições.

Capturar Hubs de Eventos

O recurso de captura permite que você armazene o fluxo de eventos em um armazenamento de BLOBs do Azure ou Data Lake Storage. Essa maneira de armazenar eventos é confiável porque, mesmo se a conta de armazenamento não estiver disponível, a captura manterá os dados por um período e, em seguida, gravará no armazenamento depois que ele estiver disponível.

Os serviços de armazenamento também podem oferecer recursos adicionais para analisar eventos. Por exemplo, aproveitando as camadas de acesso de uma conta de armazenamento de BLOBs, você pode armazenar eventos em uma camada quente para dados que precisam de acesso frequente. Você pode usar esses dados para visualização. Como alternativa, você pode armazenar dados na camada de arquivo e recuperá-los ocasionalmente para fins de auditoria.

A captura armazena todos os eventos ingeridos pelos hubs de eventos e é útil para o processamento em lotes. Você pode gerar relatórios sobre os dados usando uma função MapReduce. Os dados capturados também podem servir como a fonte de verdade. Se determinados fatos forem perdidos ao agregar os dados, você poderá consultar os dados capturados.

Para obter detalhes sobre esse recurso, consulte capturar eventos por meio dos hubs de eventos do Azure no armazenamento de BLOBs do Azure ou Azure data Lake Storage.

Suporte para clientes Apache Kafka

Os hubs de eventos fornecem um ponto de extremidade para clientes Apache Kafka . Os clientes existentes podem atualizar sua configuração para apontar para o ponto de extremidade e começar a enviar eventos para os hubs de eventos. Nenhuma alteração de código é necessária.

Para obter mais informações, consulte hubs de eventos para Apache Kafka.

Cenários de crossover

Em alguns casos, é vantajoso combinar dois serviços de mensagens.

A combinação de serviços pode aumentar a eficiência do sistema de mensagens. Por exemplo, em sua transação de negócios, você usa filas do barramento de serviço do Azure para lidar com mensagens. As filas que estão em grande parte ociosas e recebem mensagens ocasionalmente são ineficientes porque o consumidor está sondando constantemente a fila em busca de novas mensagens. Você pode configurar uma assinatura de grade de eventos com uma função do Azure como o manipulador de eventos. Cada vez que a fila recebe uma mensagem e não há nenhum consumidor ouvindo, a grade de eventos envia uma notificação, que invoca a função do Azure que drena a fila.

Integração do Barramento de Serviço do Azure com a Grade de Eventos

Para obter detalhes sobre como conectar o barramento de serviço à grade de eventos, consulte visão geral do barramento de serviço do Azure para integração da grade de eventos.

A integração corporativa no Azure usando filas de mensagens e a arquitetura de referência de eventos mostra uma implementação do barramento de serviço à integração da grade de eventos.

Aqui está outro exemplo. A grade de eventos recebe um conjunto de eventos em que alguns eventos exigem um fluxo de trabalho, enquanto outros são para notificação. Os metadados da mensagem indicam o tipo de evento. Uma maneira é verificar os metadados usando o recurso de filtragem na assinatura do evento. Se ele exigir um fluxo de trabalho, a grade de eventos o enviará para a fila do barramento de serviço do Azure. Os receptores dessa fila podem executar as ações necessárias. Os eventos de notificação são enviados aos aplicativos lógicos para enviar emails de alerta.

Grade de eventos do Azure para integração do barramento de serviço

Considere esses padrões ao implementar mensagens assíncronas:

  • Padrão de Consumidores Concorrentes. Vários consumidores podem precisar competir para ler mensagens de uma fila. Esse padrão explica como processar várias mensagens simultaneamente para otimizar a taxa de transferência, melhorar a escalabilidade e a disponibilidade e equilibrar a carga de trabalho.
  • Padrão de fila de prioridade. Para casos em que a lógica de negócios exige que algumas mensagens sejam processadas antes de outras, esse padrão descreve como as mensagens postadas por um produtor que têm uma prioridade mais alta podem ser recebidas e processadas mais rapidamente por um consumidor do que as mensagens de uma prioridade mais baixa.
  • Padrão de nivelamento de carga baseado em fila. Esse padrão usa um agente de mensagem para atuar como um buffer entre um produtor e um consumidor para ajudar a minimizar o impacto sobre a disponibilidade e a capacidade de resposta de cargas pesadas intermitentes para ambas as entidades.
  • Padrão de repetição. Um produtor ou consumidor pode não conseguir se conectar a uma fila, mas os motivos para essa falha podem ser temporários e passar rapidamente. Esse padrão descreve como lidar com essa situação para adicionar resiliência a um aplicativo.
  • Padrão de supervisor de agente do Agendador. O sistema de mensagens é geralmente usado como parte de uma implementação de fluxo de trabalho. Esse padrão demonstra como o sistema de mensagens pode coordenar um conjunto de ações em um conjunto distribuído de serviços e outros recursos remotos e permitir que um sistema recupere e repita as ações que falham.
  • Padrão coreografia. Esse padrão mostra como os serviços podem usar o sistema de mensagens para controlar o fluxo de trabalho de uma transação comercial.
  • Padrão de verificação de declaração. Esse padrão mostra como dividir uma mensagem grande em uma verificação de declaração e uma carga.

Recursos da comunidade

Postagem do blog de Jonathon Oliver: Idempotência

Postagem do blog de Martin Fowler: o que você quer dizer por "controlado por evento"?