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.
- Payload
- Salvare il payload nell'archivio dati.
- Generare il token di controllo attestazione e inviare un messaggio con token di controllo attestazione.
- Ricevere un messaggio e leggere il token di controllo attestazioni.
- Recuperare il payload.
- 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:
| Concetto fondamentale | Come questo modello supporta gli obiettivi di pilastro |
|---|---|
| Le decisioni di progettazione dell'affidabilità aiutano il carico di lavoro a diventare resilienti al malfunzionamento e assicurarsi che venga ripristinato completamente dopo l'errore. | I sistemi di messaggistica non forniscono la stessa affidabilità e ripristino di emergenza che sono spesso presenti negli archivi dati dedicati. La separazione dei dati dal messaggio può offrire maggiore affidabilità per il payload. Questa separazione facilita la ridondanza dei dati che consente di ripristinare i payload dopo un'emergenza. - Analisi della modalità errore RE:03 - RE:09 Ripristino di emergenza |
| Le decisioni di progettazione della sicurezza consentono di garantire la riservatezza, l'integrità e la disponibilità dei dati e dei sistemi del carico di lavoro. | Il modello Claim-Check può estrarre dati sensibili dai messaggi e archiviarlo in un archivio dati sicuro. Questa configurazione consente di implementare controlli di accesso più rigorosi, assicurandosi che solo i servizi destinati all'uso dei dati sensibili possano accedervi. Allo stesso tempo, nasconde questi dati da servizi non correlati, ad esempio quelli usati per il monitoraggio delle code. - Classificazione dei dati SE:03 - Segmentazione SE:04 |
| L'ottimizzazione dei costi è incentrata sul mantenimento e sul miglioramento del ritorno del carico di lavoro sugli investimenti. | I sistemi di messaggistica spesso impongono limiti alle dimensioni dei messaggi e i limiti di dimensioni maggiori sono spesso una funzionalità Premium. La riduzione delle dimensioni dei corpi dei messaggi potrebbe consentire di usare una soluzione di messaggistica più economica. - Costi dei componenti CO:07 - Costi del flusso CO:09 |
| L'efficienza delle prestazioni consente al carico di lavoro di soddisfare in modo efficiente le richieste ottimizzando il ridimensionamento, il trasferimento dei dati e l'esecuzione del codice. | Il modello Claim-Check migliora l'efficienza dell'invio e della ricezione di applicazioni e del sistema di messaggistica gestendo i messaggi di grandi dimensioni in modo più efficace. Riduce le dimensioni dei messaggi inviati al sistema di messaggistica e garantisce che le applicazioni ricevano messaggi di grandi dimensioni solo quando necessario. - PE:05 Ridimensionamento e partizionamento - Ottimizzazione continua delle prestazioni PE:12 |
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 code di Azure, 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:
| Codice di esempio | Scenari di sistema di messaggistica | Generatore di token | Ricezione dell'applicazione | Archivio dati |
|---|---|---|---|---|
| Esempio di codice 1 | Archiviazione code di Azure | Griglia di eventi di Azure | Funzione | Archiviazione BLOB di Azure |
| Esempio di codice 2 | Hub eventi di Azure (API Standard) | Griglia di eventi di Azure | Client della riga di comando eseguibile | Archiviazione BLOB di Azure |
| Esempio di codice 3 | Bus di servizio di Azure | Griglia di eventi di Azure | Funzione | Archiviazione BLOB di Azure |
| Esempio di codice 4 | Hub eventi di Azure (API Kafka) | Client della riga di comando eseguibile | Funzione | Archiviazione BLOB di Azure |
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 relativa funzionalità DataBus.