Transazioni distribuite Saga

Azure

Il modello di progettazione di questa serie è un modo per gestire la coerenza dei dati tra microservizi in scenari di transazioni distribuite. 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 di lavoro, talvolta costituito 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 irriducibile di operazioni che devono essere eseguite tutte o nessuna.
  • 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 produca lo stesso stato dei dati generato dalle transazioni eseguite in sequenza.
  • La durabilità garantisce che il commit delle transazioni di cui è stato eseguito il commit rimanga anche in caso di guasto del sistema o interruzione dell'alimentazione.

Un modello di database per microservizio 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, ridimensionare 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 pone problemi.

Le transazioni distribuite come il protocollo 2PC (Two-Phase Commit) richiedono a tutti i partecipanti di una transazione di eseguire il commit o il rollback prima che la transazione possa continuare. Tuttavia, alcune implementazioni dei partecipanti, ad esempio database NoSQL e message brokering, non supportano questo modello.

Un'altra limitazione delle transazioni distribuite è la sincronizzazione e la disponibilità delle comunicazioni interprocesso (IPC). IPC fornito dal sistema operativo consente a processi separati di condividere i dati. Per 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 di transazione sono candidate per il modello di saga.

Soluzione

Il modello di 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 successiva transazione locale nella serie. 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.

Panoramica di Saga.

In modelli di saga:

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

Esistono due approcci comuni per l'implementazione di una serie di saghe, l'orchestrazione e l'orchestrazione. Ogni approccio ha un proprio set di sfide e tecnologie per coordinare il flusso di lavoro.

Coreografia

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

Cenni preliminari sulla creazione di un'attività di creazione

Vantaggi

  • Buona per i flussi di lavoro semplici che richiedono pochi partecipanti e non richiedono una logica di coordinamento.
  • Non richiede l'implementazione e la manutenzione aggiuntive del servizio.
  • Non introduce un singolo punto di errore, poiché le responsabilità vengono distribuite tra i partecipanti della serie.

Svantaggi

  • Il flusso di lavoro può generare confusione quando si aggiungono nuovi passaggi, in quanto è difficile tenere traccia dei partecipanti della saga in ascolto dei comandi.
  • Esiste il rischio di dipendenza ciclica tra i partecipanti di una serie di eventi perché devono usare i comandi reciproci.
  • 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 saghe in cui un controller centralizzato indica ai partecipanti della saga quali transazioni locali eseguire. L'agente di orchestrazione della saga gestisce tutte le transazioni e indica ai partecipanti quale operazione eseguire in base agli eventi. L'agente di orchestrazione esegue richieste di tipo saga, archivia e interpreta gli stati di ogni attività e gestisce il ripristino degli errori con transazioni di compensazione.

Panoramica dell'orchestrazione

Vantaggi

  • Ottimo per flussi di lavoro complessi che coinvolgono molti partecipanti o nuovi partecipanti aggiunti nel tempo.
  • Adatto quando è presente il controllo su ogni partecipante del processo e il controllo sul flusso delle attività.
  • Non introduce dipendenze cicliche, perché l'agente di orchestrazione dipende in modo unilaterale dai partecipanti della serie.
  • I partecipanti di Saga non devono conoscere i comandi per altri partecipanti. Una netta separazione dei problemi semplifica la logica di business.

Svantaggi

  • Un'ulteriore complessità di progettazione richiede un'implementazione di una logica di coordinamento.
  • Esiste un ulteriore punto di errore, perché l'agente di orchestrazione gestisce il flusso di lavoro completo.

Considerazioni e problemi

Quando si implementa il modello di saga, considerare i punti seguenti:

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

Le anomalie seguenti possono verificarsi senza misure appropriate:

  • Gli aggiornamenti persi vengono persi quando una saghetta scrive senza leggere le modifiche apportate da un'altra.
  • Dirty legge, quando una transazione o una saga legge gli aggiornamenti apportati da una saga che non ha ancora completato tali aggiornamenti.
  • Le operazioni fuzzy/non repeatable vengono lette quando passaggi diversi di una serie di operazioni leggono dati diversi perché si verifica un aggiornamento dei dati tra le operazioni di lettura.

Le contromisure suggerite per ridurre o impedire le anomalie includono:

  • Blocco semantico, un blocco a livello di applicazione in cui la transazione compensabile di una saga usa un semaforo per indicare che è in corso un aggiornamento.
  • Aggiornamenti commutativi che possono essere eseguiti in qualsiasi ordine e producono lo stesso risultato.
  • Visualizzazione pessimistica: È possibile che una serie di dati dirty sia letta, mentre un'altra è in esecuzione una transazione compensabile per eseguire il rollback dell'operazione. La visualizzazione pessimistica riordina la saga in modo che i dati sottostanti si accontino in una transazione ripetibile, eliminando così la possibilità di una lettura dirty.
  • Il valore riletto verifica che i dati non sono stati modificati e quindi aggiorna il record. Se il record è stato modificato, i passaggi vengono interrotti e la serie può essere riavviata.
  • Un file di versione registra le operazioni su un record non appena arrivano e quindi le esegue nell'ordine corretto.
  • Per valore usa il rischio aziendale di ogni richiesta per selezionare dinamicamente il meccanismo di concorrenza. Le richieste a basso rischio favoriscono le saghe, mentre le richieste ad alto rischio favoriscono le transazioni distribuite.

Quando usare questo modello

Usare il modello di saga quando è necessario:

  • Garantire 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 di saga è meno adatto per:

  • Transazioni strettamente abbinate.
  • Compensazione delle transazioni che si verificano nei partecipanti precedenti.
  • Dipendenze ciclici.

Esempio

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

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

  • Per ogni componente del sistema, Il processo decisionale riguarda il flusso di lavoro di una transazione aziendale, anziché basarsi su un punto di controllo centrale.
  • La compensazione delle transazioni annulla il lavoro eseguito da una serie di passaggi e infine definisce un'operazione coerente in caso di esito negativo di uno o più passaggi. Le applicazioni ospitate nel cloud che implementano flussi di lavoro e processi aziendali complessi spesso seguono questo modello di coerenza finale.
  • Riprova consente a un'applicazione di gestire gli errori temporanei quando tenta di connettersi a un servizio o a una risorsa di rete, ripetendo in modo trasparente l'operazione non riuscita. La ripetizione dei tentativi può migliorare la stabilità dell'applicazione.
  • L'interruttore gestisce gli errori che possono richiedere una quantità variabile di tempo per il ripristino durante la connessione a un servizio remoto o a una risorsa. L'interruttore può migliorare la stabilità e la resilienza di un'applicazione.
  • Il monitoraggio degli endpoint di integrità implementa 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 funzionino correttamente.
  • Dati distribuiti
  • Richson, Chris. 2018: Modelli di microservizi. Pubblicazioni di manning.