Modello di controllo attestazione

Archiviare un payload di messaggi di grandi dimensioni in un archivio dati esterno e inviare solo un riferimento al payload archiviato tramite il sistema di messaggistica. Le applicazioni riceventi presentano il token di riferimento, denominato claim check, per recuperare il payload di grandi dimensioni quando devono elaborarlo. Questo approccio consente ai carichi di lavoro di trasferire payload di grandi dimensioni senza archiviarli nel sistema di messaggistica.

Contesto e problema

I sistemi di messaggistica tradizionali sono ottimizzati per gestire un volume elevato di messaggi di piccole dimensioni e spesso limitano le dimensioni dei messaggi che possono gestire. I messaggi di grandi dimensioni non solo rischiano di superare i limiti di dimensione, ma possono anche ridurre le prestazioni del sistema quando il sistema di messaggistica li archivia.

I vincoli seguenti rendono insufficiente la trasmissione del payload inline tramite il sistema di messaggistica:

• Rifiuto per superamento del limite di dimensione. I sistemi di messaggistica rifiutano i messaggi che superano un valore massimo configurato.

• Sovraccarico delle risorse del broker. L'archiviazione di payload di grandi dimensioni nel broker utilizza memoria e disco sproporzionati rispetto ai metadati che il broker deve instradare e recapitare il messaggio. Questo consumo compete con le risorse necessarie per altri messaggi nel sistema.

• Degrado del throughput. I messaggi più grandi aumentano la serializzazione, il trasferimento e il tempo di deserializzazione per ogni operazione.

• Escalation dei costi. Alcuni sistemi di messaggistica vengono addebitati in base alle dimensioni dei messaggi, al livello o all'unità di capacità. La trasmissione in linea di payload di grandi dimensioni può spingere i carichi di lavoro verso fasce di costo superiori o allocazioni di capacità maggiori.

Soluzione

Il pattern Claim Check separa l'archiviazione del payload dal recapito del messaggio. Un'applicazione di invio scrive il payload completo in un archivio dati esterno e invia un riferimento a tale payload tramite il sistema di messaggistica. Il sistema di messaggistica non vede mai o archivia il payload. Le applicazioni riceventi usano il riferimento per recuperare direttamente il payload dall'archivio dati. Il riferimento è un identificatore che l'applicazione ricevente deve risolvere.

Il modello segue questa sequenza:

1. L'applicazione di invio genera il payload.
2. L'applicazione di invio salva il payload nell'archivio dati esterno.
3. Una volta completato correttamente il salvataggio, l'applicazione mittente genera un riferimento al payload archiviato e lo pubblica nel sistema di messaggistica come messaggio di tipo claim check.
4. Un'applicazione ricevente recupera il messaggio e legge il token di controllo attestazione.
5. L'applicazione ricevente usa il token per recuperare il payload dall'archivio dati.
6. L'applicazione di destinazione elabora il payload.

Il sistema di messaggistica gestisce solo il messaggio claim check di piccole dimensioni, evitando il rifiuto dei messaggi dovuto ai limiti di dimensione e la necessità di utilizzare risorse per trasferire e conservare payload di messaggi di grandi dimensioni. L'archivio dati esterno applica i controlli di accesso e i criteri del ciclo di vita al payload indipendentemente dal sistema di messaggistica.

Problemi e considerazioni

Quando si decide come implementare questo modello, tenere presente quanto segue:

• Titolarità del ciclo di vita del payload. Definire il componente proprietario dell'eliminazione del payload e il modo in cui il componente determina che il payload non è necessario. Coordinare la scadenza dei messaggi e la conservazione del payload in modo che un claim check valido non rimandi a dati eliminati.

• Applicazione condizionale. Decidere se applicare il controllo delle attestazioni a tutti i messaggi oppure stabilire per ogni messaggio se applicarlo. Se è condizionale, assicurarsi che lo schema definisca se il payload è inline o esterno.

• Sicurezza di token e archivio Non incorporare i token di sicurezza come parte del controllo delle attestazioni. Mantenere l'autorizzazione come un'interazione indipendente tra i sistemi produttori o consumatori e l'archivio dati. Se la soluzione richiede che ai consumer sia concesso esplicitamente un accesso temporaneo, usa invece il Valet Key pattern.

• Coerenza del payload e del token. La scrittura del payload e la pubblicazione del token avvengono in sistemi separati e non fanno parte di un’unica transazione atomica. Un errore dopo la scrittura del payload ma prima della pubblicazione del token può lasciare un payload orfano. Un token pubblicato prima che il relativo payload sia recuperabile può comportare che i client ricevano riferimenti che non riescono a risolvere. Pubblicare il token solo dopo che la scrittura del payload ha esito positivo. Poiché i nuovi tentativi possono recapitare lo stesso claim check più di una volta, usare il pattern del consumer idempotente per gestire i duplicati in modo sicuro.

• Integrità del payload. Quando i consumer devono verificare l'integrità del payload, includere un hash del contenuto o una firma digitale nel messaggio. Definire un protocollo per i disallineamenti, ad esempio rifiutare il payload, ritentare il recupero o instradare il messaggio per ulteriori verifiche.

• Disponibilità e resistenza del payload. L'archivio dati esterno deve rimanere disponibile e persistente per tutto il periodo necessario alle applicazioni riceventi per recuperare il payload. Se l'archivio dati subisce un'interruzione o una perdita di dati, i consumer che dispongono di token validi non possono recuperare i payload e l'elaborazione dei messaggi si blocca.

• Latenza dell'hop di recupero. Il modello aggiunge viaggi di rete aggiuntivi rispetto al recapito dei messaggi inline. Le applicazioni riceventi devono chiamare l'archivio dati esterno per recuperare il payload prima che l'elaborazione possa iniziare.

• Supporto per la verifica delle dichiarazioni fornito dal framework. Usare le funzionalità offerte dall'SDK del bus di messaggi. Ad esempio, NServiceBus ha una funzionalità DataBus che può automatizzare l'archiviazione e il recupero del payload.

Quando usare questo modello

Usare questo modello quando:

• I payload dei messaggi superano regolarmente le dimensioni massime del messaggio supportate dal sistema di messaggistica. Il trasferimento del payload in un archivio dati esterno e la trasmissione del solo token leggero di claim check evitano i rifiuti dovuti ai limiti di dimensione.

• I messaggi di grandi dimensioni utilizzano risorse broker sproporzionate. I messaggi di grandi dimensioni influiscono sulle prestazioni del sistema di messaggistica aumentando la serializzazione e il tempo di trasferimento o riducendo la velocità effettiva per tutti i produttori e i consumer che condividono il sistema di messaggistica.

• I payload contengono informazioni riservate che non devono essere visibili al sistema di messaggistica o ai componenti intermedi, ad esempio gli strumenti di monitoraggio delle code. Applicare il modello all'intero payload o solo alle relative parti sensibili. Archiviare il contenuto sensibile in un archivio dati protetto con controlli di accesso dedicati per evitare il percorso di messaggistica.

• I messaggi hanno un routing complesso con serializzazione ripetuta. I messaggi attraversano più componenti di routing che eseguono la serializzazione, la deserializzazione, la crittografia o la decrittografia. Trasmettere solo un token di piccole dimensioni tramite intermediari per eliminare l'elaborazione ripetuta del payload completo a ogni hop e ridurre la latenza cumulativa.

Questo modello potrebbe non essere adatto quando:

• La sensibilità alla latenza supera i problemi relativi alle dimensioni del payload. I carichi di lavoro che richiedono la latenza end-to-end più bassa possibile tra producer e consumer potrebbero non tollerare gli hop di rete aggiunti per l'archiviazione e il recupero del payload. Se i messaggi possono essere recapitati inline senza superare le dimensioni o i limiti di prestazioni, il recapito diretto è più semplice e veloce.

• È possibile scegliere un trasporto o un livello che supporti le dimensioni del payload. Quando i payload restano entro il limite supportato dal trasporto e non causano problemi di prestazioni o latenze inaccettabili, inviali in linea per evitare la dipendenza da un archivio esterno. Ad esempio, bus di servizio di Azure livello Premium supporta messaggi AMQP (Advanced Message Queuing Protocol) fino a 100 MB. Mantenere i messaggi il più piccoli possibile, perché i messaggi di grandi dimensioni riducono la velocità effettiva e aumentano la latenza.

• Il coordinamento tra due sistemi non è possibile. Il modello richiede il coordinamento tra due sistemi indipendenti. Il valore del claim check deve essere scritto in modo che il sistema ricevente possa comprenderlo, e il suo formato potrebbe dover essere adattato nel tempo.

Alternative

Considerare questi approcci come alternative a questo modello:

• Ridurre le dimensioni del payload inline. La compressione può ridurre il testo ripetitivo o i payload binari e un serializzatore più compatto può ridurre il sovraccarico dei messaggi. Scegli questo approccio quando il payload ridotto rientra comodamente entro il limite del trasporto e ogni produttore e consumatore possono usare lo stesso formato di compressione e serializzazione.

• Dividere e aggregare il payload in modo naturale. Dividi un payload di grandi dimensioni in una sequenza di messaggi più piccoli quando i destinatari possono elaborare i blocchi in modo indipendente o riassemblarli dopo la consegna. Questo approccio mantiene i dati nel sistema di messaggistica, ma aggiunge requisiti di sequenziazione, correlazione, gestione duplicati e riassemblaggio. Per altre informazioni, vedere i modelli Splitter e Aggregator da Modelli di integrazione aziendale.

Progettazione del carico di lavoro

Valutare come usare il modello Claim Check nella progettazione di un workload per rispondere agli obiettivi e ai principi illustrati nei pilastri dell'Azure Well-Architected Framework. La tabella seguente fornisce indicazioni sul modo in cui questo modello supporta gli obiettivi dei pilastri.

Se questo modello introduce compromessi all'interno di un pilastro, considerarli contro gli obiettivi degli altri pilastri.

Esempi

Questa sezione contiene collegamenti agli esempi GitHub del modello cloud Claim Check che mostrano come i servizi di Azure implementano il modello Claim Check. Ogni esempio usa Archiviazione BLOB di Azure come archivio dati esterno e lo associa a un sistema di messaggistica Azure diverso. Gli esempi da 1 a 3 usano l'URL del blob in una notifica di Griglia di eventi di Azure come claim check. L'esempio 4 usa un claim check personalizzato pubblicato dall'applicazione mittente.

Negli esempi da 1 a 3:

1. Un'applicazione di invio carica un payload di grandi dimensioni per gestione rete virtuale di Azure.
2. Il caricamento attiva un evento Microsoft.Storage.BlobCreated tramite un argomento di sistema di Event Grid.
3. Event Grid instrada la notifica, che contiene un URL diretto del BLOB che gli esempi usano come claim check, al sistema di messaggistica configurato.
4. Un'applicazione ricevente, implementata come app per le funzioni Funzioni di Azure o client da riga di comando, recupera la notifica, estrae l'URL del BLOB e scarica il payload direttamente da gestione rete virtuale di Azure per l'elaborazione.

In un'implementazione di produzione è possibile filtrare la sottoscrizione di eventi in base alle operazioni che indicano un BLOB in blocchi con commit completo e progettare il ricevitore per gestire eventi ritardati, duplicati e non in ordine.

L'esempio 4 usa un approccio diverso. Anziché instradare una notifica di gestione rete virtuale di Azure tramite Event Grid, l'applicazione mittente costruisce il claim check dopo aver caricato il payload in gestione rete virtuale di Azure. L'applicazione di invio pubblica quindi il controllo dell'attestazione nel Hub eventi di Azure endpoint Kafka usando il protocollo Apache Kafka. Questo approccio si adatta agli ambienti che usano già producer compatibili con Kafka o richiedono formati di token personalizzati.

La tabella seguente elenca ciascun esempio con il relativo sistema di messaggistica, il publisher del claim check, l'applicazione ricevente e le dipendenze di archiviazione. Selezionare ogni collegamento per visualizzare il codice di esempio in GitHub.

Passaggi successivi

• Leggi la descrizione canonica di Enterprise Integration Patterns di Claim Check.
• Esamina un'altra implementazione in Gestione di messaggi di bus di servizio di grandi dimensioni tramite il claim check pattern.
• Scegliere tra Griglia di eventi di Azure, Hub eventi e bus di servizio.

Risorse correlate

• Schema di Request-Reply Asincrono
• Modello consumatori in concorrenza
• Modello di convoglio sequenziale
• Modello Di passeparte