Questo articolo descrive i diversi tipi di messaggi e le entità che partecipano a un'infrastruttura di messaggistica. In base ai requisiti di ogni tipo di messaggio, l'articolo consiglia i servizi di messaggistica di Azure. Le opzioni includono bus di servizio di Azure Messaggistica, Griglia di eventi di Azure e Hub eventi di Azure. Per il confronto dei prodotti, vedere Confrontare i servizi di messaggistica.
A livello di architettura, un messaggio è un datagramma creato da un'entità (producer), per distribuire le informazioni in modo che altre entità (consumer) possano essere consapevoli e agire di conseguenza. Il producer e il consumer possono comunicare direttamente o facoltativamente tramite un'entità intermedia (broker di messaggi). Questo articolo è incentrato sulla messaggistica asincrona tramite un broker di messaggi.
È possibile classificare i messaggi in due categorie principali. Se il producer prevede un'azione dal consumer, tale messaggio è un comando. Se il messaggio informa il consumer che è stata eseguita un'azione, il messaggio è un evento.
Comandi
Il producer invia un comando con la finalità che i consumer eseguiranno un'operazione nell'ambito di una transazione aziendale.
Un comando è un messaggio di valore elevato e deve essere recapitato almeno una volta. Se un comando viene perso, l'intera transazione aziendale potrebbe non riuscire. Inoltre, un comando non deve essere elaborato più di una volta. In questo modo potrebbe verificarsi una transazione errata. Un cliente potrebbe ricevere ordini duplicati o fatturati due volte.
I comandi vengono spesso usati per gestire il flusso di lavoro di una transazione business a più passaggi. A seconda della logica di business, il producer potrebbe aspettarsi che il consumer riconosca il messaggio e segnali i risultati dell'operazione. In base a tale risultato, il produttore potrebbe scegliere un corso di azione appropriato.
Eventi
Un evento è un tipo di messaggio che un producer genera per annunciare i fatti.
Il producer (noto come autore in questo contesto) non prevede che gli eventi comportino alcuna azione.
Gli utenti interessati possono sottoscrivere, ascoltare gli eventi e intraprendere azioni a seconda dello scenario di consumo. Gli eventi possono avere più sottoscrittori o nessun sottoscrittore. Due sottoscrittori diversi possono reagire a un evento con azioni diverse e non essere consapevoli l'uno dell'altro.
Il produttore e il consumatore sono ad accoppiamento libero e gestito in modo indipendente. Il producer non prevede che il consumer riconosci l'evento al producer. Un consumer che non è più interessato agli eventi può annullare la sottoscrizione, rimuovendo il consumer dalla pipeline senza influire sul producer o sulla funzionalità complessiva del sistema.
Esistono due categorie di eventi:
Il produttore genera eventi per annunciare fatti discreti. Un caso d'uso comune è la notifica degli eventi. Ad esempio, Azure Resource Manager genera eventi quando crea, modifica o elimina le risorse. Un sottoscrittore di tali eventi potrebbe essere un'app per la logica che invia messaggi di posta elettronica di avviso.
Il producer genera eventi correlati in una sequenza o in un flusso di eventi in un periodo di tempo. In genere, un flusso viene utilizzato per la valutazione statistica. La valutazione può essere eseguita all'interno di una finestra temporale o quando arrivano gli eventi. La telemetria è un caso d'uso comune, ad esempio il monitoraggio dell'integrità e del carico di un sistema. Un altro caso è lo streaming di eventi dai dispositivi IoT.
Un modello comune per l'implementazione della messaggistica di eventi è il modello Publisher-Subscriber .
Ruolo e vantaggi di un broker di messaggi
Un broker di messaggi intermedio offre la funzionalità di spostamento dei messaggi dal producer al consumer e può offrire maggiori vantaggi.
Disaccoppiamento
Un broker di messaggi separa il producer dal consumer nella logica che genera e usa rispettivamente i messaggi. In un flusso di lavoro complesso, il broker può incoraggiare le operazioni aziendali a essere disaccoppiate e a coordinare il flusso di lavoro.
Ad esempio, una singola transazione aziendale richiede operazioni distinte eseguite in una sequenza di logica di business. Il producer emette un comando che segnala a un consumer di avviare un'operazione. Il consumer riconosce il messaggio in una coda separata riservata per l'allineamento delle risposte per il produttore. Solo dopo aver ricevuto la risposta, il producer invia un nuovo messaggio per avviare l'operazione successiva nella sequenza. Un consumer diverso elabora il messaggio e invia un messaggio di completamento alla coda di risposta. Usando la messaggistica, i servizi coordinano il flusso di lavoro della transazione tra loro.
Un broker di messaggi fornisce il disaccoppiamento temporale. Il producer e il consumer non devono essere eseguiti contemporaneamente. Un producer può inviare un messaggio al broker di messaggi indipendentemente dalla disponibilità del consumer. Al contrario, il consumer non è limitato dalla disponibilità del produttore.
Ad esempio, l'interfaccia utente di un'app Web genera messaggi e usa una coda come broker di messaggi. Quando il consumer è pronto, può recuperare i messaggi dalla coda ed eseguire il lavoro. Il disaccoppiamento temporale consente all'interfaccia utente di rimanere reattiva. Non viene bloccato mentre i messaggi vengono gestiti in modo asincrono.
Il completamento di alcune operazioni può richiedere molto tempo. Dopo aver eseguito un comando, il producer non deve attendere il completamento del consumer. Un broker di messaggi consente l'elaborazione asincrona dei messaggi.
Bilanciamento del carico
I producer possono pubblicare un numero elevato di messaggi gestiti da molti consumer. Usare un broker di messaggi per distribuire l'elaborazione tra server e migliorare la velocità effettiva. I consumer possono essere eseguiti su server diversi per distribuire il carico. I consumer possono essere aggiunti dinamicamente per aumentare il numero di istanze del sistema quando necessario o rimosso in caso contrario.
Il modello Consumer concorrenti illustra come elaborare più messaggi contemporaneamente per ottimizzare la velocità effettiva, migliorare la scalabilità e la disponibilità e bilanciare il carico di lavoro.
Livellamento del carico
Il volume di messaggi generati dal producer o da un gruppo di produttori può essere variabile. A volte potrebbe verificarsi un volume elevato che causa picchi nei messaggi. Invece di aggiungere consumer per gestire questo lavoro, un broker di messaggi può fungere da buffer e i consumer svuotano gradualmente i messaggi al proprio ritmo senza stressare il sistema.
Il modello di livellamento del carico basato su coda fornisce altre informazioni.
Messaggistica affidabile
Un broker di messaggi garantisce che i messaggi non vengano persi anche se la comunicazione non riesce tra il producer e il consumer. Il producer può pubblicare messaggi nel broker di messaggi e il consumer può recuperarli quando la comunicazione viene ristabilita. Il producer non viene bloccato a meno che non perda la connettività con il broker di messaggi.
Messaggistica resiliente
Un broker di messaggi può aggiungere resilienza ai consumer nel sistema. Se un consumer non riesce durante l'elaborazione di un messaggio, un'altra istanza del consumer può elaborare tale messaggio. La rielaborazione è possibile perché il messaggio persiste nel broker.
Scelte tecnologico per un broker di messaggi
Azure offre diversi servizi broker di messaggi, ognuno con una gamma di funzionalità. Prima di scegliere un servizio, determinare la finalità e i requisiti del messaggio.
Messaggistica del bus di servizio di Azure
bus di servizio di Azure code di messaggistica sono particolarmente adatte per il trasferimento di comandi dai producer ai consumer. Ecco alcune considerazioni.
Modello di pull
Un consumer di una coda bus di servizio esegue costantemente il polling bus di servizio per verificare se sono disponibili nuovi messaggi. Gli SDK client e Funzioni di Azure trigger per bus di servizio astrarre tale modello. Quando è disponibile un nuovo messaggio, viene richiamato il callback del consumer e il messaggio viene inviato al consumer.
Recapito garantito
bus di servizio consente a un consumer di visualizzare la coda e bloccare un messaggio da altri consumer.
È responsabilità dell'utente segnalare lo stato di elaborazione del messaggio. Solo quando il consumer contrassegna il messaggio come utilizzato bus di servizio rimuovere il messaggio dalla coda. Se si verifica un errore, un timeout o un arresto anomalo, bus di servizio sblocca il messaggio in modo che altri consumer possano recuperarlo. In questo modo, i messaggi non vengono persi nel trasferimento.
Un producer potrebbe inviare accidentalmente lo stesso messaggio due volte. Ad esempio, un'istanza producer ha esito negativo dopo l'invio di un messaggio. Un altro producer sostituisce l'istanza originale e invia di nuovo il messaggio. bus di servizio di Azure code offrono una funzionalità predefinita di deduplicazione che rileva e rimuove i messaggi duplicati. È comunque possibile che un messaggio venga recapitato due volte. Ad esempio, se un consumer non riesce durante l'elaborazione, il messaggio viene restituito alla coda e viene recuperato dallo stesso consumer o da un altro consumer. La logica di elaborazione dei messaggi nel consumer deve essere idempotente in modo che, anche se il lavoro viene ripetuto, lo stato del sistema non viene modificato.
Ordinamento dei messaggi
Se si vuole che i consumer ottengano i messaggi nell'ordine in cui vengono inviati, bus di servizio code garantiscono il recapito ordinato FIFO (First-In-First Out) usando le sessioni. Una sessione può avere uno o più messaggi. I messaggi sono correlati alla proprietà SessionId . I messaggi che fanno parte di una sessione non scadono mai. Una sessione può essere bloccata a un consumer per impedire che i messaggi vengano gestiti da un consumer diverso.
Per altre informazioni, vedere Sessioni di messaggi.
Persistenza dei messaggi
Le code del bus di servizio supportano il disaccoppiamento temporale. Anche quando un consumer non è disponibile o non è in grado di elaborare il messaggio, rimane nella coda.
Transazioni con esecuzione prolungata del checkpoint
Le transazioni aziendali possono essere eseguite per molto tempo. Ogni operazione nella transazione può avere più messaggi. Usare il checkpoint per coordinare il flusso di lavoro e fornire resilienza in caso di errore di una transazione.
bus di servizio code consentono il checkpoint tramite la funzionalità di stato della sessione. Le informazioni sullo stato vengono registrate in modo incrementale nella coda (SetState) per i messaggi che appartengono a una sessione. Ad esempio, un consumer può tenere traccia dello stato controllando lo stato (GetState) ogni ora e poi. Se un consumer ha esito negativo, un altro consumer può usare le informazioni sullo stato per determinare l'ultimo checkpoint noto per riprendere la sessione.
Coda di messaggi non recapitabili (DLQ)
Una coda bus di servizio ha una coda secondaria predefinita, denominata coda di messaggi non recapitabili (DLQ) per contenere messaggi che non possono essere recapitati o elaborati. bus di servizio o la logica di elaborazione dei messaggi nel consumer può aggiungere messaggi alla DQ. La DQ mantiene i messaggi fino a quando non vengono recuperati dalla coda.
Ecco alcuni esempi di quando un messaggio può trovarsi nella DQ:
Un messaggio non elaborabile è un messaggio che non può essere gestito perché non è valido o contiene informazioni impreviste. Nelle code bus di servizio è possibile rilevare i messaggi non elaborabili impostando la proprietà MaxDeliveryCount della coda. Se il numero di volte in cui viene ricevuto lo stesso messaggio supera il valore della proprietà, bus di servizio sposta il messaggio nella DQ.
Un messaggio potrebbe non essere più rilevante se non viene elaborato entro un periodo. bus di servizio code consentono al producer di pubblicare messaggi con un attributo time-to-live. Se questo periodo scade prima della ricezione del messaggio, il messaggio viene inserito nella DQ.
Esaminare i messaggi nella DQ per determinare il motivo dell'errore.
Soluzione ibrida
bus di servizio bridge su sistemi locali e soluzioni cloud. I sistemi locali sono spesso difficili da raggiungere a causa di restrizioni del firewall. Sia il producer che il consumer (possono essere in locale o nel cloud) possono usare l'endpoint della coda bus di servizio come percorso di ritiro e rilascio per i messaggi.
Il modello Messaging Bridge è un altro modo per gestire questi scenari.
Argomenti e sottoscrizioni
bus di servizio supporta il modello Publisher-Subscriber tramite bus di servizio argomenti e sottoscrizioni.
Questa funzionalità consente al producer di trasmettere messaggi a più consumer. Quando un argomento riceve un messaggio, viene inoltrato a tutti i consumer sottoscritti. Facoltativamente, una sottoscrizione può avere criteri di filtro che consentono al consumer di ottenere un subset di messaggi. Ogni consumer recupera i messaggi da una sottoscrizione in modo analogo a una coda.
Per altre informazioni, vedere bus di servizio di Azure argomenti.
Griglia di eventi di Azure
È consigliabile Griglia di eventi di Azure per eventi discreti. Griglia di eventi segue il modello Publisher-Subscriber. Quando le origini eventi attivano eventi, vengono pubblicate negli argomenti di Griglia di eventi. I consumer di tali eventi creano sottoscrizioni di Griglia di eventi specificando i tipi di evento e il gestore eventi che elaborano gli eventi. Se non sono presenti sottoscrittori, gli eventi vengono eliminati. Ogni evento può avere più sottoscrizioni.
Modello di push
Griglia di eventi propaga i messaggi ai sottoscrittori in un modello push. Si supponga di avere una sottoscrizione di Griglia di eventi con un webhook. Quando arriva un nuovo evento, Griglia di eventi invia l'evento all'endpoint del webhook.
Integrazione con Azure
Scegliere Griglia di eventi se si vogliono ricevere notifiche sulle risorse di Azure. Molti servizi di Azure fungono da origini eventi con argomenti predefiniti di Griglia di eventi. Griglia di eventi supporta anche vari servizi di Azure che possono essere configurati come gestori eventi. È facile sottoscrivere questi argomenti per instradare gli eventi ai gestori eventi di propria scelta. Ad esempio, è possibile usare Griglia di eventi per richiamare una funzione di Azure quando un archivio BLOB viene creato o eliminato.
Argomenti personalizzati
Creare argomenti personalizzati di Griglia di eventi se si vogliono inviare eventi dall'applicazione o da un servizio di Azure che non è integrato con Griglia di eventi.
Ad esempio, per visualizzare lo stato di avanzamento di un'intera transazione aziendale, si vuole che i servizi partecipanti generino eventi durante l'elaborazione delle singole operazioni aziendali. Un'app Web mostra tali eventi. Un modo per eseguire questa attività consiste nel creare un argomento personalizzato e aggiungere una sottoscrizione con l'app Web registrata tramite un webhook HTTP. Man mano che i servizi aziendali inviano eventi all'argomento personalizzato, Griglia di eventi li inserisce nell'app Web.
Eventi filtrati
È possibile specificare filtri in una sottoscrizione per indicare a Griglia di eventi di instradare solo un subset di eventi a un gestore eventi specifico. Specificare i filtri nello schema della sottoscrizione. Qualsiasi evento inviato all'argomento con valori corrispondenti al filtro viene inoltrato automaticamente a tale sottoscrizione.
Ad esempio, il contenuto in vari formati viene caricato in Blob Archiviazione. Ogni volta che viene aggiunto un file, viene generato e pubblicato un evento in Griglia di eventi. La sottoscrizione di eventi potrebbe avere un filtro che invia solo gli eventi per le immagini in modo che un gestore eventi possa generare anteprime.
Per altre informazioni sul filtro, vedere Filtrare gli eventi per Griglia di eventi.
Velocità effettiva elevata
Griglia di eventi può instradare 10.000.000 eventi al secondo per area. Le prime 100.000 operazioni al mese sono gratuite. Per considerazioni sul costo, vedere Quanto costa Griglia di eventi?
Recapito resiliente
Anche se il recapito riuscito per gli eventi non è fondamentale come i comandi, è comunque possibile che si vogliano avere una garanzia a seconda del tipo di evento. Griglia di eventi offre funzionalità che è possibile abilitare e personalizzare, ad esempio criteri di ripetizione dei tentativi, ora di scadenza e messaggi non recapitabili. Per altre informazioni, vedere Recapito di messaggi di Griglia di eventi e nuovi tentativi.
Il processo di ripetizione dei tentativi di Griglia di eventi può contribuire alla resilienza, ma non è sicuro per gli errori. Nel processo di ripetizione dei tentativi, Griglia di eventi potrebbe recapitare il messaggio più di una volta, ignorare o ritardare alcuni tentativi se l'endpoint non risponde per molto tempo. Per altre informazioni, vedere La pianificazione dei tentativi.
È possibile rendere persistenti gli eventi non recapitati in un account di archiviazione BLOB abilitando l'inserimento di messaggi non recapitabili. Si verifica un ritardo nel recapito del messaggio all'endpoint di archiviazione BLOB e, se tale endpoint non risponde, Griglia di eventi elimina l'evento. Per altre informazioni, vedere Impostare la posizione dei messaggi non recapitabili e i criteri di ripetizione dei tentativi.
Hub eventi di Azure
Quando si usa un flusso di eventi, Hub eventi di Azure è il broker di messaggi consigliato. Essenzialmente, si tratta di un buffer di grandi dimensioni in grado di ricevere grandi volumi di dati con bassa latenza. I dati ricevuti possono essere letti rapidamente tramite operazioni simultanee. È possibile trasformare i dati ricevuti usando qualsiasi provider di analisi in tempo reale. Hub eventi offre anche la possibilità di archiviare gli eventi in un account di archiviazione.
Inserimento rapido
Hub eventi è in grado di inserire milioni di eventi al secondo. Gli eventi vengono aggiunti solo al flusso e vengono ordinati in base all'ora.
Modello di pull
Analogamente a Griglia di eventi, Hub eventi offre anche funzionalità del Sottoscrittore del server di pubblicazione. Una differenza fondamentale tra Griglia di eventi e Hub eventi consiste nel modo in cui i dati degli eventi sono resi disponibili ai sottoscrittori. Griglia di eventi inserisce i dati inseriti nei sottoscrittori, mentre Hub eventi rende i dati disponibili in un modello di pull. Quando gli eventi vengono ricevuti, Hub eventi li aggiunge al flusso. Un sottoscrittore gestisce il cursore e può spostarsi avanti e indietro nel flusso, selezionare un offset temporale e riprodurre una sequenza al ritmo.
I processori di flusso sono sottoscrittori che eseguono il pull dei dati da Hub eventi ai fini della trasformazione e dell'analisi statistica. Usare Analisi di flusso di Azure e Apache Spark per l'elaborazione complessa, ad esempio l'aggregazione nel tempo o il rilevamento anomalie.
Se si vuole agire su ogni evento per partizione, è possibile eseguire il pull dei dati usando l'host processore di eventi o usando un connettore predefinito, ad esempio App per la logica di Azure per fornire la logica di trasformazione. Un'altra opzione consiste nell'usare Funzioni di Azure.
Partizionamento
Una partizione è una parte del flusso di eventi. Gli eventi vengono divisi usando una chiave di partizione. Ad esempio, diversi dispositivi IoT inviano i dati del dispositivo a un hub eventi. La chiave di partizione è l'identificatore del dispositivo. Man mano che gli eventi vengono inseriti, Hub eventi li sposta in partizioni separate. All'interno di ogni partizione, tutti gli eventi vengono ordinati in base all'ora.
Un consumer è un'istanza di codice che elabora i dati dell'evento. Hub eventi segue un modello consumer partizionato. Ogni consumer legge solo una partizione specifica. La presenza di più partizioni comporta un'elaborazione più rapida perché il flusso può essere letto simultaneamente da più consumer.
Le istanze dello stesso consumer costituiscono un singolo gruppo di consumer. Più gruppi di consumer possono leggere lo stesso flusso con intenzioni diverse. Si supponga che un flusso di eventi disponga di dati da un sensore di temperatura. Un gruppo di consumer può leggere il flusso per rilevare anomalie, ad esempio un picco di temperatura. Un altro può leggere lo stesso flusso per calcolare una temperatura media mobile in una finestra temporale.
Hub eventi supporta il modello Publisher-Subscriber consentendo più gruppi di consumer. Ogni gruppo di consumer è un sottoscrittore.
Per altre informazioni sul partizionamento di Hub eventi, vedere Partizioni.
Acquisizione di Hub eventi
La funzionalità Di acquisizione consente di archiviare il flusso di eventi in un archivio BLOB di Azure o in data lake Archiviazione. Questo modo di archiviare gli eventi è affidabile perché anche se l'account di archiviazione non è disponibile, Capture mantiene i dati per un periodo, quindi scrive nella risorsa di archiviazione dopo che è disponibile.
Archiviazione servizi possono anche offrire funzionalità aggiuntive per l'analisi degli eventi. Ad esempio, sfruttando i livelli di accesso di un account di archiviazione BLOB, è possibile archiviare gli eventi in un livello ad accesso frequente per i dati che richiedono l'accesso frequente. È possibile usare tali dati per la visualizzazione. In alternativa, è possibile archiviare i dati nel livello archivio e recuperarli occasionalmente a scopo di controllo.
Capture archivia tutti gli eventi inseriti da Hub eventi ed è utile per l'elaborazione batch. È possibile generare report sui dati usando una funzione MapReduce. I dati acquisiti possono fungere anche da fonte di verità. Se alcuni fatti non sono stati rilevati durante l'aggregazione dei dati, è possibile fare riferimento ai dati acquisiti.
Per informazioni dettagliate su questa funzionalità, vedere Acquisire eventi tramite Hub eventi di Azure in Archiviazione BLOB di Azure o Azure Data Lake Archiviazione.
Supporto per i client Apache Kafka
Hub eventi fornisce un endpoint per i client Apache Kafka . I client esistenti possono aggiornare la configurazione in modo che punti all'endpoint e inizino a inviare eventi a Hub eventi. Non è necessario apportare modifiche al codice.
Per altre informazioni, vedere Hub eventi per Apache Kafka.
Scenari crossover
In alcuni casi, è vantaggioso combinare due servizi di messaggistica.
La combinazione dei servizi può aumentare l'efficienza del sistema di messaggistica. Ad esempio, nella transazione aziendale si usano le code bus di servizio di Azure per gestire i messaggi. Le code che sono principalmente inattive e ricevono messaggi occasionalmente sono inefficienti, perché il consumer esegue costantemente il polling della coda per i nuovi messaggi. È possibile configurare una sottoscrizione di Griglia di eventi con una funzione di Azure come gestore eventi. Ogni volta che la coda riceve un messaggio e non sono presenti consumer in ascolto, Griglia di eventi invia una notifica, che richiama la funzione di Azure che svuota la coda.
Per informazioni dettagliate sulla connessione di bus di servizio a Griglia di eventi, vedere bus di servizio di Azure alla panoramica dell'integrazione di Griglia di eventi.
L'integrazione aziendale che usa code di messaggi ed architettura di riferimento agli eventi mostra un'implementazione di bus di servizio all'integrazione di Griglia di eventi.
Ecco un altro esempio: Griglia di eventi riceve un set di eventi in cui alcuni eventi richiedono un flusso di lavoro mentre altri sono per la notifica. I metadati del messaggio indicano il tipo di evento. Un modo per distinguere è controllare i metadati usando la funzionalità di filtro nella sottoscrizione di eventi. Se richiede un flusso di lavoro, Griglia di eventi lo invia a bus di servizio di Azure coda. I ricevitori di tale coda possono eseguire le azioni necessarie. Gli eventi di notifica vengono inviati ad App per la logica per inviare messaggi di posta elettronica di avviso.
Modelli correlati
Quando si implementa la messaggistica asincrona, considerare questi modelli:
- Modello di consumer concorrenti. È possibile che più consumer debbano competere per leggere i messaggi da una coda. Questo modello illustra come elaborare più messaggi contemporaneamente per ottimizzare la velocità effettiva, migliorare la scalabilità e la disponibilità e bilanciare il carico di lavoro.
- Schema di coda di priorità. Nei casi in cui la logica di business richiede che alcuni messaggi vengano elaborati prima di altri, questo modello descrive come i messaggi inviati da un producer con priorità più alta vengono ricevuti ed elaborati più rapidamente da un consumer rispetto ai messaggi con priorità inferiore.
- Schema di livellamento del carico basato sulle code. Questo modello usa un broker di messaggi per fungere da buffer tra un producer e un consumer per ridurre al minimo l'impatto sulla disponibilità e sulla velocità di risposta di carichi pesanti intermittenti per entrambe le entità.
- Modello di ripetizione dei tentativi. Un producer o un consumer potrebbe non essere in grado di connettersi a una coda, ma i motivi di questo errore potrebbero essere temporanei e rapidi. Questo modello descrive come gestire questa situazione per aggiungere resilienza a un'applicazione.
- Modello supervisore agente dell'utilità di pianificazione. La messaggistica viene spesso usata come parte di un'implementazione del flusso di lavoro. Questo modello illustra come la messaggistica può coordinare un set di azioni in un set distribuito di servizi e altre risorse remote e consentire a un sistema di ripristinare e ripetere le azioni che hanno esito negativo.
- Modello coreografico. Questo modello illustra come i servizi possono usare la messaggistica per controllare il flusso di lavoro di una transazione aziendale.
- Modello Claim-Check. Questo modello illustra come suddividere un messaggio di grandi dimensioni in un controllo attestazioni e un payload.
Risorse della community
Post di blog di Jonathon Oliver: Idempotency
Post di blog di Martin Fowler: Cosa intendi per "Event-Driven"?