Claim-Check padrão

Divida uma mensagem grande em uma verificação de declaração e uma carga. Envie a verificação de declaração para a plataforma de mensagens e armazene o payload em um serviço externo. Esse padrão permite que mensagens grandes sejam processadas, enquanto protege o barramento de mensagem e o cliente de serem sobrecarregadas ou lentas. Esse padrão também ajuda a reduzir os custos, pois o armazenamento geralmente é mais barato do que as unidades de recursos usadas pela plataforma de mensagens.

Esse padrão também é conhecido como mensagens Reference-Based, e foi originalmente descrito no livro Enterprise Integration Patterns, de Gregor Hohpe e Elaf.

Contexto e problema

Uma arquitetura baseada em mensagens em algum momento deve ser capaz de enviar, receber e manipular mensagens grandes. Essas mensagens podem conter qualquer coisa, incluindo imagens (por exemplo, verificações de MRI), arquivos de som (por exemplo, chamadas de call center), documentos de texto ou qualquer tipo de dados binários de tamanho arbitrário.

Não é recomendável enviar mensagens tão grandes diretamente para o barramento de mensagens, pois elas exigem mais recursos e largura de banda a serem consumidos. Mensagens grandes também podem reduzir a velocidade de toda a solução, pois as plataformas de mensagens geralmente são ajustadas para lidar com grandes quantidades de mensagens pequenas. Além disso, a maioria das plataformas de mensagens tem limites no tamanho da mensagem, portanto, talvez seja necessário resolver esses limites para mensagens grandes.

Solução

Armazene todo o conteúdo da mensagem em um serviço externo, como um banco de dados. Obter a referência ao payload armazenado e enviar apenas essa referência para o barramento de mensagem. A referência atua como uma verificação de declaração usada para recuperar uma parte da inserção, portanto, o nome do padrão. Os clientes interessados em processar essa mensagem específica podem usar a referência obtida para recuperar o payload, se necessário.

Diagrama do padrão Claim-Check padrão

Problemas e considerações

Considere os seguintes pontos ao decidir como implementar esse padrão:

  • Considere excluir os dados da mensagem depois de consumi-los, se você não precisar arquivar as mensagens. Embora o armazenamento de blob seja relativamente barato, ele custa algum dinheiro a longo prazo, especialmente se houver muitos dados. A exclusão da mensagem pode ser feita de forma síncrona pelo aplicativo que recebe e processa a mensagem ou de forma assíncrona por um processo dedicado separado. A abordagem assíncrona remove dados antigos sem impacto sobre a taxa de transferência e o desempenho do processamento de mensagens do aplicativo receptor.

  • Armazenar e recuperar a mensagem causa alguma sobrecarga e latência adicionais. Talvez você queira implementar a lógica no aplicativo de envio para usar esse padrão somente quando o tamanho da mensagem exceder o limite de dados do barramento de mensagem. O padrão seria ignorado para mensagens menores. Essa abordagem resultaria em um padrão de verificação de declaração condicional.

Quando usar esse padrão

Esse padrão deve ser usado sempre que uma mensagem não puder se ajustar ao limite de mensagens com suporte da tecnologia do barramento de mensagens escolhida. Por exemplo, os Hubs de Eventos atualmente têm um limite de 256 KB (Camada Básica), enquanto a Grade de Eventos dá suporte apenas a mensagens de 64 KB.

O padrão também pode ser usado se o conteúdo deve ser acessado somente por serviços autorizados a vê-lo. Ao descarregar o conteúdo para um recurso externo, regras de autenticação e autorização mais estritas podem ser colocadas em vigor, para garantir que a segurança seja imposta quando dados confidenciais são armazenados no conteúdo.

Exemplos

No Azure, esse padrão pode ser implementado de várias maneiras e com tecnologias diferentes, mas há duas categorias principais. Em ambos os casos, o receptor tem a responsabilidade de ler a verificação de declaração e usá-la para recuperar a carga.

  • Geração automática de verificação de declaração. Essa abordagem usa Grade de Eventos do Azure para gerar automaticamente a verificação de declaração e efetuar push dela para o barramento de mensagens.

  • Geração manual de verificação de declaração. Nessa abordagem, o remetente é responsável por gerenciar a carga. O remetente armazena a carga usando o serviço apropriado, obtém ou gera a verificação de declaração e envia a verificação de declaração para o barramento de mensagem.

A Grade de Eventos é um serviço de roteamento de eventos e tenta entregar eventos dentro de um período configurável de até 24 horas. Depois disso, os eventos são descartados ou com letras mortas. Se você precisar arquivar os conteúdos do evento ou repetir o fluxo de eventos, poderá adicionar uma assinatura da Grade de Eventos aos Hubs de Eventos ou Armazenamento fila, em que as mensagens podem ser mantidas por períodos mais longos e há suporte para mensagens de arquivamento. Para obter informações sobre como ajustar a entrega e a nova tentativa de mensagens da Grade de Eventos e a configuração de mensagens mortas, consulte Políticas de mensagens mortas e de nova tentativa.

Geração automática de verificação de declaração com o blob Armazenamento e a Grade de Eventos

Nessa abordagem, o remetente descarta o payload da mensagem em um contêiner de blob do Azure Armazenamento designado. A Grade de Eventos gera automaticamente uma marca/referência e a envia para um barramento de mensagens com suporte, como filas Armazenamento Azure. O receptor pode sondar a fila, obter a mensagem e, em seguida, usar os dados de referência armazenados para baixar o conteúdo diretamente do Blob Armazenamento.

A mesma mensagem da Grade de Eventos pode ser consumida diretamente Azure Functions, sem a necessidade de passar por um barramento de mensagem. Essa abordagem aproveita ao máximo a natureza sem servidor da Grade de Eventos e das Funções.

Você pode encontrar o código de exemplo para essa abordagem aqui.

Grade de Eventos com Hubs de Eventos

Semelhante ao exemplo anterior, a Grade de Eventos gera automaticamente uma mensagem quando um conteúdo é gravado em um contêiner de Blob do Azure. Mas, neste exemplo, o barramento de mensagem é implementado usando Hubs de Eventos. Um cliente pode se registrar para receber o fluxo de mensagens conforme elas são escritas no hub de eventos. O hub de eventos também pode ser configurado para arquivar mensagens, disponibilizando-as como um arquivo Avro que pode ser consultado usando ferramentas como Apache Spark, Apache Drill ou qualquer uma das bibliotecas Avro disponíveis.

Você pode encontrar o código de exemplo para essa abordagem aqui.

Geração de verificação de declaração com Barramento de Serviço

Essa solução aproveita um plug-in Barramento de Serviço específico, ServiceBus.AttachmentPlugin,que facilita a implementação do fluxo de trabalho de verificação de declaração. O plug-in converte qualquer corpo da mensagem em um anexo armazenado no blob do Azure Armazenamento quando a mensagem é enviada.

using ServiceBus.AttachmentPlugin;
...

// Getting connection information
var serviceBusConnectionString = Environment.GetEnvironmentVariable("SERVICE_BUS_CONNECTION_STRING");
var queueName = Environment.GetEnvironmentVariable("QUEUE_NAME");
var storageConnectionString = Environment.GetEnvironmentVariable("STORAGE_CONNECTION_STRING");

// Creating config for sending message
var config = new AzureStorageAttachmentConfiguration(storageConnectionString);

// Creating and registering the sender using Service Bus Connection String and Queue Name
var sender = new MessageSender(serviceBusConnectionString, queueName);
sender.RegisterAzureStorageAttachmentPlugin(config);

// Create payload
var payload = new { data = "random data string for testing" };
var serialized = JsonConvert.SerializeObject(payload);
var payloadAsBytes = Encoding.UTF8.GetBytes(serialized);
var message = new Message(payloadAsBytes);

// Send the message
await sender.SendAsync(message);

A Barramento de Serviço funciona como uma fila de notificação, que um cliente pode assinar. Quando o consumidor recebe a mensagem, o plug-in possibilita ler diretamente os dados da mensagem do Blob Armazenamento. Em seguida, você pode escolher como processar a mensagem ainda mais. Uma vantagem dessa abordagem é que ela abstrai o fluxo de trabalho de verificação de declaração do remetente e do destinatário.

Você pode encontrar o código de exemplo para essa abordagem aqui.

Geração manual de verificação de declaração com Kafka

Neste exemplo, um cliente Kafka grava o payload no blob do Azure Armazenamento. Em seguida, ele envia uma mensagem de notificação usando Hubs de Eventos habilitados para Kafka. O consumidor recebe a mensagem e pode acessar o conteúdo do blob Armazenamento. Este exemplo mostra como um protocolo de mensagens diferente pode ser usado para implementar o padrão de verificação de declaração no Azure. Por exemplo, talvez seja necessário dar suporte a clientes Kafka existentes.

Você pode encontrar o código de exemplo para essa abordagem aqui.

Próximas etapas

  • Um padrão alternativo para lidar com mensagens grandes é Dividir e Agregar.