Modello di transazioni distribuite saga

Il modello di progettazione saga è un modo per gestire la coerenza dei dati tra microservizi in scenari di transazione distribuiti. Una saga è una sequenza di transazioni che aggiorna ogni servizio e pubblica un messaggio o un evento per attivare il passaggio successivo della transazione. Se un passaggio ha esito negativo, la saga esegue transazioni di compensazione che contrastano le transazioni precedenti.

Contesto e problema

Una transazione è una singola unità di logica o lavoro, talvolta costituita da più operazioni. All'interno di una transazione, un evento è una modifica dello stato che si verifica in un'entità e un comando incapsula tutte le informazioni necessarie per eseguire un'azione o attivare un evento successivo.

Le transazioni devono essere atomiche, coerenti, isolate e durevoli (ACID). Le transazioni all'interno di un singolo servizio sono ACID, ma la coerenza dei dati tra servizi richiede una strategia di gestione delle transazioni tra servizi.

Nelle architetture multiservizi:

• L'atomicità è un set indivisibile e irreducibile di operazioni che devono verificarsi tutte o nessuna.
• La coerenza significa che la transazione porta i dati solo da uno stato valido a un altro stato valido.
• L'isolamento garantisce che le transazioni simultanee producano lo stesso stato di dati che le transazioni eseguite in sequenza avrebbero prodotto.
• La durabilità garantisce che le transazioni di commit rimangano commit anche in caso di errore di sistema o interruzione dell'alimentazione.

Un modello di microservizio per database offre molti vantaggi per le architetture di microservizi. L'incapsulamento dei dati di dominio consente a ogni servizio di usare il tipo di archivio dati e lo schema migliori, ridimensionarne il proprio archivio dati in base alle esigenze e essere isolato dagli errori di altri servizi. Tuttavia, garantire la coerenza dei dati tra database specifici del servizio comporta problemi.

Le transazioni distribuite, ad esempio il protocollo di commit in due fasi (2PC) richiedono a tutti i partecipanti di una transazione di eseguire il commit o il rollback prima che la transazione possa procedere. Tuttavia, alcune implementazioni dei partecipanti, ad esempio database NoSQL e brokering dei messaggi, non supportano questo modello.

Un'altra limitazione delle transazioni distribuite è la sincronizzazione e la disponibilità di IPC (Interprocess Communication). Il sistema operativo fornito da IPC consente ai processi separati di condividere i dati. Per eseguire il commit delle transazioni distribuite, tutti i servizi partecipanti devono essere disponibili, riducendo potenzialmente la disponibilità complessiva del sistema. Le implementazioni dell'architettura con limitazioni di IPC o transazioni sono candidati per il modello Saga.

Soluzione

Il modello Saga fornisce la gestione delle transazioni usando una sequenza di transazioni locali. Una transazione locale è il lavoro atomico eseguito da un partecipante della saga. Ogni transazione locale aggiorna il database e pubblica un messaggio o un evento per attivare la transazione locale successiva nella saga. Se una transazione locale ha esito negativo, la saga esegue una serie di transazioni di compensazione che annullano le modifiche apportate dalle transazioni locali precedenti.

Nei modelli saga:

• Le transazioni compensabili sono transazioni che possono potenzialmente essere invertite elaborando un'altra transazione con l'effetto opposto.
• Una transazione pivot è il punto go/no-go in una saga. Se il commit della transazione pivot viene eseguito fino al completamento della saga. Una transazione pivot può essere una transazione che non è compensabile né riprovabile oppure può essere l'ultima transazione compensabile o la prima transazione riprovabile nella saga.
• Le transazioni riprovabili sono transazioni che seguono la transazione pivot e hanno la garanzia di esito positivo.

Esistono due approcci comuni di implementazione della saga, coreografie e orchestrazione. Ogni approccio ha un proprio set di sfide e tecnologie per coordinare il flusso di lavoro.

Coreografia

La coreografia è un modo per coordinare le saga in cui i partecipanti scambiano eventi senza un punto di controllo centralizzato. Con la coreografia, ogni transazione locale pubblica eventi di dominio che attivano transazioni locali in altri servizi.

Vantaggi

• Buono per i flussi di lavoro semplici che richiedono pochi partecipanti e non ha bisogno di una logica di coordinamento.
• Non richiede un'implementazione e una manutenzione aggiuntive del servizio.
• Non introduce un singolo punto di errore, poiché le responsabilità vengono distribuite tra i partecipanti alla saga.

Svantaggi

• Il flusso di lavoro può diventare confuso quando si aggiungono nuovi passaggi, poiché è difficile tenere traccia dei partecipanti della saga a cui i partecipanti ascoltano i comandi.
• C'è un rischio di dipendenza ciclico tra i partecipanti alla saga perché devono usare i comandi dell'altro.
• Il test di integrazione è difficile perché tutti i servizi devono essere in esecuzione per simulare una transazione.

Orchestrazione

L'orchestrazione è un modo per coordinare le saga in cui un controller centralizzato indica ai partecipanti alla saga quali transazioni locali eseguire. L'orchestratore della saga gestisce tutte le transazioni e indica ai partecipanti l'operazione da eseguire in base agli eventi. L'agente di orchestrazione esegue richieste di saga, archivia e interpreta gli stati di ogni attività e gestisce il ripristino degli errori con transazioni di compensazione.

Vantaggi

• Buono per i flussi di lavoro complessi che coinvolgono molti partecipanti o nuovi partecipanti aggiunti nel tempo.
• Adatto quando c'è il controllo su ogni partecipante nel processo e controllare il flusso di attività.
• Non introduce dipendenze cicliche, perché l'agente di orchestrazione dipende in modo unilaterale dai partecipanti alla saga.
• I partecipanti alla saga non devono conoscere i comandi per altri partecipanti. La separazione chiara dei problemi semplifica la logica di business.

Svantaggi

• La complessità di progettazione aggiuntiva richiede un'implementazione di una logica di coordinamento.
• C'è un altro punto di errore, perché l'agente di orchestrazione gestisce il flusso di lavoro completo.

Considerazioni e problemi

Prendere in considerazione i punti seguenti quando si implementa il modello Saga:

• Il modello Saga può essere inizialmente impegnativo, perché richiede un nuovo modo di pensare su come coordinare una transazione e mantenere la coerenza dei dati per un processo aziendale che si estende su più microservizi.
• Il modello Saga è particolarmente difficile da eseguire nel debug e la complessità aumenta man mano che i partecipanti aumentano.
• Non è possibile eseguire il rollback dei dati perché i partecipanti della saga esegue il commit delle modifiche ai database locali.
• L'implementazione deve essere in grado di gestire un set di potenziali errori temporanei e fornire idempotenza per ridurre gli effetti collaterali e garantire la coerenza dei dati. L'Idempotenza significa che la stessa operazione può essere ripetuta più volte senza modificare il risultato iniziale. Per altre informazioni, vedere le linee guida per garantire l'idempotenza durante l'elaborazione dei messaggi e l'aggiornamento dello stato insieme.
• È consigliabile implementare l'osservabilità per monitorare e tenere traccia del flusso di lavoro della saga.
• La mancanza di isolamento dei dati partecipanti impone sfide di durabilità. L'implementazione della saga deve includere contromisure per ridurre le anomalie.

Le anomalie seguenti possono verificarsi senza misure appropriate:

• Aggiornamenti perduti, quando una saga scrive senza leggere le modifiche apportate da un'altra saga.
• Letture sporche, quando una transazione o una saga legge gli aggiornamenti effettuati da una saga che non ha ancora completato tali aggiornamenti.
• Letture fuzzy/nonrepeatable, quando diversi passaggi della saga leggeno dati diversi perché si verifica un aggiornamento dei dati tra le letture.

Le contromisure suggerite per ridurre o prevenire anomalie includono:

• Blocco semantico, un blocco a livello di applicazione in cui la transazione compensabile di una saga usa un semaforo per indicare che un aggiornamento è in corso.
• Aggiornamenti commutatori che possono essere eseguiti in qualsiasi ordine e produrre lo stesso risultato.
• Vista pessimistica: È possibile che una saga legge i dati sporchi, mentre un'altra saga esegue una transazione compensabile per eseguire il rollback dell'operazione. La visualizzazione pessimistica riordina la saga in modo che gli aggiornamenti dei dati sottostanti in una transazione riprovabile, che elimina la possibilità di una lettura sporca.
• Il valore di riread verifica che i dati siano invariati e quindi aggiornano il record. Se il record è cambiato, i passaggi interrompeno e la saga può riavviare.
• Un file di versione registra le operazioni su un record durante l'arrivo e quindi le esegue nell'ordine corretto.
• Per valore viene usato il rischio aziendale di ogni richiesta per selezionare dinamicamente il meccanismo di concorrenza. Le richieste a basso rischio favoriscono le saga, mentre le richieste ad alto rischio favoriscono le transazioni distribuite.

Quando usare questo modello

Usare il modello Saga quando è necessario:

• Assicurarsi la coerenza dei dati in un sistema distribuito senza accoppiamento stretto.
• Eseguire il rollback o compensare se una delle operazioni nella sequenza ha esito negativo.

Il modello Saga è meno adatto per:

• Transazioni strettamente associate.
• Compensazione delle transazioni che si verificano nei partecipanti precedenti.
• Dipendenze cicliche.

Esempio

La saga basata su orchestrazione su Serverless è un riferimento all'implementazione della saga usando l'approccio di orchestrazione che simula uno scenario di trasferimento denaro con flussi di lavoro riusciti e non riusciti.

Passaggi successivi

• Dati distribuiti
• Richardson, Chris. 2018: Modelli di microservizi. Pubblicazioni di Manning.

Risorse correlate

Quando si implementa questo modello, possono essere utili anche i modelli seguenti:

• La coreografia ha ogni componente del sistema partecipa al processo decisionale sul flusso di lavoro di una transazione aziendale, anziché basarsi su un punto centrale di controllo.
• Compensazione delle transazioni non eseguite da una serie di passaggi e infine definire un'operazione coerente se uno o più passaggi hanno esito negativo. Le applicazioni ospitate nel cloud che implementano processi aziendali complessi e flussi di lavoro spesso seguono questo modello di coerenza finale.
• Riprovare consente a un'applicazione di gestire gli errori temporanei quando tenta di connettersi a un servizio o a una risorsa di rete, riprovando in modo trasparente l'operazione non riuscita. I tentativi possono migliorare la stabilità dell'applicazione.
• L'interruttore gestisce gli errori che richiedono un intervallo di tempo variabile da cui eseguire il ripristino, quando ci si connette a un servizio o una risorsa remota. L'interruttore può migliorare la stabilità e la resilienza di un'applicazione.
• Il monitoraggio degli endpoint di integrità implementa i controlli funzionali in un'applicazione a cui gli strumenti esterni possono accedere tramite endpoint esposti a intervalli regolari. Il monitoraggio degli endpoint di integrità consente di verificare che le applicazioni e i servizi vengano eseguite correttamente.