O padrão Claim-Check permite que cargas de trabalho transfiram cargas úteis sem armazenar a carga útil em um sistema de mensagens. O padrão armazena a carga em um armazenamento de dados externo e usa uma "verificação de declaração" para recuperar a carga útil. A verificação de declaração é um token ou chave exclusivo e obscuro. Para recuperar a carga útil, os aplicativos precisam apresentar o token de verificação de declaração ao armazenamento de dados externo.
Contexto e problema
Os sistemas de mensagens tradicionais são otimizados para gerenciar um grande volume de mensagens pequenas e geralmente têm restrições no tamanho da mensagem que podem lidar. Mensagens grandes não só correm o risco de exceder esses limites, mas também podem degradar o desempenho de todo o sistema quando o sistema de mensagens as armazena.
Solução
Use o padrão Claim-Check e não envie mensagens grandes para o sistema de mensagens. Em vez disso, envie a carga para um armazenamento de dados externo e gere um token de verificação de declaração para essa carga. O sistema de mensagens envia uma mensagem com o token de verificação de declaração para aplicativos de recebimento para que esses aplicativos possam recuperar a carga útil do armazenamento de dados. O sistema de mensagens nunca vê ou armazena a carga útil.
- Payload
- Poupe carga útil no armazenamento de dados.
- Gere o token de verificação de declaração e envie uma mensagem com o token de verificação de declaração.
- Receba uma mensagem e leia o token de verificação de declaração.
- Recupere a carga útil.
- Processe a carga útil.
Problemas e considerações com o padrão Claim-Check
Considere as seguintes recomendações ao implementar o padrão Claim-Check:
Excluir mensagens consumidas. Se você não precisar arquivar a mensagem, exclua a mensagem e a carga útil depois que os aplicativos de recebimento a consumirem. Use uma estratégia de exclusão síncrona ou assíncrona:
Exclusão síncrona: O aplicativo consumidor exclui a mensagem e a carga imediatamente após o consumo. Ele vincula a exclusão ao fluxo de trabalho de manipulação de mensagens e usa a capacidade de computação do fluxo de trabalho de mensagens.
Exclusão assíncrona: um processo fora do fluxo de trabalho de processamento de mensagens exclui a mensagem e a carga útil. Ele separa o processo de exclusão do fluxo de trabalho de manipulação de mensagens e minimiza o uso de computação de fluxo de trabalho de mensagens.
Implemente o padrão condicionalmente. Incorpore a lógica no aplicativo de envio que aplica o padrão Claim-Check se o tamanho da mensagem exceder o limite do sistema de mensagens. Para mensagens menores, ignore o padrão e envie a mensagem menor para o sistema de mensagens. Essa abordagem condicional reduz a latência, otimiza a utilização de recursos e melhora a taxa de transferência.
Quando usar o padrão Claim-Check
Os cenários a seguir são os principais casos de uso para o padrão Claim-Check:
Limitações do sistema de mensagens: use o padrão Claim-Check quando os tamanhos das mensagens ultrapassarem os limites do seu sistema de mensagens. Descarregue a carga útil para armazenamento externo. Envie apenas a mensagem com seu token de verificação de declaração para o sistema de mensagens.
Desempenho do sistema de mensagens: use o padrão Claim-Check quando mensagens grandes estiverem sobrecarregando o sistema de mensagens e degradando o desempenho do sistema.
Os cenários a seguir são casos de uso secundários para o padrão Claim-Check:
Proteção de dados confidenciais: use o padrão Claim-Check quando as cargas úteis contiverem dados confidenciais que não querem ser visíveis para o sistema de mensagens. Aplique o padrão a todas ou partes de informações confidenciais na carga útil. Proteja os dados confidenciais sem transmiti-los diretamente através do sistema de mensagens.
Cenários de roteamento complexos: mensagens que atravessam vários componentes podem causar gargalos de desempenho devido a tarefas de serialização, desserialização, criptografia e descriptografia. Use o padrão Claim-Check para impedir o processamento de mensagens diretas por componentes intermediários.
Design de carga de trabalho com o padrão Claim-Check
Um arquiteto deve avaliar como o padrão Claim-Check 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:
| Pilar | Como esse padrão suporta os objetivos do pilar |
|---|---|
| As decisões de projeto de confiabilidade ajudam sua carga de trabalho a se tornar resiliente ao mau funcionamento e garantem que ela se recupere totalmente após uma falha. | Os sistemas de mensagens não fornecem a mesma confiabilidade e recuperação de desastres que geralmente estão presentes em armazenamentos de dados dedicados. Separar os dados da mensagem pode fornecer maior confiabilidade para a carga útil. Essa separação facilita a redundância de dados que permite recuperar cargas úteis após um desastre. - RE:03 Análise do modo de falha - RE:09 Recuperação de desastres |
| As decisões de design de segurança ajudam a garantir a confidencialidade, integridade e disponibilidade dos dados e sistemas de carga de trabalho. | O padrão Claim-Check pode extrair dados confidenciais de mensagens e armazená-los em um armazenamento de dados seguro. Essa configuração permite que você implemente controles de acesso mais rígidos, garantindo que apenas os serviços destinados a usar os dados confidenciais possam acessá-los. Ao mesmo tempo, oculta esses dados de serviços não relacionados, como aqueles usados para monitoramento de filas. - SE:03 Classificação dos dados - SE:04 Segmentação |
| A Otimização de Custos está focada em sustentar e melhorar o retorno do investimento da sua carga de trabalho. | Os sistemas de mensagens geralmente impõem limites ao tamanho da mensagem, e o aumento dos limites de tamanho é muitas vezes um recurso premium. Reduzir o tamanho dos corpos de mensagens pode permitir que você use uma solução de mensagens mais barata. - CO:07 Custos dos componentes - CO:09 Custos de fluxo |
| A eficiência de desempenho ajuda sua carga de trabalho a atender às demandas de forma eficiente, otimizando o dimensionamento, a transferência de dados e a execução de código. | O padrão Claim-Check melhora a eficiência do envio e recebimento de aplicativos e do sistema de mensagens, gerenciando mensagens grandes de forma mais eficaz. Ele reduz o tamanho das mensagens enviadas para o sistema de mensagens e garante que os aplicativos de recebimento acessem mensagens grandes apenas quando necessário. - PE:05 Dimensionamento e particionamento - PE:12 Otimização contínua do desempenho |
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.
Exemplos de padrões de verificação de declarações
Os exemplos a seguir demonstram como o Azure facilita a implementação do Padrão de Verificação de Declaração:
Sistemas de mensagens do Azure: os exemplos abrangem quatro cenários diferentes do sistema de mensagens do Azure: Armazenamento de Filas do Azure, Hubs de Eventos do Azure (API Padrão), Barramento de Serviço do Azure e Hubs de Eventos do Azure (API Kafka).
Geração automática versus manual de token de verificação de declaração: esses exemplos também mostram dois métodos para gerar o token de verificação de declaração. Nos exemplos de código 1 a 3, a Grade de Eventos do Azure gera automaticamente o token quando o aplicativo de envio transfere a carga para o Armazenamento de Blobs do Azure. O exemplo de código 4 mostra um processo manual de geração de token usando um cliente de linha de comando executável.
Escolha o exemplo que atenda às suas necessidades e siga o link fornecido para visualizar o código no GitHub:
| Código de exemplo | Cenários do sistema de mensagens | Gerador de tokens | Receção da candidatura | Arquivo de dados |
|---|---|---|---|---|
| Exemplo de código 1 | Armazenamento de Filas do Azure | Grelha de Eventos do Azure | Function | Armazenamento de Blobs do Azure |
| Exemplo de código 2 | Hubs de Eventos do Azure (API Padrão) | Grelha de Eventos do Azure | Cliente de linha de comando executável | Armazenamento de Blobs do Azure |
| Exemplo de código 3 | Azure Service Bus | Grelha de Eventos do Azure | Function | Armazenamento de Blobs do Azure |
| Exemplo de código 4 | Hubs de Eventos do Azure (API Kafka) | Cliente de linha de comando executável | Function | Armazenamento de Blobs do Azure |
Próximos passos
- O site Padrões de Integração Empresarial tem uma descrição desse padrão.
- Para outro exemplo, consulte Lidando com mensagens grandes do Service Bus usando o padrão Claim-Check (postagem de blog).
- Um padrão alternativo para lidar com mensagens grandes é Dividir e Agregar.
- Bibliotecas como o NServiceBus fornecem suporte para esse padrão pronto para uso com seu recurso DataBus.