Modello coreografico

Il modello Coreografa decentralizza la logica del flusso di lavoro e distribuisce le responsabilità ad altri componenti all'interno di un sistema. Invece di dipendere da un agente di orchestrazione centrale, i servizi decidono quando e come elaborare un'operazione aziendale.

Contesto e problema

In genere si divide un'applicazione basata sul cloud in diversi servizi di piccole dimensioni che interagiscono per elaborare una transazione aziendale end-to-end. Una singola operazione all'interno di una transazione può comportare più chiamate da punto a punto tra tutti i servizi. Idealmente, questi servizi sono ad accoppiamento libero. È difficile progettare un flusso di lavoro distribuito, efficiente e scalabile perché comporta una comunicazione interservizi complessa.

Un modello comune per la comunicazione consiste nell'usare un servizio centralizzato o un agente di orchestrazione. Le richieste in ingresso fluiscono attraverso l'orchestratore che delega le operazioni ai rispettivi servizi. Ogni servizio completa la propria responsabilità e non è a conoscenza del flusso di lavoro complessivo.

In genere si implementa lo schema dell'agente di orchestrazione come software personalizzato con conoscenze di dominio sulle responsabilità dei servizi all'interno del sistema. Un vantaggio di questo approccio è che l'agente di orchestrazione può consolidare lo stato di una transazione in base ai risultati delle singole operazioni eseguite dai servizi downstream.

Questo approccio crea anche alcuni ostacoli. L'aggiunta o la rimozione di servizi potrebbe interrompere la logica esistente perché è necessario collegare parti del percorso di comunicazione. Questa dipendenza rende l'implementazione dell'agente di orchestrazione complessa e difficile da gestire. L'orchestratore potrebbe influire negativamente sulla stabilità del carico di lavoro. In fase di caricamento, può introdurre colli di bottiglia delle prestazioni e essere il singolo punto di errore (SPoF). Può anche causare errori a catena nei servizi downstream.

Soluzione

Delegare la logica di gestione delle transazioni tra i servizi. Consentire a ogni servizio di partecipare al flusso di lavoro di comunicazione per un'operazione aziendale e decidere quando e come elaborarlo.

Il modello Coreografia riduce al minimo la dipendenza dal software personalizzato che centralizza il flusso di comunicazione. I componenti implementano la logica comune mentre coreografano il flusso di lavoro tra loro senza comunicare direttamente tra loro.

Un modo comune per implementare la coreografia consiste nell'usare un broker di messaggi che memorizza nel buffer le richieste fino a quando i componenti downstream non le richiedano e le elaborino. L'immagine seguente mostra la gestione delle richieste tramite un modello publisher-subscriber.

1. Il client invia le richieste in coda come messaggi in un broker di messaggi.

2. I servizi o il sottoscrittore esegue il polling del broker per determinare se è in grado di elaborare tale messaggio secondo la logica aziendale implementata. Il broker può anche eseguire il push dei messaggi ai sottoscrittori interessati a tale messaggio.

3. Ogni servizio sottoscritto esegue l'operazione come indica il messaggio e risponde al broker con un messaggio di operazione riuscita o di errore.

4. Se l'operazione ha esito positivo, il servizio può eseguire il push di un messaggio nella stessa coda o in una coda di messaggi diversa in modo che un altro servizio possa continuare il flusso di lavoro, se necessario. Se l'operazione non riesce, il broker di messaggi collabora con altri servizi per compensare tale operazione o l'intera transazione.

Problemi e considerazioni

Quando si decide come implementare questo modello, tenere presente quanto segue:

• La gestione degli errori può risultare complessa. I componenti di un'applicazione possono gestire le attività atomica e dipendono da altre parti del sistema. L'errore in un componente può influire su altri componenti, causando ritardi nel completamento della richiesta complessiva.

  Per gestire correttamente gli errori, implementare la logica di gestione degli errori, che introduce complessità. Anche la logica di gestione degli errori, ad esempio le transazioni di compensazione, è soggetta a errori.

  

  Il diagramma di flusso mostra la gestione degli errori e la logica di compensazione in un modello coreografico con dipendenze del servizio sequenziale. Nella parte superiore, un nodo iniziale punta al servizio A. Il servizio A si connette a un diamante che punta al servizio B a sinistra e al servizio C a destra. Le frecce puntano da ciascuno di questi servizi a un diamante decisionale che verifica se la richiesta è fallita. Il percorso etichettato sì si dirama verso l'alto in un ciclo che torna al diamante che connette tutti e tre i servizi. Il percorso con etichetta no continua a una casella che indica che entrambi i servizi sono riusciti. Da questo stato di successo, il flusso continua verso il basso fino al servizio D, che si connette a un nodo decisionale finale che verifica se la richiesta fallisce. Il percorso del sì da questo rombo torna verso l'alto per rientrare nel flusso prima del servizio D, e il percorso del no continua verso il basso fino a un nodo finale.

• Questo modello è adatto a un flusso di lavoro che elabora operazioni aziendali indipendenti in parallelo. Il flusso di lavoro può diventare complicato quando la coreografia deve verificarsi in una sequenza. Ad esempio, Il servizio D può avviare l'operazione solo dopo che il servizio B e il servizio C completano correttamente le operazioni.

  

  Il diagramma mostra il flusso dei messaggi in un modello coreografico in cui i servizi elaborano le operazioni in parallelo e sequenziale. Nella parte superiore sono presenti cinque componenti disposti orizzontalmente: servizio A, un broker di messaggi, servizio B, servizio C e servizio D. All'estrema sinistra, un utente invia una richiesta al servizio A. Il servizio A converte la richiesta in un messaggio m1_a e lo pubblica sul broker di messaggi. Sotto il broker di messaggi, una sequenza temporale verticale mostra come ogni servizio gestisce i messaggi. All'interno di un'area ombreggiata con etichetta par per l'elaborazione parallela, il broker di messaggi recapita m1_a sia al servizio B che al servizio C contemporaneamente tramite frecce tratteggiate. Il servizio B elabora il messaggio e restituisce m1_b al broker di messaggi. Il servizio C elabora il messaggio e restituisce m1_c al broker di messaggi. Sul lato destro del diagramma, due piccole caselle rappresentano le condizioni di attesa per il servizio D. La prima condizione indica Attendere fino a m1_b e m1_c, che indica che il servizio D non può continuare finché non riceve entrambi i messaggi. La seconda condizione indica Attendere fino a m1_b. Dopo il completamento dell'elaborazione parallela e la risposta del servizio B e del servizio C, il broker messaggi invia m1_c al servizio D, seguito da m1_b. Il servizio D elabora questi messaggi e restituisce m1_d al broker di messaggi. Sotto il diagramma, una legenda illustra ogni notazione. La richiesta fa riferimento alla richiesta HTTP originale inviata a un endpoint pubblico. M1_a è la richiesta HTTP convertita in un messaggio. M1_b è il messaggio elaborato e inviato di nuovo al broker di messaggi dal servizio B. M1_c è il messaggio elaborato e inviato al broker di messaggi dal servizio C e m1_d indica che m1_b e m1_c vengono elaborati e restituiti come conferma finale al broker messaggi. Le frecce a tinta unita indicano i messaggi di pubblicazione e le frecce tratteggiate indicano i messaggi di sottoscrizione.

• Questo modello presenta problemi se il numero di servizi cresce rapidamente. Molte parti mobili indipendenti complicano il flusso di lavoro tra i servizi. Per mantenere l'osservabilità, è necessario usare in modo coerente gli identificatori di traccia e correlazione distribuiti.

• In una progettazione guidata dall'orchestratore, il componente centrale può delegare le responsabilità di resilienza, ad esempio la gestione dei tentativi per gli errori temporanei, non transitori e timeout, a un gestore dedicato alla resilienza.

  Quando si rimuove l'agente di orchestrazione in una progettazione basata su coreografia, i componenti downstream non assumono responsabilità di resilienza. Rimangono centralizzati nel gestore della resilienza. Tuttavia, i componenti downstream devono comunicare direttamente con il gestore, che aumenta la comunicazione da punto a punto.

• L'evoluzione dello schema di eventi può causare modifiche di rilievo nei consumatori nel corso del tempo. In questo modello, più servizi indipendenti consumano gli stessi eventi. Se un produttore modifica la struttura dei dati di un evento, può interrompere i consumatori a valle che dipendono dallo schema precedente. Usare un registro schemi per gestire i contratti di evento e adottare un'evoluzione retrocompatibile man mano che i servizi si evolvono in modo indipendente.

• L'ordinamento degli eventi non è garantito durante tentativi di ripetizione o in caso di scalabilità. Progettare per idempotenza e riemettere messaggi in sequenza per gestire eventi duplicati o fuori ordine.

• Le topologie di eventi decentralizzate possono creare comportamenti emergenti su larga scala. Quando molti servizi reagiscono agli eventi dell'altro, il sistema può produrre involontariamente cicli di feedback o tempeste di eventi. Un evento secondario potrebbe attivare una cascata di reazioni downstream. Per evitare catene di eventi circolari, usare misure di sicurezza come il filtraggio degli eventi, i limiti di concorrenza dei consumatori, la limitazione del flusso e le regole esplicite.

Quando usare questo modello

Usare questo modello quando:

• I componenti downstream gestiscono le operazioni atomica in modo indipendente. Si pensi a questo modello come a un meccanismo 'fire and forget', in cui un componente esegue un'attività che non richiede una gestione attiva. Al termine dell'attività, il componente invia una notifica agli altri componenti.

• Si prevede di aggiornare e sostituire frequentemente i componenti. Questo modello consente di modificare l'applicazione con un minor impegno e un'interruzione minima dei servizi esistenti.

• Si usano architetture serverless per flussi di lavoro semplici. I componenti possono avere breve durata e essere basati su eventi. Quando si verifica un evento, il servizio crea componenti che eseguono un'attività e il servizio rimuove i componenti dopo il completamento dell'attività.

• La comunicazione tra contesti delimitati richiede un accoppiamento libero tra i limiti del dominio. Per la comunicazione all'interno di un singolo contesto delimitato, applicare invece un pattern di orchestrazione.

• L'orchestratore centrale introduce un collo di bottiglia delle prestazioni.

Questo modello potrebbe non essere adatto quando:

• L'applicazione è complessa e richiede un componente centrale per gestire la logica condivisa per mantenere leggeri i componenti downstream.

• La comunicazione da punto a punto tra i componenti è inevitabile.

• È necessario usare la logica di business per consolidare tutte le operazioni gestite dai componenti downstream.

Progettazione del carico di lavoro

Valutare come usare il modello Coreografia nella progettazione di un carico di lavoro per affrontare gli obiettivi e i principi trattati nei pilastri di Azure Well-Architected Framework. La tabella seguente fornisce indicazioni su come questo modello supporta gli obiettivi di ogni pilastro.

Se questo modello introduce compromessi all'interno di un pilastro, considerarli contro gli obiettivi degli altri pilastri.

Esempio

Questo esempio illustra il modello Coreografa creando un carico di lavoro nativo del cloud basato su eventi che esegue funzioni insieme ai microservizi. Quando un client richiede di spedire un pacchetto, il carico di lavoro assegna un drone. Dopo che il pacchetto è pronto per il ritiro dal drone pianificato, viene avviato il processo di consegna. Mentre il pacchetto è in transito, il carico di lavoro gestisce il recapito fino a quando non riceve lo stato di spedizione.

Il servizio di inserimento riceve le richieste client e le converte in messaggi che includono i dettagli del recapito. Le transazioni aziendali iniziano dopo l'utilizzo dei nuovi messaggi da parte dei servizi.

Una singola transazione aziendale client richiede tre operazioni aziendali distinte:

• Creare o aggiornare un pacchetto.

• Assegnare un drone per recapitare il pacchetto.

• Gestire il recapito, incluso il controllo e l'invio di una notifica quando il pacchetto viene fornito.

I microservizi dei pacchetti, del gestore dei droni e del recapito eseguono l'elaborazione dei processi aziendali. I servizi usano la messaggistica anziché un agente di orchestrazione centrale per comunicare tra loro. Ogni servizio deve implementare un protocollo in anticipo che coordina il flusso di lavoro aziendale in modo decentralizzato.

Design

I servizi elaborano le transazioni aziendali in sequenza attraverso più passaggi. Ogni hop condivide un singolo bus di messaggi tra tutti i servizi aziendali.

Quando un client invia una richiesta di recapito tramite un endpoint HTTP, il servizio di inserimento lo riceve, lo converte in un messaggio e quindi pubblica il messaggio nel bus di messaggi condiviso. I servizi aziendali sottoscritti consumano i nuovi messaggi aggiunti al bus. Quando un servizio aziendale riceve il messaggio, completa correttamente l'operazione oppure la richiesta ha esito negativo o si verifica il timeout. Se la richiesta ha esito positivo, il servizio risponde al bus con il Ok codice di stato, genera un nuovo messaggio di operazione e lo invia al bus di messaggi. Se la richiesta ha esito negativo o si verifica il timeout, il servizio segnala l'errore inviando il codice motivo al bus di messaggi e quindi aggiunge il messaggio a una coda di messaggi non recapitabili (DLQ). Il servizio sposta anche i messaggi che non riesce a ricevere o elaborare entro un determinato periodo di tempo nella DLQ.

Questa progettazione usa più bus di messaggio per elaborare l'intera transazione aziendale. Il bus di servizio di Azure e Griglia di eventi di Azure forniscono la piattaforma del servizio di messaggistica per questa progettazione. Il carico di lavoro viene eseguito in Azure Container Apps, che ospita Azure Functions per l'inserimento. Container Apps gestisce l'elaborazione guidata dagli eventi che esegue la logica di business.

Questo design garantisce anche che la coreografia si verifichi in una sequenza. Un singolo spazio dei nomi del bus di servizio contiene un argomento con due sottoscrizioni e una coda compatibile con la sessione. Il servizio di inserimento pubblica messaggi nel topic. Il servizio di gestione dei pacchetti e il servizio di pianificazione dei droni si iscrivono al canale e pubblicano messaggi che notificano alla coda le richieste riuscite. Includere un identificatore di sessione comune che associa un GUID all'identificatore di recapito in modo che i servizi possano gestire sequenze non associate di messaggi correlati in ordine. Il servizio di recapito attende due messaggi correlati per ogni transazione. Il primo messaggio indica che il pacchetto è pronto per essere spedito e il secondo messaggio segnala che è pianificato un drone.

In questa progettazione, il bus di servizio gestisce messaggi di valore elevato che non devono essere persi o duplicati durante l'intero processo di recapito. Quando il pacchetto viene fornito, una modifica dello stato viene pubblicata in Griglia di eventi. Il mittente dell'evento non si aspetta come viene gestita la modifica dello stato. I servizi dell'organizzazione downstream che questa progettazione non include possono restare in ascolto di questo tipo di evento ed eseguire logica di business specifica, ad esempio l'invio di un messaggio di posta elettronica di stato dell'ordine all'utente.

Se distribuisci questo modello in un altro servizio di calcolo, ad esempio AKS, puoi implementare il boilerplate dell'applicazione del modello Publisher-Subscriber con due contenitori nello stesso pod. Un contenitore esegue l'ambassador che interagisce con il bus di messaggi scelto mentre l'altro contenitore esegue la logica di business. Questo approccio migliora le prestazioni e la scalabilità. L'ambasciatore e il servizio aziendale condividono la stessa rete, riducendo la latenza e aumentando la velocità effettiva.

Per evitare operazioni di ripetizione a catena che potrebbero causare più tentativi, i servizi aziendali devono contrassegnare immediatamente messaggi inaccettabili. Arricchite questi messaggi usando codici motivo comuni o un codice dell'applicazione definito affinché i servizi possano spostarli in una DLQ. Prendere in considerazione l'implementazione del modello Saga per gestire i problemi di coerenza dai servizi downstream. Ad esempio, un altro servizio gestisce i messaggi non recapitabili a scopo di correzione solo eseguendo una compensazione, un nuovo tentativo o una transazione pivot.

I servizi aziendali sono idempotenti per garantire che le operazioni di ripetizione dei tentativi non creino risorse duplicate. Ad esempio, il servizio pacchetti usa operazioni upsert per aggiungere dati all'archivio dati.

Passaggi successivi

• Centralizzare la gestione dello schema degli eventi usando il Registro schemi in Hub eventi di Azure per mantenere la compatibilità man mano che i servizi si evolvono.

• Esaminare le opzioni di messaggistica asincrona in Azure per informazioni sulle diverse opzioni di infrastruttura disponibili per l'implementazione di un flusso di lavoro decentralizzato.

• Valutare le funzionalità tecniche di piattaforme diverse per scegliere il servizio di messaggistica di Azure appropriato per i requisiti di coreografia specifici.

Risorse correlate

Prendi in considerazione questi modelli nel tuo design per la coreografia:

• Modularizzare il servizio aziendale usando il modello Ambassador.

• Implementare il modello di livellamento del carico basato su coda per gestire i picchi nel carico di lavoro.

• Usare la messaggistica distribuita asincrona tramite il modello diPublisher-Subscriber.

• Usare transazioni di compensazione per annullare una serie di operazioni riuscite se una o più operazioni correlate hanno esito negativo.