Lo schema di progettazione Saga consente di mantenere la coerenza dei dati nei sistemi distribuiti coordinando le transazioni tra più servizi. Una saga è una sequenza di transazioni locali in cui ogni servizio esegue l'operazione e avvia il passaggio successivo tramite eventi o messaggi. Se un passaggio della sequenza non riesce, la saga esegue transazioni di compensazione per annullare i passaggi completati. Questo approccio consente di mantenere la coerenza dei dati.
Contesto e problema
Una transazione rappresenta un'unità di lavoro, che può includere più operazioni. All'interno di una transazione, un evento fa riferimento a una modifica dello stato che influisce su un'entità. Un comando incapsula tutte le informazioni necessarie per eseguire un'azione o attivare un evento successivo.
Le transazioni devono rispettare i principi di atomicità, coerenza, isolamento e durabilità (ACID).
- Atomicità: Tutte le operazioni hanno esito positivo o nessuna operazione riuscita.
- Coerenza: transizioni di dati da uno stato valido a un altro stato valido.
- isolamento : transazioni simultanee producono gli stessi risultati delle transazioni sequenziali.
- Durabilità: le modifiche vengono mantenute dopo il commit, anche quando si verificano errori.
In un singolo servizio le transazioni seguono i principi ACID perché operano all'interno di un singolo database. Tuttavia, può essere più complesso ottenere la conformità ACID tra più servizi.
Sfide nelle architetture di microservizi
Le architetture di microservizi assegnano in genere un database dedicato a ogni microservizio. Questo approccio offre diversi vantaggi:
- Ogni servizio incapsula i propri dati.
- Ogni servizio può usare la tecnologia e lo schema di database più adatti per le esigenze specifiche.
- I database per ogni servizio possono essere ridimensionati in modo indipendente.
- Gli errori in un servizio sono isolati da altri servizi.
Nonostante questi vantaggi, questa architettura complica la coerenza dei dati tra servizi. Le garanzie di database tradizionali, ad esempio ACID, non sono direttamente applicabili a più archivi dati gestiti in modo indipendente. A causa di queste limitazioni, le architetture che si basano sulla comunicazione interprocesso o su modelli di transazioni tradizionali come il protocollo di commit a due fasi, sono spesso più adatte per il modello Saga.
Soluzione
Il modello Saga gestisce le transazioni suddividendole in una sequenza di transazioni locali .
Ogni transazione locale:
- Completa il lavoro in modo atomico all'interno di un singolo servizio.
- Aggiorna il database del servizio.
- Avvia la transazione successiva tramite un evento o un messaggio.
Se una transazione locale ha esito negativo, la saga esegue una serie di transazioni di compensazione per invertire le modifiche apportate alle transazioni locali precedenti.
Concetti chiave nel modello Saga
transazioni compensabili possono essere annullate o compensate da altre transazioni con l'effetto opposto. Se un passaggio della saga ha esito negativo, le transazioni di compensazione annullano le modifiche apportate alle transazioni compensabili.
transazioni pivot fungono da punto di non ritorno nella saga. Dopo l'esito positivo di una transazione pivot, le transazioni compensabili non sono più rilevanti. Tutte le azioni successive devono essere completate affinché il sistema ottenga uno stato finale coerente. Una transazione pivot può assumere ruoli diversi, a seconda del flusso della saga:
transazioni irreversibili o non conformi non possono essere annullate o ritentate.
Il limite tra il reversibile e quello di cui è stato eseguito il commit significa che l'ultima transazione pivot può essere l'ultima transazione annullabile o compensabile. Oppure può essere la prima operazione riprovabile nella saga.
transazioni ritentabili seguire la transazione pivot. Le transazioni riprovabili sono idempotenti e contribuiscono a garantire che la saga possa raggiungere lo stato finale, anche se si verificano errori temporanei. Aiutano la saga a raggiungere alla fine uno stato coerente.
Approcci all'implementazione di Saga
I due approcci tipici di implementazione della saga sono coreografia e orchestrazione. Ogni approccio ha un proprio set di sfide e tecnologie per coordinare il flusso di lavoro.
Coreografia
Nell'approccio coreografico, i servizi scambiano eventi senza un controller centralizzato. Con la coreografia, ogni transazione locale pubblica eventi di dominio che attivano transazioni locali in altri servizi.
| Vantaggi della coreografia | Svantaggi della coreografia |
|---|---|
| Valido per i flussi di lavoro semplici che hanno pochi servizi e che non necessitano di una logica di coordinamento. | Il flusso di lavoro può generare confusione quando si aggiungono nuovi passaggi. È difficile tenere traccia dei comandi a cui ogni partecipante della saga risponde. |
| Nessun altro servizio è necessario per il coordinamento. | C'è il rischio di dipendenza ciclico tra i partecipanti alla saga perché devono usare i comandi dell'altro. |
| Non introduce un singolo punto di guasto perché le responsabilità vengono distribuite tra i partecipanti alla saga. | Il test di integrazione è difficile perché tutti i servizi devono essere eseguiti per simulare una transazione. |
Orchestrazione
Nell'orchestrazione, un controller centralizzato o agente di orchestrazione, gestisce tutte le transazioni e indica ai partecipanti l'operazione da eseguire in base agli eventi. L'agente di orchestrazione esegue richieste saga, archivia e interpreta gli stati di ogni attività e gestisce il ripristino degli errori usando transazioni di compensazione.
| Vantaggi dell'orchestrazione | Svantaggi dell'orchestrazione |
|---|---|
| Più adatto per flussi di lavoro complessi o quando si aggiungono nuovi servizi. | Altre complessità di progettazione richiedono un'implementazione di una logica di coordinamento. |
| Evita le dipendenze cicliche perché l'agente di orchestrazione gestisce il flusso. | Introduce un punto di errore perché l'agente di orchestrazione gestisce il flusso di lavoro completo. |
| La separazione chiara delle responsabilità semplifica la logica del servizio. |
Problemi e considerazioni
Quando si decide come implementare questo modello, tenere presente quanto segue:
Cambiamento nel pensiero progettuale: Adottare il modello Saga richiede una mentalità diversa. È necessario concentrarsi sul coordinamento delle transazioni e sulla coerenza dei dati tra più microservizi.
complessità delle saghe di debug: saga di debug può essere complessa, in particolare man mano che aumenta il numero di servizi partecipanti.
Modifiche irreversibili del database locale: non è possibile eseguire il rollback dei dati perché i partecipanti della saga eseguono il commit delle modifiche ai rispettivi database.
Gestione degli errori temporanei e dell'idempotenza: Il sistema deve gestire in modo efficace gli errori temporanei e garantire l'idempotenza, quando si ripete la stessa operazione non modifica il risultato. Per altre informazioni, vedere 'elaborazione di messaggi Idempotenti.
La necessità di monitorare e tenere traccia delle saghe: Monitoraggio e monitoraggio del flusso di lavoro di una saga sono attività essenziali per mantenere la supervisione operativa.
Limitazioni delle transazioni di compensazione: transazioni di compensazione potrebbero non sempre avere esito positivo, che può lasciare il sistema in uno stato incoerente.
Potenziali anomalie dei dati nelle saghe
Le anomalie dei dati sono incoerenze che possono verificarsi quando le saghe operano in più servizi. Poiché ogni servizio gestisce i propri dati, chiamati dati dei partecipanti, non esiste alcun isolamento predefinito tra i servizi. Questa configurazione può causare incoerenze o problemi di durabilità dei dati, ad esempio aggiornamenti parzialmente applicati o conflitti tra i servizi. I problemi tipici includono:
Aggiornamenti persi: Quando una saga modifica i dati senza considerare le modifiche apportate da un'altra saga, comporta aggiornamenti sovrascritti o mancanti.
letture Dirty: Quando una saga o una transazione legge i dati modificati da un'altra saga, ma la modifica non è completa.
Fuzzy, o nonrepeatable, legge: Quando passaggi diversi di una saga leggono dati incoerenti perché si verificano aggiornamenti tra le letture.
Strategie per risolvere le anomalie dei dati
Per ridurre o prevenire queste anomalie, considerare le contromisure seguenti:
blocco semantico: Usare blocchi a livello di applicazione quando la transazione compensabile di una saga usa un semaforo per indicare che è in corso un aggiornamento.
Aggiornamenti commutativi: Aggiornamenti della progettazione in modo che possano essere applicati in qualsiasi ordine pur producendo lo stesso risultato. Questo approccio consente di ridurre i conflitti tra saghe.
visualizzazione pessimistica: riordinare la sequenza della saga in modo che gli aggiornamenti dei dati si verifichino in transazioni riprovabili per eliminare le letture dirty. In caso contrario, una saga potrebbe leggere dati sporchi o modifiche di cui non è stato eseguito il commit, mentre un'altra saga esegue contemporaneamente una transazione compensabile per eseguire il rollback degli aggiornamenti.
Valori di rilettura: Verificare che i dati rimangano invariati prima di apportare aggiornamenti. Se i dati cambiano, arrestare il passaggio corrente e riavviare la saga in base alle esigenze.
File di versione: Mantenere un log di tutte le operazioni eseguite su un record e assicurarsi che vengano eseguite nella sequenza corretta per evitare conflitti.
concorrenza basata sul rischio in base al valore: scegliere dinamicamente il meccanismo di concorrenza appropriato in base al potenziale rischio aziendale. Ad esempio, usare sagas per gli aggiornamenti a basso rischio e le transazioni distribuite per gli aggiornamenti ad alto rischio.
Quando usare questo modello
Usare questo modello quando:
- È necessario garantire la coerenza dei dati in un sistema distribuito senza accoppiamento stretto.
- È necessario eseguire il rollback o compensare se una delle operazioni nella sequenza ha esito negativo.
Questo modello potrebbe non essere adatto quando:
- Le transazioni sono strettamente associate.
- Le transazioni di compensazione si verificano nei partecipanti precedenti.
- Esistono dipendenze cicliche.
Passaggio successivo
Risorse correlate
I modelli seguenti potrebbero essere rilevanti quando si implementa questo modello:
Il modello Coreografia ha ogni componente del sistema che partecipa al processo decisionale sul flusso di lavoro di una transazione aziendale, anziché basarsi su un punto di controllo centrale.
Il modello transazione di compensazione annulla il lavoro eseguito da una serie di passaggi e infine definisce un'operazione coerente se uno o più passaggi hanno esito negativo. Le applicazioni ospitate nel cloud che implementano processi aziendali e flussi di lavoro complessi spesso seguono questo modello di coerenza finale.
Il modello di ripetizione dei tentativi consente a un'applicazione di gestire gli errori temporanei quando tenta di connettersi a un servizio o a una risorsa di rete ritentando in modo trasparente l'operazione non riuscita. Questo modello può migliorare la stabilità dell'applicazione.
Il modello di interruttore gestisce gli errori che richiedono una quantità variabile di tempo per il ripristino, quando ci si connette a un servizio remoto o a una risorsa. Questo modello può migliorare la stabilità e la resilienza di un'applicazione.
Il modello di monitoraggio degli endpoint di integrità implementa controlli funzionali in un'applicazione a cui gli strumenti esterni possono accedere tramite endpoint esposti a intervalli regolari. Questo modello consente di verificare che le applicazioni e i servizi funzionino correttamente.