Modello coreografico saga - AWS Guida prescrittiva
IntentoMotivazioneApplicabilitàProblemi e considerazioniImplementazioneContenuti correlati

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Modello coreografico saga

Intento

Il modello coreografico saga aiuta a preservare l'integrità dei dati nelle transazioni distribuite che si estendono su più servizi utilizzando abbonamenti a eventi. In una transazione distribuita, è possibile chiamare più servizi prima del completamento di una transazione. Quando i servizi archiviano i dati in datastore diversi, può essere difficile mantenere la coerenza dei dati tra questi.

Motivazione

Una transazione è una singola unità di lavoro che può comportare più passaggi, in cui tutti i passaggi vengono eseguiti completamente o non viene eseguito alcun passaggio, con il risultato di un datastore che mantiene lo stato coerente. I termini atomicità, consistenza, isolamento e durabilità (ACID) definiscono le proprietà di una transazione. I database relazionali forniscono transazioni ACID per mantenere la coerenza dei dati.

Per mantenere la coerenza in una transazione, i database relazionali utilizzano il metodo di commit a due fasi (2PC). Tale metodo consiste in una fase di preparazione e una fase di commit.

  • Nella fase di preparazione, il processo di coordinamento richiede che i processi partecipanti alla transazione (partecipanti) si impegnino a confermare o annullare la transazione.

  • Nella fase di commit, il processo di coordinamento richiede ai partecipanti di confermare la transazione. Se i partecipanti non riescono ad accettare di impegnarsi nella fase di preparazione, la transazione viene annullata.

Nei sistemi distribuiti che seguono uno schema di database-per-service progettazione, il commit in due fasi non è un'opzione. Questo perché ogni transazione è distribuita su diversi database e non esiste un unico controller in grado di coordinare un processo simile al commit in due fasi nei datastore relazionali. In questo caso, una soluzione consiste nell'utilizzare il modello coreografico saga.

Applicabilità

Usa il modello coreografico saga quando:

  • Il sistema richiede l'integrità e la coerenza dei dati nelle transazioni distribuite che si estendono su più datastore.

  • Il datastore (ad esempio, un database NoSQL) non fornisce 2PC per fornire transazioni ACID, è necessario aggiornare più tabelle all'interno di una singola transazione e implementare 2PC entro i confini dell'applicazione sarebbe un'attività complessa.

  • Un processo di controllo centrale che gestisce le transazioni dei partecipanti potrebbe diventare un singolo punto di errore.

  • I partecipanti alla saga sono servizi indipendenti e devono essere accoppiati in maniera debole.

  • Esiste una comunicazione tra contesti limitati in un dominio aziendale.

Problemi e considerazioni

  • Complessità: con l'aumentare del numero di microservizi, la coreografia saga può diventare difficile da gestire a causa del numero di interazioni tra i microservizi. Inoltre, le transazioni di compensazione e i nuovi tentativi aggiungono complessità al codice dell'applicazione, il che può aumentare la necessità di manutenzione. 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.

  • Implementazione resiliente: nella coreografia saga, è più difficile implementare timeout, nuovi tentativi e altri modelli di resilienza a livello globale, rispetto all'orchestrazione saga. La coreografia deve essere implementata su singoli componenti anziché a livello di orchestratore.

  • Dipendenze cicliche: i partecipanti utilizzano messaggi pubblicati l'uno dall'altro. Ciò potrebbe comportare dipendenze cicliche, con conseguente complessità del codice e sovraccarichi di manutenzione e possibili situazioni di stallo.

  • Problema di doppia scrittura: il microservizio deve aggiornare atomicamente il database e pubblicare un evento. L'errore di una delle due operazioni potrebbe portare a uno stato incoerente. Un modo per risolvere questo problema consiste nell'utilizzare il modello di posta in uscita transazionale.

  • Conservazione degli eventi: i partecipanti alla saga agiscono in base agli eventi pubblicati. È importante salvare gli eventi nell'ordine in cui si verificano per scopi di controllo, debug e riproduzione. Per mantenere gli eventi in un datastore nel caso in cui sia necessaria una riproduzione dello stato del sistema per ripristinare la coerenza dei dati, è possibile utilizzare il modello di approvvigionamento degli eventi. Gli archivi eventi possono essere utilizzati anche per scopi di controllo e risoluzione dei problemi perché riflettono ogni modifica del sistema.

  • Coerenza finale: l'elaborazione sequenziale delle transazioni locali si traduce in una coerenza finale, il che può rappresentare una sfida nei sistemi che richiedono una forte coerenza. È possibile risolvere questo problema impostando le aspettative dei team aziendali in merito al modello di consistenza o rivalutare il caso d'uso e passare a un datastore che garantisca una forte coerenza.

  • Idempotenza: i partecipanti a saga devono essere idempotenti per consentire l'esecuzione ripetuta in caso di guasti transitori causati da arresti imprevisti e guasti dell'orchestratore.

  • Isolamento delle transazioni: il modello saga non include l'isolamento delle transazioni, che è una delle quattro proprietà delle transazioni ACID. Il grado di isolamento di una transazione determina quanto o quanto poco altre transazioni simultanee possono influire sui dati su cui operano. L'orchestrazione simultanea delle transazioni può portare a dati obsoleti. Consigliamo di utilizzare il blocco semantico per gestire tali scenari.

  • Osservabilità: l'osservabilità si riferisce alla registrazione e al tracciamento dettagliati per risolvere i problemi durante il processo di implementazione e orchestrazione. Ciò diventa importante quando il numero di partecipanti alla saga aumenta, con conseguenti complessità nel debug. nd-to-end Il monitoraggio e la reportistica elettronica sono più difficili da realizzare nella coreografia delle saga, rispetto all'orchestrazione delle saga.

  • Problemi di latenza: le transazioni compensative possono aggiungere latenza al tempo di risposta complessivo quando la saga è composta da più passaggi. Se le transazioni effettuano chiamate sincrone, ciò può aumentare ulteriormente la latenza.

Implementazione

Architettura di alto livello

Nel seguente diagramma di architettura, l'orchestratore saga ha tre partecipanti: il servizio ordini, il servizio di inventario e il servizio di pagamento. Per completare la transazione sono necessari tre passaggi: T1, T2 e T3. Tre transazioni compensative consentono di ripristinare i dati allo stato iniziale: C1, C2 e C3.

Architettura coreografica saga di alto livello

  • Il servizio ordini esegue una transazione locale, T1, che aggiorna atomicamente il database e pubblica un messaggio Order placed sul broker di messaggi.

  • Il servizio di inventario sottoscrive i messaggi del servizio ordini e riceve il messaggio che indica che è stato creato un ordine.

  • Il servizio di inventario esegue una transazione locale, T2, che aggiorna atomicamente il database e pubblica un messaggio Inventory updated sul broker di messaggi.

  • Il servizio di pagamento sottoscrive i messaggi del servizio di inventario e riceve il messaggio che l'inventario è stato aggiornato.

  • Il servizio di pagamento esegue una transazione locale, T3, che aggiorna atomicamente il database con i dettagli del pagamento e pubblica un messaggio Payment processed sul broker di messaggi.

  • Se il pagamento non riesce, il servizio di pagamento esegue una transazione compensativa, C1, che annulla atomicamente il pagamento nel database e pubblica un messaggio Payment failed sul broker di messaggi.

  • Le transazioni compensative C2 e C3 vengono eseguite per ripristinare la coerenza dei dati.

Implementazione tramite servizi AWS

Puoi implementare il pattern coreografico della saga utilizzando Amazon. EventBridge EventBridgeutilizza gli eventi per connettere i componenti dell'applicazione. Elabora gli eventi tramite bus o pipe di eventi. Un router di eventi è un router che riceve eventi e li invia a nessuna o a più destinazioni o target. Le regole associate al router di eventi valutano gli eventi man mano che arrivano e li inviano alle destinazioni per l'elaborazione.

Nella seguente architettura:

  • I microservizi (servizio ordini, servizio di inventario e servizio di pagamento) sono implementati come funzioni Lambda.

  • Esistono tre EventBridge bus personalizzati: Orders event bus, Inventory event bus e Payment event bus.

  • Le regole Orders, le regole Inventory e le regole Payment corrispondono agli eventi che vengono inviati al router di eventi corrispondente e richiamano le funzioni Lambda.

Architettura della coreografia saga che utilizza i servizi AWS

In uno scenario di successo, quando viene effettuato un ordine:

  1. Il servizio ordini elabora la richiesta e invia l'evento al router di eventi Orders.

  2. Le regole Orders corrispondono agli eventi e avviano il servizio di inventario.

  3. Il servizio di inventario aggiorna l'inventario e invia l'evento al router di eventi Inventory.

  4. Le regole Inventory corrispondono agli eventi e avviano il servizio di pagamento.

  5. Il servizio di pagamento elabora il pagamento e invia l'evento al router di eventi Payment.

  6. Le regole Payment corrispondono agli eventi e inviano la notifica dell'evento Payment processed all'ascoltatore.

    In alternativa, quando si verifica un problema nell'elaborazione degli ordini, le EventBridge regole avviano le transazioni compensative per ripristinare gli aggiornamenti dei dati per mantenere la coerenza e l'integrità dei dati.

  7. Se il pagamento non riesce, le regole Payment elaborano l'evento e avviano il servizio di inventario.Il servizio di inventario esegue quindi le transazioni compensative per ripristinare l'inventario.

  8. Una volta ripristinato l'inventario, il servizio di inventario invia l'evento Inventory reverted al router di eventi Inventory.Questo evento viene elaborato dalle regole Inventory.Avvia il servizio ordini, che esegue la transazione compensativa per rimuovere l'ordine.

Contenuti correlati