Modello claim-check

Il modello Claim-Check consente ai carichi di lavoro di trasferire payload senza archiviare il payload in un sistema di messaggistica. Il modello archivia il payload in un archivio dati esterno e usa un "controllo attestazioni" per recuperare il payload. Il controllo dell'attestazione è un token o una chiave univoca o oscura. Per recuperare il payload, le applicazioni devono presentare il token di controllo attestazione all'archivio dati esterno.

Contesto e problema

I sistemi di messaggistica tradizionali sono ottimizzati per gestire un volume elevato di messaggi di piccole dimensioni e spesso hanno restrizioni sulle dimensioni dei messaggi che possono gestire. I messaggi di grandi dimensioni non solo rischiano di superare questi limiti, ma possono anche ridurre le prestazioni dell'intero sistema quando il sistema di messaggistica li archivia.

Soluzione

Usare il modello Claim-Check e non inviare messaggi di grandi dimensioni al sistema di messaggistica. In alternativa, inviare il payload a un archivio dati esterno e generare un token di controllo attestazioni per tale payload. Il sistema di messaggistica invia un messaggio con il token di controllo attestazione per ricevere applicazioni in modo che queste applicazioni possano recuperare il payload dall'archivio dati. Il sistema di messaggistica non vede mai o archivia il payload.

1. Payload
2. Salvare il payload nell'archivio dati.
3. Generare il token di controllo attestazione e inviare un messaggio con token di controllo attestazione.
4. Ricevere un messaggio e leggere il token di controllo attestazioni.
5. Recuperare il payload.
6. Elaborare il payload.

Problemi e considerazioni con il modello Claim-Check

Quando si implementa il modello Claim-Check, tenere presente quanto segue:

• Eliminare i messaggi utilizzati. Se non è necessario archiviare il messaggio, eliminare il messaggio e il payload dopo l'utilizzo delle applicazioni riceventi. Usare una strategia di eliminazione sincrona o asincrona:

  • Eliminazione sincrona: l'applicazione che utilizza elimina il messaggio e il payload immediatamente dopo l'utilizzo. Collega l'eliminazione al flusso di lavoro di gestione dei messaggi e usa la capacità di calcolo del flusso di lavoro di messaggistica.

  • Eliminazione asincrona: un processo esterno al flusso di lavoro di elaborazione dei messaggi elimina il messaggio e il payload. Separa il processo di eliminazione dal flusso di lavoro di gestione dei messaggi e riduce al minimo l'uso del calcolo del flusso di lavoro di messaggistica.

• Implementare il modello in modo condizionale. Incorporare la logica nell'applicazione di invio che applica il modello Claim-Check se la dimensione del messaggio supera il limite del sistema di messaggistica. Per i messaggi più piccoli, ignorare il modello e inviare il messaggio più piccolo al sistema di messaggistica. Questo approccio condizionale riduce la latenza, ottimizza l'utilizzo delle risorse e migliora la velocità effettiva.

Quando usare il modello Claim-Check

Gli scenari seguenti sono i casi d'uso principali per il modello Claim-Check:

• Limitazioni del sistema di messaggistica: usare il modello Claim-Check quando le dimensioni dei messaggi superano i limiti del sistema di messaggistica. Eseguire l'offload del payload nell'archiviazione esterna. Inviare solo il messaggio con il relativo token di controllo attestazione al sistema di messaggistica.

• Prestazioni del sistema di messaggistica: usare il modello Claim-Check quando i messaggi di grandi dimensioni stanno mettendo a dura prova il sistema di messaggistica e degradando le prestazioni del sistema.

Gli scenari seguenti sono casi d'uso secondari per il modello Claim-Check:

• Protezione dei dati sensibili: usare il modello Claim-Check quando i payload contengono dati sensibili che non vogliono essere visibili al sistema di messaggistica. Applicare il modello a tutte o parti di informazioni riservate nel payload. Proteggere i dati sensibili senza trasmetterli direttamente tramite il sistema di messaggistica.

• Scenari di routing complessi: i messaggi che attraversano più componenti possono causare colli di bottiglia delle prestazioni a causa della serializzazione, deserializzazione, crittografia e decrittografia delle attività. Usare il modello Claim-Check per impedire l'elaborazione diretta dei messaggi da parte dei componenti intermedi.

Progettazione del carico di lavoro con il modello Claim-Check

Un architetto deve valutare come usare il modello Claim-Check nella progettazione del carico di lavoro per soddisfare gli obiettivi e i principi trattati nei pilastri di Azure Well-Architected Framework. Ad esempio:

Come per qualsiasi decisione di progettazione, prendere in considerazione eventuali compromessi rispetto agli obiettivi degli altri pilastri che potrebbero essere introdotti con questo modello.

Esempi di criteri di controllo delle attestazioni

Gli esempi seguenti illustrano come Azure facilita l'implementazione del modello Claim-Check:

• Sistemi di messaggistica di Azure: gli esempi riguardano quattro diversi scenari di sistema di messaggistica di Azure: Archiviazione, Hub eventi di Azure (API Standard), bus di servizio di Azure e Hub eventi di Azure (API Kafka).

• Generazione automatica e manuale del token di controllo delle attestazioni: questi esempi mostrano anche due metodi per generare il token di controllo attestazione. Negli esempi di codice 1-3, Griglia di eventi di Azure genera automaticamente il token quando l'applicazione di invio trasferisce il payload a Archiviazione BLOB di Azure. L'esempio di codice 4 mostra un processo di generazione manuale dei token usando un client della riga di comando eseguibile.

Scegliere l'esempio più adatto alle proprie esigenze e seguire il collegamento fornito per visualizzare il codice in GitHub:

Passaggi successivi

• Il sito Modelli di integrazione aziendale include una descrizione di questo modello.
• Per un altro esempio, vedere Gestione di messaggi di bus di servizio di grandi dimensioni usando il modello Claim-Check (post di blog).
• Un modello alternativo per la gestione di messaggi di grandi dimensioni è Split e Aggregate.
• Le librerie come NServiceBus forniscono supporto per questo modello predefinito con la funzionalità "bus di dati".

Risorse correlate

• Modello di richiesta/risposta asincrona
• Modello consumer concorrenti
• Modello di convoglio sequenziale