Padrão de Verificação de Declaração

Armazene uma carga de mensagem grande em um armazenamento de dados externo e envie apenas uma referência ao conteúdo armazenado por meio do sistema de mensagens. As aplicações receptoras apresentam o token de referência, chamado de claim check, para recuperar a carga útil grande quando precisarem processá-la. Essa abordagem permite que as cargas de trabalho transfiram grandes volumes de dados sem armazená-los no sistema de mensagens.

Contexto e problema

Os sistemas de mensagens tradicionais são otimizados para gerenciar um alto volume de mensagens pequenas e geralmente restringem o tamanho da mensagem que podem lidar. Mensagens grandes não só correm o risco de exceder os limites de tamanho, mas também podem prejudicar o desempenho do sistema quando o sistema de mensagens as armazena.

As seguintes restrições tornam insuficiente a transmissão de payload em linha por meio do sistema de mensagens:

• Rejeição por limite de tamanho. Os sistemas de mensagens rejeitam mensagens que excedem um máximo configurado.

• Pressão de recursos do broker. Armazenar grandes cargas úteis no broker consome uma quantidade desproporcional de memória e espaço em disco em comparação com os metadados de que o broker precisa para encaminhar e entregar a mensagem. Esse consumo compete com os recursos necessários para outras mensagens no sistema.

• Degradação da taxa de transferência. Mensagens maiores aumentam o tempo de serialização, transferência e desserialização por operação.

• Escalonamento de custos. Alguns sistemas de mensagens cobram pelo tamanho da mensagem, camada ou unidade de capacidade. Transmitir grandes payloads em linha pode levar as cargas de trabalho para camadas mais caras ou alocações de capacidade.

Solução

O padrão Claim Check separa o armazenamento da carga útil da entrega de mensagens. Um aplicativo de envio grava o conteúdo completo em um armazenamento de dados externo e envia uma referência a esse conteúdo por meio do sistema de mensagens. O sistema de mensagens nunca vê ou armazena a carga útil. Os aplicativos receptores usam a referência para recuperar a carga diretamente do armazenamento de dados. A referência é um identificador que o aplicativo receptor deve resolver.

O padrão segue esta sequência:

1. A aplicação remetente gera a carga útil.
2. O aplicativo de envio salva a carga no armazenamento de dados externo.
3. Depois que o salvamento for bem-sucedido, o aplicativo de envio gerará uma referência ao conteúdo armazenado e o publicará no sistema de mensagens como uma mensagem de verificação de declaração.
4. Um aplicativo receptor recupera a mensagem e lê o token de verificação de declaração.
5. O aplicativo receptor usa o token para recuperar a carga do armazenamento de dados.
6. O aplicativo receptor processa o conteúdo.

O sistema de mensagens manipula apenas a pequena mensagem de verificação de declaração, o que evita a rejeição do tamanho da mensagem e a necessidade de usar recursos para transferir e reter grandes cargas de mensagem. O repositório de dados externo aplica controles de acesso e políticas de ciclo de vida ao conteúdo independente do sistema de mensagens.

Problemas e considerações

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

• Responsabilidade pelo ciclo de vida da carga útil. Defina qual componente possui a exclusão de carga e como o componente determina que o conteúdo não é necessário. Coordenar a expiração da mensagem e a retenção de conteúdo para que uma verificação de declaração válida não aponte para dados excluídos.

• Aplicação condicional. Decida se todas as mensagens devem usar claim check ou se a decisão de usar claim check deve ser tomada por mensagem. Se for condicional, verifique se o esquema define se a carga está embutida ou externa.

• Segurança de token e de armazenamento. Não insira tokens de segurança como parte da verificação de declaração. Deixe a autorização como uma interação independente entre os sistemas de produtor ou consumidor e o armazenamento de dados. Se a sua solução exigir que seja concedido explicitamente aos consumidores acesso temporário, use o padrão Valet Key em vez disso.

• Carga útil e consistência do token. A gravação do payload e a publicação do token ocorrem em sistemas separados e não ocorrem em uma única transação atômica. Uma falha após a gravação da carga útil, mas antes da publicação do token, pode deixar a carga útil órfã. Um token publicado antes que sua carga útil possa ser recuperada pode fazer com que os consumidores recebam referências que não conseguem resolver. Publique o token somente depois que a escrita do payload for concluída com êxito. Como as novas tentativas podem fornecer a mesma verificação de declaração mais de uma vez, use o padrão de consumidor Idempotente para processar duplicatas com segurança.

• Integridade da carga útil. Quando os consumidores devem verificar a integridade da carga, inclua um hash de conteúdo ou uma assinatura digital na mensagem. Defina um protocolo para incompatibilidades, como rejeitar a carga, tentar novamente a recuperação ou rotear a mensagem para investigação.

• Disponibilidade e durabilidade da carga útil. O armazenamento de dados externo deve permanecer disponível e durável durante todo o período em que os aplicativos receptores precisam recuperar uma carga. Se a loja sofrer uma interrupção ou perda de dados, os consumidores que possuem tokens válidos não conseguem recuperar seus payloads, e o processamento de suas mensagens é interrompido.

• Latência de salto de recuperação. Esse padrão adiciona idas e voltas extras na rede em comparação com a entrega inline de mensagens. Os aplicativos receptores devem chamar o repositório de dados externo para recuperar o conteúdo antes que o processamento possa começar.

• Suporte à verificação de declaração fornecida pela estrutura. Use os recursos que o SDK do barramento de mensagens oferece. Por exemplo, o NServiceBus tem um recurso DataBus que pode automatizar o armazenamento e a recuperação de conteúdo.

Quando usar esse padrão

Use esse padrão quando:

• Os conteúdos de mensagens excedem regularmente o tamanho máximo da mensagem compatível com o sistema de mensagens. Descarregar a carga para um armazenamento de dados externo e transmitir apenas um token de verificação de declaração leve evita rejeições de limite de tamanho.

• Mensagens grandes consomem uma quantidade desproporcional de recursos do broker. Mensagens grandes afetam o desempenho do sistema de mensagens aumentando o tempo de serialização e transferência ou reduzindo a taxa de transferência para todos os produtores e consumidores que compartilham o sistema de mensagens.

• Os conteúdos contêm informações confidenciais que não devem ser visíveis para o sistema de mensagens ou para componentes intermediários, como ferramentas de monitoramento de fila. Aplique o padrão à carga inteira ou apenas às partes confidenciais. Armazene o conteúdo confidencial em um repositório de dados protegido com controles de acesso dedicados para mantê-lo fora do caminho de mensagens.

• As mensagens têm roteamento complexo com serialização repetida. As mensagens atravessam vários componentes de roteamento que executam serialização, desserialização, criptografia ou descriptografia. Transmita apenas um token pequeno por meio de intermediários para eliminar o processamento repetido da carga completa em cada salto e reduzir a latência cumulativa.

Esse padrão pode não ser adequado quando:

• A sensibilidade à latência supera as preocupações com o tamanho da carga. Cargas de trabalho que exigem a menor latência de ponta a ponta possível entre produtor e consumidor podem não tolerar os saltos de rede adicionados para armazenamento e recuperação de conteúdo. Se as mensagens puderem ser entregues em linha sem exceder os limites de tamanho ou desempenho, a entrega direta é mais simples e rápida.

• Você pode escolher um transporte ou camada que dê suporte ao tamanho da carga. Quando as cargas úteis permanecerem dentro do limite suportado pelo transporte e não causarem taxa de transferência ou latência inaceitáveis, envie-as em linha para evitar a dependência de armazenamento externo. Por exemplo, Barramento de Serviço do Azure camada Premium dá suporte a mensagens AMQP (Advanced Message Queuing Protocol) de até 100 MB. Mantenha as mensagens o menor possível, pois mensagens grandes reduzem a taxa de transferência e aumentam a latência.

• A coordenação entre dois sistemas não é possível. O padrão requer coordenação entre dois sistemas independentes. O valor de verificação de declaração precisa ser gravado de uma maneira que o sistema receptor possa entender e seu formato pode precisar ser ajustado ao longo do tempo.

Alternatives

Considere essas abordagens como alternativas a esse padrão:

• Reduza o tamanho da carga embutida. A compactação pode reduzir conteúdos repetitivos de texto ou binários, e um serializador mais compacto pode reduzir a sobrecarga da mensagem. Escolha essa abordagem quando o payload reduzido couber confortavelmente no limite de transporte e todos os produtores e consumidores puderem usar o mesmo formato de compactação e serialização.

• Divida e agregue o payload de forma natural. Divida uma carga grande em uma sequência de mensagens menores quando os consumidores puderem processar partes de forma independente ou remontá-las após a entrega. Essa abordagem mantém os dados no sistema de mensagens, mas adiciona requisitos de sequenciamento, correlação, tratamento duplicado e remontagem. Para obter mais informações, consulte os padrões splitter e agregador de padrões de integração empresarial.

Design de carga de trabalho

Avalie como usar o padrão de Verificação de Declaração no design de uma carga de trabalho para abordar as metas e os princípios abordados nos pilares do Azure Well-Architected Framework. A tabela a seguir fornece diretrizes sobre como esse padrão dá suporte às metas dos pilares.

Se esse padrão introduzir compensações dentro de um pilar, considere-as em relação aos objetivos dos outros pilares.

Examples

Esta seção inclui links para exemplos do padrão de nuvem Claim Check no GitHub Claim-check cloud pattern examples que mostram como os serviços do Azure implementam o padrão Claim Check. Cada exemplo usa Armazenamento de Blobs do Azure como o armazenamento de dados externo e o emparelha com um sistema de mensagens Azure diferente. Os exemplos de 1 a 3 usam a URL do blob em uma notificação Grade de Eventos do Azure como a verificação de declaração. O exemplo 4 usa uma verificação de declaração personalizada que o aplicativo de envio publica.

Nos exemplos de 1 a 3:

1. Um aplicativo de envio carrega uma carga grande para Armazenamento de Blobs.
2. O carregamento dispara um evento Microsoft.Storage.BlobCreated por meio de um tópico do sistema do Event Grid.
3. A Grade de Eventos roteia a notificação, que contém uma URL de blob direta que os exemplos usam como a verificação de declaração, para o sistema de mensagens configurado.
4. Um aplicativo receptor, implementado como um aplicativo de funções Azure Functions ou cliente de linha de comando, recupera a notificação, extrai a URL do blob e baixa o conteúdo diretamente do Armazenamento de Blobs para processamento.

Em uma implementação de produção, você filtra a assinatura de eventos por operações que indiquem um block blob totalmente consolidado e projeta o receptor para lidar com eventos atrasados, duplicados e fora de ordem.

O exemplo 4 usa uma abordagem diferente. Em vez de encaminhar uma notificação do Armazenamento de Blobs por meio do Event Grid, o aplicativo remetente constrói o claim check após carregar o payload no Armazenamento de Blobs. Em seguida, o aplicativo de envio publica o claim check no endpoint Kafka do Hubs de Eventos do Azure usando o protocolo Apache Kafka. Essa abordagem atende a ambientes que já usam produtores compatíveis com Kafka ou exigem formatos de token personalizados.

A tabela a seguir lista cada exemplo com seu sistema de mensagens, editor de verificação de declarações, aplicativo de recebimento e dependências de armazenamento. Selecione cada link para exibir o código de exemplo no GitHub.

Próximas Etapas 

• Leia a descrição canônica do padrão Claim Check em Enterprise Integration Patterns.
• Veja outra implementação em Lidando com mensagens grandes do Barramento de Serviço usando o padrão Claim Check.
• Escolha entre Grade de Eventos do Azure, Hubs de Eventos e Barramento de Serviço.

Recursos relacionados

• padrão de Request-Reply assíncrono
• Padrão de Consumidores Concorrentes
• Padrão de Comboio Sequencial
• Padrão de chave limitada