Modello di transazioni di compensazione

Usare questo modello per annullare il funzionamento quando uno o più passaggi hanno esito negativo in un'operazione finale coerente. Le applicazioni ospitate nel cloud che implementano processi aziendali complessi e flussi di lavoro usano in genere operazioni che seguono il modello di coerenza finale.

Contesto e problema

Le applicazioni cloud modificano spesso i dati distribuiti tra varie origini dati in posizioni geografiche diverse. Per evitare conflitti e migliorare le prestazioni in un ambiente distribuito, le applicazioni devono implementare la coerenza finale anziché una coerenza transazionale assoluta. Nel modello di coerenza finale, un'operazione aziendale tipica è costituita da una serie di passaggi separati. Durante questi passaggi, la visualizzazione generale dello stato del sistema potrebbe non essere coerente. Ma il sistema dovrebbe diventare di nuovo coerente al termine di tutti i passaggi.

La gestione degli errori dei passaggi presenta una sfida fondamentale nel modello di coerenza finale. Dopo un errore, potrebbe essere necessario annullare il lavoro dai passaggi dell'operazione completati. Tuttavia, non è sempre possibile eseguire il rollback dei dati perché altre istanze dell'applicazione simultanee potrebbero modificare i dati. Anche quando le istanze simultanee non modificano i dati, può essere più complesso annullare un passaggio che ripristinare lo stato originale. Potrebbe essere necessario applicare regole specifiche dell'azienda. Per un esempio, vedere l'esempio del sito Web di viaggio.

Quando un'operazione che implementa la coerenza finale si estende su più archivi dati, è necessario accedere a ogni archivio dati per annullare le modifiche. Per evitare che il sistema rimanga incoerente, è necessario annullare in modo affidabile il lavoro in ogni archivio dati.

Un'operazione che implementa la coerenza finale non archivia sempre i dati interessati in un database. Ad esempio, in un ambiente SOA (Service-Oriented Architecture), un'operazione può richiamare un'azione in un servizio e modificare lo stato che il servizio contiene. Per annullare l'operazione, è anche necessario annullare questa modifica dello stato, che può comportare la chiamata del servizio di nuovo per invertire gli effetti della prima azione.

Soluzione

Implementare una transazione di compensazione che annulla gli effetti dei passaggi completati nell'operazione originale. Si potrebbe pensare di poter semplicemente ripristinare il sistema allo stato originale, ma questo approccio può sovrascrivere le modifiche da altre istanze dell'applicazione simultanee. La transazione di compensazione deve invece tenere conto in modo intelligente del lavoro simultaneo. Questo processo è in genere specifico dell'applicazione e dipende dall'operazione originale.

È possibile usare un flusso di lavoro per implementare un'operazione coerente alla fine che richiede una compensazione. Durante l'esecuzione dell'operazione originale, il sistema registra informazioni su ogni passaggio e su come annullarlo. Se l'operazione non riesce, il flusso di lavoro viene riavvolso attraverso i passaggi completati e inverte ogni passaggio.

Diagramma che mostra un flusso di lavoro con passaggi successivi e azioni di compensazione. Un utente avvia un'operazione che esegue il passaggio 1, il passaggio 2 e il passaggio 3 in sequenza. Se tutti i passaggi hanno esito positivo, il processo viene completato. Se si verifica un errore dopo qualsiasi passaggio, le azioni di compensazione vengono eseguite in ordine inverso per annullare il lavoro completato, che termina con uno stato compensato.

Mentre ogni passaggio è un'azione separata, insieme formano un'operazione coerente alla fine. Il sistema deve eseguire i passaggi e le operazioni di annullamento corrispondenti per ogni passaggio. Se il cliente annulla, queste operazioni di annullamento possono essere eseguite come transazione di compensazione.

Un errore in un singolo passaggio non richiede sempre di eseguire il rollback dell'intero sistema usando una transazione di compensazione. Ad esempio, in uno scenario di sito Web di viaggio, un cliente prenota i voli F1, F2 e F3, ma non riesce a prenotare una stanza in hotel H1. Offrire al cliente una stanza in un hotel diverso è preferibile annullare i voli. Il cliente può comunque scegliere di annullare, che attiva la transazione di compensazione per annullare le prenotazioni dei voli. Tuttavia, il cliente deve prendere questa decisione, non il sistema. Quando le decisioni sono ad alto impatto o difficili da automatizzare in modo affidabile, includere un essere umano nel processo decisionale.

Considerare questi punti importanti:

• Una transazione di compensazione potrebbe non dover annullare il lavoro nell'ordine inverso esatto dell'operazione originale.

• Potrebbe essere possibile eseguire alcuni passaggi di annullamento in parallelo.

• Potrebbe essere necessario applicare regole specifiche dell'azienda. Ad esempio, l'annullamento di una prenotazione di volo potrebbe non autorizzare il cliente a un rimborso completo.

Questo approccio è simile al modello di transazioni distribuite Saga.

Le transazioni di compensazione sono infine operazioni coerenti e possono non riuscire. Il sistema deve registrare lo stato di avanzamento in modo che possa riprendere la transazione di compensazione dal punto di errore. Un passaggio può essere eseguito più volte quando si ritenta, quindi progettare ogni passaggio come comando idempotente.

A volte l'intervento manuale è l'unico modo per eseguire il ripristino da un passaggio non riuscito. In queste situazioni, il sistema deve generare un avviso che include informazioni dettagliate sul motivo dell'errore.

Problemi e considerazioni

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

• Potrebbe non essere facile determinare quando un passaggio di un'operazione che implementa la coerenza finale non riesce. Un passaggio potrebbe non fallire immediatamente, ma potrebbe essere bloccato. Potrebbe essere necessario implementare un meccanismo di timeout.

• Non è facile generalizzare la logica di compensazione. Una transazione di compensazione è specifica dell'applicazione. Dipende dal fatto che l'applicazione disponga di informazioni sufficienti per annullare gli effetti di ciascun passaggio in caso di operazione non riuscita.

• Le transazioni di compensazione non funzionano sempre. Definire i passaggi in una transazione di compensazione come comandi idempotenti in modo da poterli ripetere se la transazione di compensazione stessa ha esito negativo.

• L'infrastruttura che gestisce i passaggi deve soddisfare i criteri seguenti:

  • È resiliente sia nell'operazione originale che nella transazione di compensazione.

  • Non perde le informazioni necessarie per compensare un passaggio mancato.

  • Monitora in modo affidabile lo stato della logica di compensazione. Le transazioni di compensazione vengono eseguite dopo il commit delle operazioni originali e altre transazioni potrebbero modificare gli stati intermedi. Assicurarsi pertanto di poter correlare e controllare sia l'operazione originale che la relativa compensazione end-to-end.

• Una transazione di compensazione non restituisce necessariamente i dati di sistema allo stato all'inizio dell'operazione originale. Al contrario, la transazione compensa il lavoro che l'operazione ha completato con successo prima di fallire.

• I passaggi delle transazioni di compensazione non sempre invertono l'operazione originale nell'ordine esatto opposto. Ad esempio, se un archivio dati è più sensibile alle incoerenze rispetto a un altro, annullare prima le modifiche apportate a tale archivio.

• Alcune misure consentono di migliorare i tassi di successo. È possibile inserire un blocco a breve termine con un timeout per ogni risorsa necessaria per completare un'operazione. È possibile acquisire queste risorse in anticipo e quindi eseguire operazioni solo dopo l'acquisizione di tutte le risorse. Finalizzare tutte le azioni prima della scadenza dei blocchi.

• La logica di ripetizione dei tentativi che considera più errori come temporanei può aiutare a ridurre al minimo gli errori che attivano una transazione di compensazione. Quando un passaggio di un'operazione che implementa la coerenza finale non riesce, gestirlo come eccezione temporanea e riprovare a eseguire il passaggio. Arrestare l'operazione e attivare la compensazione solo se il passaggio ha esito negativo ripetutamente o non è possibile recuperarlo. Per altre informazioni sulle strategie di ripetizione dei tentativi, vedere Gestione degli errori temporanei.

• Quando si implementa una transazione di compensazione, si riscontrano molte sfide simili all'implementazione della coerenza finale. Per altre informazioni, vedere Ridurre al minimo il coordinamento.

• Definire punti di non ritorno e passaggi irreversibili. Nei flussi di lavoro complessi non è possibile annullare in modo sicuro o significativo alcune operazioni, ad esempio effetti collaterali esterni o azioni legalmente vincolanti. Identificare i passaggi compensabili e irreversibili. Progettare il flusso di lavoro in modo che i passaggi irreversibili si verifichino solo dopo l'esito positivo di tutte le convalide critiche.

Quando usare questo modello

Usare questo modello quando:

• Un'operazione aziendale si estende su più passaggi, servizi o archivi dati e deve essere annullata se un passaggio successivo ha esito negativo. Questo scenario si verifica spesso in flussi di lavoro a esecuzione prolungata che seguono un modello di coerenza finale e non possono basarsi su transazioni atomiche.

• Il recupero dai guasti richiede spesso una logica specifica del dominio anziché un semplice rollback dei dati. Usare le azioni di compensazione quando si annulla il lavoro richiede l'applicazione di regole business, ad esempio l'annullamento delle prenotazioni o l'emissione di rimborsi parziali.

Questo modello potrebbe non essere adatto quando:

• Le operazioni possono essere ritentate in modo sicuro e la maggior parte degli errori è temporanea. La logica di ripetizione dei tentativi è spesso sufficiente in questi casi e le transazioni di compensazione aggiungono complessità non necessarie.

• Il sistema non può tollerare l'incoerenza temporanea o la compensazione non può ripristinare in modo affidabile uno stato valido. Usare invece meccanismi di coerenza assoluta o transazioni atomiche in tutti i passaggi.

Progettazione del carico di lavoro

Valutare come usare la transazione di compensazione nella progettazione di un carico di lavoro per soddisfare gli obiettivi e i principi trattati nei pilastri Azure Well-Architected Framework. La tabella seguente fornisce indicazioni su come questo modello supporta gli obiettivi di ogni pilastro.

Pilastro	Come questo modello supporta gli obiettivi di pilastro
decisioni di progettazione dell'affidabilità consentono al carico di lavoro di diventare resiliente a un malfunzionamento e assicurano che ripristini a uno stato completamente funzionante dopo che si verifica un guasto.	Le azioni di compensazione consentono di risolvere i malfunzionamenti nei percorsi critici del carico di lavoro usando processi come il rollback diretto delle modifiche dei dati, l'interruzione dei blocchi delle transazioni o persino l'esecuzione del comportamento del sistema nativo per invertire l'effetto. - Flussi critici RE:02 - RE:09 Ripristino di emergenza

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

Esempio

Il diagramma seguente illustra un'implementazione pratica Azure del modello di transazione di compensazione. Altre implementazioni possono essere adatte anche per i requisiti del carico di lavoro. Un agente di orchestrazione eseguito in Azure Container Apps coordina ogni passaggio di un flusso di lavoro a esecuzione prolungata inviando comandi tramite Azure Service Bus. Man mano che ogni passaggio successivo ha esito positivo, l'agente di orchestrazione registra sia lo stato di esecuzione che l'azione di compensazione corrispondente in Azure Cosmos DB in modo che il flusso di lavoro possa essere ripreso, correlato e controllato.

Diagramma che mostra un flusso di lavoro in un ambiente Azure Container Apps. Un client invia una richiesta a un contenitore di orchestrazione, che coordina il servizio A e il servizio B e registra le operazioni. I messaggi dei passaggi 1 e 2 fluiscono attraverso il Service Bus. Se un passaggio ha esito negativo, le azioni di compensazione vengono eseguite in ordine inverso. I messaggi non riusciti vengono spostati in una coda di messaggi non recapitabili. L'ambiente si integra con Microsoft Entra ID per identità e Application Insights e Azure Monitor per l'osservabilità.

Questo modello utilizza prima i ritenti per preservare il progresso. Se un passaggio ha esito negativo, l'agente di orchestrazione applica la logica di ripetizione dei tentativi per gli errori temporanei e tenta di continuare l'operazione originale. La compensazione viene richiamata solo quando lo stato di avanzamento diventa impossibile, ad esempio quando i tentativi vengono esauriti o l'errore viene classificato come non transitorio.

Le regole specifiche dell'azienda possono anche preferire lo stato di avanzamento rispetto alla compensazione immediata. Se un passaggio ha esito negativo, l'agente di orchestrazione può selezionare un percorso alternativo, ad esempio sostituendo un servizio equivalente o un'opzione di fallback, anziché eseguire il rollback del flusso di lavoro. Per i casi ad impatto elevato o ambiguo, è possibile sospendere il flusso di lavoro per la revisione umana prima di decidere se continuare in un percorso alternativo o attivare la compensazione. Questo approccio considera la compensazione come ultima risorsa e consente alle regole di dominio di guidare le decisioni di ripristino.

In una sequenza tipica, l'agente di orchestrazione invia messaggi di passaggio attraverso Service Bus (passaggi 1 e 2), riceve risultati riusciti e archivia i metadati di inoltro e compensazione in Azure Cosmos DB.

È possibile attivare la compensazione in due modi:

• Quando un passaggio successivo nello stesso carico di lavoro ha esito negativo ed è necessario annullare i passaggi riusciti in precedenza. Questa compensazione può avvenire immediatamente quando un passaggio restituisce un errore aziendale, come nel caso di un errore di convalida delle regole, oppure dopo che i tentativi tecnici sono stati esauriti e il messaggio viene spostato nella coda dei messaggi non recapitabili (dead-letter queue).

• Quando un client successivo richiede esplicitamente di annullare un'operazione completata.

In entrambi i casi, l'agente di orchestrazione legge i record di compensazione archiviati e invia comandi di compensazione al servizio corrispondente. Se un passaggio di compensazione fallisce temporaneamente, i tentativi di Service Bus possono completarlo senza esacerbare l'incidente.

Se i tentativi ripetuti continuano a non riuscire, Service Bus sposta il messaggio in una coda di messaggi non recapitabili, conservando i dettagli dell'errore. L'agente di orchestrazione, o un dead-letter processor dedicato, genera un avviso ed emette dati di telemetria strutturati, inclusi i motivi degli errori e gli ID di correlazione, per Azure Monitor e Log Analytics, che possono emergere in Application Insights. Questo percorso operativo consente ai team di diagnosticare gli errori, determinare la necessità di intervento manuale e mantenere la tracciabilità nei flussi originali e di compensazione.

Il flusso di lavoro può avviare automaticamente la compensazione per condizioni chiare e a basso rischio o sospendere la revisione umana quando la situazione è ambigua, con un impatto elevato o richiede una decisione manuale.

Usare le identità gestite e l'autorizzazione basata su Microsoft Entra ID tra i componenti per evitare segreti condivisi e applicare l'accesso con privilegi minimi. Quando si crea un diagramma di riferimento semplificato, considerare questi controlli di identità e autorizzazione come problemi di implementazione di base anziché passaggi espliciti del flusso. Mantenere il diagramma incentrato sull'orchestrazione, sui tentativi, sulla compensazione e sulla gestione degli errori.

" output is necessary.)

• Considerazioni sui dati per i microservizi: informazioni sul motivo per cui la coerenza finale e l'errore parziale sono intrinseci nei sistemi distribuiti. Il modello di transazione di compensazione fornisce un meccanismo concreto per gestire tali errori quando le operazioni si estendono su più servizi.

• Modello outbox transazionale con Azure Cosmos DB: Usare questo modello quando le transazioni di compensazione devono pubblicare eventi o comandi in modo affidabile. Consente di garantire che le modifiche di stato e i messaggi vengano registrati in modo atomico, che impedisce la perdita di messaggi.

• Progettazione per la riparazione automatica: usare transazioni di compensazione come parte di un approccio di riparazione automatica per le applicazioni.

• Modello Scheduler Agent Supervisor: utilizzare questo modello per implementare sistemi resilienti che eseguono operazioni aziendali attraverso servizi e risorse distribuiti. Questi sistemi a volte necessitano di transazioni di compensazione per annullare il lavoro.

• Modello di ripetizione dei tentativi: usare questo modello per gestire gli errori temporanei e ridurre al minimo la necessità di compensare le transazioni.

• Modello di transazioni distribuite saga: usare questo modello per gestire la coerenza dei dati tra microservizi nelle transazioni distribuite. Saga utilizza transazioni compensative per il recupero dai guasti.

• Modello Pipe e Filtri: utilizzare questo modello con il modello di Transazione Compensativa come alternativa alle transazioni distribuite quando si scompongono le attività complesse in fasi riutilizzabili.