Modelli saga

Una saga consiste in una sequenza di transazioni locali. Ogni transazione locale di una saga aggiorna il database e attiva la transazione locale successiva. Se una transazione non riesce, la saga esegue transazioni di compensazione per ripristinare le modifiche al database apportate dalle transazioni precedenti.

Questa sequenza di transazioni locali aiuta a realizzare un flusso di lavoro aziendale utilizzando i principi di continuazione e compensazione. Il principio di continuazione decide il ripristino successivo del flusso di lavoro, mentre il principio di compensazione decide il ripristino a ritroso. Se l'aggiornamento fallisce in qualsiasi fase della transazione, la saga pubblica un evento di continuazione (per riprovare la transazione) o di compensazione (per tornare allo stato precedente dei dati). Ciò garantisce il mantenimento dell'integrità dei dati e la coerenza in tutti i datastore.

Ad esempio, quando un utente acquista un libro da un rivenditore online, il processo consiste in una sequenza di transazioni, come la creazione dell'ordine, l'aggiornamento dell'inventario, il pagamento e la spedizione, che rappresenta un flusso di lavoro aziendale. Per completare questo flusso di lavoro, l'architettura distribuita emette una sequenza di transazioni locali per creare un ordine nel database degli ordini, aggiornare il database dell'inventario e aggiornare il database dei pagamenti. Quando il processo ha esito positivo, queste transazioni vengono richiamate in sequenza per completare il flusso di lavoro aziendale, come illustrato nel diagramma seguente. Tuttavia, se una di queste transazioni locali non riesce, il sistema deve essere in grado di decidere la fase successiva appropriata, ovvero un ripristino in avanti o un ripristino all'indietro.

I due scenari seguenti aiutano a determinare se il passaggio successivo è un ripristino in avanti o all'indietro:

• Errore a livello di piattaforma, in cui qualcosa va storto con l'infrastruttura sottostante e causa la non riuscita della transazione. In questo caso, il modello saga può eseguire un ripristino successivo ritentando la transazione locale e continuando il processo aziendale.

• Errore a livello di applicazione, in cui il servizio di pagamento non funziona a causa di un pagamento non valido. In questo caso, il modello saga può eseguire un ripristino a ritroso emettendo una transazione compensativa per aggiornare l'inventario e i database degli ordini e ripristinare lo stato precedente.

Il modello saga gestisce il flusso di lavoro aziendale e garantisce il raggiungimento dello stato finale desiderato attraverso il ripristino successivo. In caso di errori, ripristina le transazioni locali utilizzando il ripristino a ritroso per evitare problemi di coerenza dei dati.

Il modello saga ha due varianti: coreografia e orchestrazione.

Coreografia saga

Il modello coreografico della saga dipende dagli eventi pubblicati dai microservizi. I partecipanti alla saga (microservizi) sottoscrivono gli eventi e agiscono in base ai fattori scatenanti dell'evento. Ad esempio, il servizio ordini nel diagramma seguente emette un evento OrderPlaced. Il servizio di inventario sottoscrive quell'evento e aggiorna l'inventario quando viene emesso l'evento OrderPlaced. Allo stesso modo, i servizi per i partecipanti agiscono in base al contesto dell'evento emesso.

La coreografia è adatta quando ci sono solo pochi partecipanti alla saga ed è necessaria un'implementazione semplice senza alcun punto di errore. Quando vengono aggiunti più partecipanti, diventa più difficile tenere traccia delle dipendenze tra i vari partecipanti utilizzando questo schema.

Per una revisione dettagliata, consulta la sezione Coreografia Saga in questa guida.

Orchestrazione saga

Il modello di orchestrazione saga ha un coordinatore centrale chiamato orchestratore. L'orchestratore saga gestisce e coordina l'intero ciclo di vita delle transazioni. È a conoscenza della serie di passaggi da eseguire per completare la transazione. Per eseguire un passaggio, invia un messaggio al microservizio partecipante affinché esegua l'operazione. Il microservizio partecipante completa l'operazione e invia a sua volta un messaggio all'orchestratore. In base al messaggio ricevuto, l'orchestratore decide quale microservizio eseguire successivamente nella transazione.

Il modello di orchestrazione saga è adatto quando ci sono molti partecipanti ed è richiesto un accoppiamento libero tra i partecipanti alla saga. L'orchestratore incapsula la complessità della logica rendendo i partecipanti accoppiati in modo debole. Tuttavia, l'orchestratore può diventare un singolo punto di errore perché controlla l'intero flusso di lavoro.

Per una revisione dettagliata, consulta la sezione Orchestrazione Saga in questa guida.