Padrão de verificação de sinistros

Armazene uma grande carga útil de mensagens num armazenamento de dados externo e envie apenas uma referência à carga útil armazenada através do sistema de mensagens. As aplicações recetoras apresentam o token de referência, chamado verificação de reivindicação, para recuperar a grande carga útil quando precisam de a processar. Esta abordagem permite que os processos transfiram grandes volumes de dados sem os armazenar no sistema de mensagens.

Contexto e problema

Os sistemas tradicionais de mensagens são otimizados para gerir um grande volume de mensagens pequenas e frequentemente restringem o tamanho da mensagem que conseguem gerir. Mensagens grandes não só correm o risco de ultrapassar os limites de tamanho, como também podem degradar o desempenho do sistema quando o sistema de mensagens as armazena.

As seguintes restrições tornam insuficiente a transmissão da carga útil em linha através do sistema de mensagens:

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

• Pressão de recursos para corretores. Armazenar grandes cargas no broker de mensagens consome memória e espaço em disco de forma desproporcionada, em comparação com os metadados de que o broker necessita para encaminhar e entregar a mensagem. Este consumo compete com os recursos necessários para outras mensagens no sistema.

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

• Escalada de custos. Alguns sistemas de mensagens cobram pelo tamanho da mensagem, nível ou unidade de capacidade. Transmitir cargas úteis grandes em linha pode empurrar cargas de trabalho para níveis de custo mais elevados ou alocações de capacidade.

Solução

O padrão Claim Check separa o armazenamento da carga útil da entrega de mensagens. Uma aplicação enviadora escreve a carga útil completa para um armazenamento de dados externo e envia uma referência a essa carga útil através do sistema de mensagens. O sistema de mensagens nunca vê ou armazena a carga útil. As aplicações recetoras utilizam a referência para recuperar a carga útil diretamente do armazenamento de dados. A referência é um identificador que a aplicação recetora tem de resolver.

O padrão segue esta sequência:

1. A aplicação de envio gera a carga útil.
2. A aplicação de envio guarda a carga útil no armazenamento de dados externo.
3. Depois de o save ser bem-sucedido, a aplicação enviadora gera uma referência à carga útil armazenada e publica-a no sistema de mensagens como uma mensagem de verificação de reclamação.
4. Uma aplicação recetora recupera a mensagem e lê o token de verificação da reclamação.
5. A aplicação recetora utiliza o token para recuperar a carga útil do armazenamento de dados.
6. A aplicação recetora processa a carga útil.

O sistema de mensagens trata apenas a mensagem de verificação de pequenas reclamações, o que evita rejeições do tamanho da mensagem e a necessidade de usar recursos para transferir e manter grandes cargas úteis de mensagens. O armazenamento de dados externo aplica controlos de acesso e políticas de ciclo de vida ao payload independentemente 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 o componente responsável pela eliminação da carga útil e como esse componente determina que a carga útil deixou de ser necessária. Coordena a expiração da mensagem e a retenção da carga útil para que uma verificação válida da reclamação não aponte para dados eliminados.

• Aplicação condicional. Decida se deve aplicar verificações claim-check a todas as mensagens ou tomar essa decisão para cada mensagem. Se for condicional, certifique-se de que o esquema define se a carga útil é incorporada ou externa.

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

• Consistência do payload e do token. A escrita da carga e a publicação de tokens ocorrem em sistemas separados e não ocorrem numa única transação atómica. Uma falha após a gravação do payload, mas antes da publicação do token, pode deixar o payload órfão. Um token publicado antes da sua carga útil ser recuperável pode significar que os consumidores recebem referências que não conseguem resolver. Publique o token apenas depois de a escrita do payload ter sucesso. Como as retentativas podem fornecer a mesma verificação de reclamação mais do que uma vez, utilize o padrão Consumidor Idempotente para processar duplicados de forma segura.

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

• Disponibilidade e durabilidade da carga. O armazenamento de dados externo deve permanecer disponível e durável durante todo o período em que as aplicações recetoras precisam de recuperar uma carga útil. Se o armazenamento sofrer uma falha ou perda de dados, os consumidores que tenham tokens válidos não conseguem recuperar os seus conteúdos e o processamento das mensagens fica bloqueado.

• Latência de salto de recuperação. O padrão adiciona viagens de rede extra em comparação com a entrega de mensagens em linha. As aplicações recetoras devem contactar o armazenamento de dados externo para recuperar a carga útil antes de o processamento poder começar.

• Suporte de verificação de sinistros fornecido pelo framework. Use as capacidades que o seu SDK do barramento de mensagens oferece. Por exemplo, o NServiceBus tem uma funcionalidade DataBus que pode automatizar o armazenamento e a recuperação de cargas úteis.

Quando utilizar este padrão

Utilize este padrão quando:

• As cargas úteis das mensagens ultrapassam regularmente o tamanho máximo da mensagem suportado pelo sistema de mensagens. Descarregar a carga útil para um armazenamento de dados externo e transmitir apenas um token leve de verificação de reivindicação evita rejeições por limite de tamanho.

• As mensagens grandes consomem uma quantidade desproporcionada de recursos dos brokers. As mensagens grandes afetam o desempenho do sistema de mensagens ao aumentar o tempo de serialização e de transferência ou ao degradar o rendimento de todos os produtores e consumidores que partilham esse sistema de mensagens.

• As cargas úteis contêm informações sensíveis que não deveriam ser visíveis para o sistema de mensagens ou para componentes intermédios, como ferramentas de monitorização de filas. Aplique o padrão a toda a carga útil ou apenas às suas partes sensíveis. Armazene o conteúdo sensível num armazenamento de dados seguro com controlos de acesso dedicados para o manter fora do caminho de mensagens.

• As mensagens apresentam encaminhamento complexo com serialização repetida. As mensagens atravessam múltiplos componentes de encaminhamento que realizam serialização, desserialização, encriptação ou desencriptação. Transmitir apenas um pequeno token através de intermediários para eliminar o processamento repetido da carga útil completa a cada salto e reduzir a latência acumulada.

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

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

• Podes escolher um transporte ou nível que suporte o tamanho da carga útil. Quando as cargas úteis se mantêm dentro do limite suportado pelo transporte e não criam uma taxa de transferência ou latência inaceitáveis, envie-as em linha para evitar a dependência da memória externa. Por exemplo, o nível Premium do Azure Service Bus suporta mensagens Advanced Message Queuing Protocol (AMQP) até 100 MB. Mantenha as mensagens o mais pequenas possível, porque as mensagens grandes reduzem o débito 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 do cheque de reclamação deve ser escrito de forma a que o sistema recetor possa compreender, e o seu formato pode ter de ser ajustado ao longo do tempo.

Alternatives

Considere estas abordagens como alternativas a este padrão:

• Reduzir o tamanho da carga útil em linha. A compressão pode reduzir o texto repetitivo ou cargas binárias, e um serializador mais compacto pode reduzir a sobrecarga das mensagens. Escolha esta abordagem quando a carga útil reduzida se encaixa confortavelmente dentro do limite de transporte e todos os produtores e consumidores podem usar o mesmo formato de compressão e serialização.

• Dividir e agregar a carga útil naturalmente. Divida uma carga útil grande numa sequência de mensagens mais pequenas quando os consumidores possam processar blocos de forma independente ou voltar a montá-los após a entrega. Esta abordagem mantém os dados no sistema de mensagens, mas acrescenta requisitos de sequenciação, correlação, tratamento de duplicados e remontagem. Para mais informações, consulte os padrões Splitter e Aggregator dos Padrões de Integração Empresarial.

Design da carga de trabalho

Avalie como utilizar o padrão Claim Check na conceção de uma carga de trabalho para cumprir os objetivos e princípios abrangidos pelos pilares do Azure Well-Architected Framework. A tabela seguinte fornece orientações sobre como este padrão apoia os objetivos dos pilares.

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

Examples

Esta secção liga a exemplos de padrões cloud do GitHub Claim-check que mostram como os serviços do Azure implementam o padrão Claim Check. Cada exemplo utiliza o Armazenamento de Blobs do Azure como armazenamento de dados externo e emparelha-o com um sistema de mensagens Azure diferente. Os exemplos 1 a 3 usam a URL do blob numa notificação do Azure Event Grid como verificação de reivindicação. O Exemplo 4 utiliza uma verificação personalizada de reclamação que a aplicação de envio publica.

Nos exemplos 1 a 3:

1. Uma aplicação enviadora carrega uma grande carga útil para o Armazenamento de Blobs.
2. O upload desencadeia um Microsoft.Storage.BlobCreated evento através de um tópico do sistema Event Grid.
3. O Event Grid encaminha a notificação, que contém um URL de blob direto que os exemplos usam como verificação de reivindicações, para o sistema de mensagens configurado.
4. Uma aplicação recetora, implementada como uma aplicação de funções Funções do Azure ou cliente de linha de comandos, recupera a notificação, extrai o URL do blob e descarrega o payload diretamente do Armazenamento de Blobs para processamento.

Numa implementação de produção, filtra-se a subscrição de eventos por operações que indicam um blob de bloco totalmente comprometido, e projeta-se o recetor para lidar com eventos atrasados, duplicados e fora de ordem.

O Exemplo 4 usa uma abordagem diferente. Em vez de encaminhar uma notificação de Armazenamento de Blobs através da Grade de Eventos, a aplicação enviante constrói a verificação da reclamação após carregar o payload para o Armazenamento de Blobs. A aplicação de envio publica então a verificação de reivindicação no endpoint Kafka do Hubs de Eventos do Azure usando o protocolo Apache Kafka. Esta abordagem adequa-se a ambientes que já utilizam produtores compatíveis com Kafka ou que requerem formatos personalizados de tokens.

A tabela seguinte lista cada exemplo com o seu sistema de mensagens, publicador de verificação de reivindicações, aplicação recetora e dependências de armazenamento. Selecione cada link para ver o código de exemplo no GitHub.

Passos seguintes

• Leia a descrição canónica dos Padrões de Integração Empresarial do Claim Check.
• Veja outra implementação em Lidar com mensagens grandes do Service Bus utilizando o padrão claim check.
• Escolha entre Azure Event Grid, Event Hubs e Service Bus.

Recursos relacionados

• Padrão de Request-Reply assíncrono
• Padrão de consumidores concorrentes
• Padrão de comboio sequencial
• Padrão de Chave Valet