Consente a ogni componente del sistema di partecipare al processo decisionale sul flusso di lavoro di una transazione aziendale, anziché basarsi su un punto di controllo centrale.
Contesto e problema
Nell'architettura dei microservizi, spesso è possibile che un'applicazione basata sul cloud sia suddivisa in diversi servizi di piccole dimensioni che interagiscono per elaborare una transazione aziendale end-to-end. Per ridurre l'accoppiamento tra i servizi, ogni servizio è responsabile di una singola operazione aziendale. Alcuni vantaggi includono sviluppo più rapido, codebase più piccolo e scalabilità. Tuttavia, la progettazione di un flusso di lavoro efficiente e scalabile è una sfida e spesso richiede una comunicazione interservizi complessa.
I servizi comunicano tra loro usando API ben definite. Anche una singola operazione aziendale può comportare più chiamate da punto a punto tra tutti i servizi. Un modello comune per la comunicazione consiste nell'usare un servizio centralizzato che funge da agente di orchestrazione. Riconosce tutte le richieste in ingresso e delega le operazioni ai rispettivi servizi. In questo modo, gestisce anche il flusso di lavoro dell'intera transazione aziendale. Ogni servizio completa solo un'operazione e non è a conoscenza del flusso di lavoro complessivo.
Il modello dell'agente di orchestrazione riduce la comunicazione da punto a punto tra i servizi, ma presenta alcuni svantaggi a causa dell'accoppiamento stretto tra l'agente di orchestrazione e altri servizi che partecipano all'elaborazione della transazione aziendale. Per eseguire attività in una sequenza, l'agente di orchestrazione deve avere alcune conoscenze di dominio sulle responsabilità di tali servizi. Se si desidera aggiungere o rimuovere servizi, la logica esistente verrà interrotta e sarà necessario collegare parti del percorso di comunicazione. Sebbene sia possibile configurare il flusso di lavoro, aggiungere o rimuovere facilmente servizi con un agente di orchestrazione ben progettato, tale implementazione è complessa e difficile da gestire.
Soluzione
Consentire a ogni servizio di decidere quando e come viene elaborata un'operazione aziendale, invece di dipendere da un agente di orchestrazione centrale.
Un modo per implementare la coreografia consiste nell'usare il modello di messaggistica asincrona per coordinare le operazioni aziendali.
Una richiesta client pubblica messaggi in una coda di messaggi. Quando arrivano i messaggi, vengono inviati ai sottoscrittori o ai servizi interessati a tale messaggio. Ogni servizio sottoscritto esegue l'operazione come indicato dal messaggio e risponde alla coda dei messaggi con esito positivo o negativo dell'operazione. In caso di 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 un'operazione non riesce, il bus di messaggi può ritentare l'operazione.
In questo modo, i servizi coreografano il flusso di lavoro tra loro senza dipendere da un agente di orchestrazione o avere una comunicazione diretta tra di loro.
Poiché non esiste una comunicazione da punto a punto, questo modello consente di ridurre l'accoppiamento tra i servizi. Inoltre, può rimuovere il collo di bottiglia delle prestazioni causato dall'agente di orchestrazione quando deve gestire tutte le transazioni.
Quando usare questo modello
Usa il modello coreografico se prevedi di aggiornare o sostituire frequentemente i servizi e aggiungere o rimuovere alcuni servizi alla fine. L'intera app può essere modificata con un minor impegno e un'interruzione minima dei servizi esistenti.
Prendere in considerazione questo modello se si verificano colli di bottiglia delle prestazioni nell'agente di orchestrazione centrale.
Questo modello è un modello naturale per l'architettura serverless in cui tutti i servizi possono essere di breve durata o basati su eventi. I servizi possono essere attivati a causa di un evento, eseguire l'attività e vengono rimossi al termine dell'attività.
Considerazioni e problemi
La decentralizzazione dell'agente di orchestrazione può causare problemi durante la gestione del flusso di lavoro.
Se un servizio non riesce a completare un'operazione aziendale, può essere difficile eseguire il ripristino da tale errore. Un modo consiste nel fare in modo che il servizio indichi un errore attivando un evento. Un altro servizio sottoscrive tali eventi non riusciti esegue azioni necessarie, ad esempio l'applicazione di transazioni di compensazione alle operazioni di annullamento dell'esito positivo in una richiesta. Il servizio non riuscito potrebbe anche non generare un evento per l'errore. In tal caso, è consigliabile usare un nuovo tentativo e o un meccanismo di timeout per riconoscere tale operazione come errore. Per un esempio, vedere la sezione Esempio .
È semplice implementare un flusso di lavoro quando si vogliono elaborare operazioni aziendali indipendenti in parallelo. È possibile usare un singolo bus di messaggi. Tuttavia, il flusso di lavoro può diventare complicato quando la coreografia deve verificarsi in una sequenza. Ad esempio, il servizio C può avviare l'operazione solo dopo che il servizio A e il servizio B hanno completato le operazioni con esito positivo. Un approccio consiste nell'avere più bus di messaggi o code che ricevono messaggi nell'ordine richiesto. Per altre informazioni, vedere la sezione Esempio .
Il modello coreografico diventa una sfida se il numero di servizi cresce rapidamente. Dato il numero elevato di parti in movimento indipendenti, il flusso di lavoro tra i servizi tende a diventare complesso. Inoltre, la traccia distribuita diventa difficile.
L'agente di orchestrazione gestisce centralmente la resilienza del flusso di lavoro e può diventare un singolo punto di errore. D'altra parte, per la coreografia, il ruolo viene distribuito tra tutti i servizi e la resilienza diventa meno robusto.
Ogni servizio non è responsabile solo della resilienza dell'operazione, ma anche del flusso di lavoro. Questa responsabilità può essere onerosa per il servizio e difficile da implementare. Ogni servizio deve ripetere gli errori temporanei, non transienti e timeout, in modo che la richiesta venga terminata normalmente, se necessario. Inoltre, il servizio deve essere diligente sulla comunicazione dell'esito positivo o negativo dell'operazione in modo che altri servizi possano agire di conseguenza.
Progettazione del carico di lavoro
Un architetto deve valutare il modo in cui il modello coreografico può essere usato nella progettazione del carico di lavoro per soddisfare gli obiettivi e i principi trattati nei pilastri di Azure Well-Architected Framework. Ad esempio:
| Concetto fondamentale | Come questo modello supporta gli obiettivi di pilastro |
|---|---|
| L'eccellenza operativa consente di offrire la qualità del carico di lavoro attraverso processi standardizzati e coesione del team. | Poiché i componenti distribuiti in questo modello sono autonomi e progettati per essere sostituibili, è possibile modificare il carico di lavoro con modifiche meno complessive al sistema. - Strumenti e processi di OE:04 |
| L'efficienza delle prestazioni consente al carico di lavoro di soddisfare in modo efficiente le richieste tramite ottimizzazioni in termini di scalabilità, dati, codice. | Questo modello offre un'alternativa quando si verificano colli di bottiglia delle prestazioni in una topologia di orchestrazione centralizzata. - PE:02 Pianificazione della capacità - PE:05 Ridimensionamento e partizionamento |
Come per qualsiasi decisione di progettazione, prendere in considerazione eventuali compromessi rispetto agli obiettivi degli altri pilastri che potrebbero essere introdotti con questo modello.
Esempio
Questo esempio illustra il modello coreografico creando un carico di lavoro nativo del cloud basato su eventi che esegue funzioni insieme ai microservizi. Quando un client richiede la spedizione di un pacchetto, il carico di lavoro assegna un drone. Una volta che il pacchetto è pronto per il ritiro dal drone pianificato, viene avviato il processo di consegna. Durante il transito, il carico di lavoro gestisce il recapito fino a quando non ottiene lo stato spedito.
Questo esempio è un refactoring dell'implementazione del recapito tramite drone che sostituisce il modello Orchestrator con il modello Coreografia.
Il servizio di inserimento gestisce le richieste client e le converte in messaggi, inclusi i dettagli del recapito. Le transazioni aziendali vengono avviate dopo l'utilizzo di tali nuovi messaggi.
Una singola transazione aziendale client richiede tre operazioni aziendali distinte: la creazione o l'aggiornamento di un pacchetto, l'assegnazione di un drone per recapitare il pacchetto e la corretta gestione del recapito che consiste nel controllare e alla fine aumentare la consapevolezza quando viene spedito. Tre microservizi eseguono l'elaborazione aziendale: Pacchetti, Utilità di pianificazione droni e Servizi di recapito. Anziché un agente di orchestrazione centrale, i servizi usano la messaggistica per comunicare tra loro. Ogni servizio sarà responsabile dell'implementazione anticipata di un protocollo che coordina in modo decentralizzato il flusso di lavoro aziendale.
Progettazione
La transazione aziendale viene elaborata in una sequenza tramite più hop. 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, converte tale richiesta in un messaggio e quindi pubblica il messaggio nel bus di messaggi condiviso. I servizi aziendali sottoscritti stanno per consumare nuovi messaggi aggiunti al bus. Quando si riceve il messaggio, i servizi aziendali possono completare l'operazione con esito positivo, negativo o il timeout della richiesta. In caso di esito positivo, i servizi rispondono al bus con il codice di stato Ok, genera un nuovo messaggio di operazione e lo invia al bus di messaggi. Se si verifica un errore o un timeout, il servizio segnala un errore inviando il codice motivo al bus di messaggi. Inoltre, il messaggio verrà inviato a messaggi non recapitabili per una gestione successiva. I messaggi che non possono essere ricevuti o elaborati entro un periodo di tempo ragionevole e appropriato vengono spostati anche la DQ.
La progettazione usa più bus di messaggio per elaborare l'intera transazione aziendale. bus di servizio di Microsoft Azure e Microsoft Griglia di eventi di Azure sono composti per fornire la piattaforma del servizio di messaggistica per questa progettazione. Il carico di lavoro viene distribuito in App Contenitore di Azure che ospita Funzioni di Azure per l'inserimento e le app che gestiscono l'elaborazione basata su eventi che esegue la logica di business.
Il design garantisce che la coreografia venga eseguita in una sequenza. Un singolo spazio dei nomi bus di servizio di Azure contiene un argomento con due sottoscrizioni e una coda compatibile con la sessione. Il servizio di inserimento pubblica messaggi nell'argomento. Il servizio Package e drone Scheduler sottoscrivono l'argomento e pubblicano messaggi che comunicano l'esito positivo alla coda. Includendo un identificatore di sessione comune associato a un GUID associato all'identificatore di recapito, consente la gestione ordinata di sequenze non associate di messaggi correlati. Il servizio di recapito attende due messaggi correlati per transazione. Il primo messaggio indica che il pacchetto è pronto per essere spedito e il secondo segnala che un drone è pianificato.
Questa progettazione usa bus di servizio di Azure per gestire messaggi di valore elevato che non possono essere persi o duplicati durante l'intero processo di recapito. Quando il pacchetto viene spedito, viene pubblicato anche un cambiamento di stato in Griglia di eventi di Azure. In questa progettazione, il mittente dell'evento non si aspetta come viene gestita la modifica dello stato. I servizi dell'organizzazione downstream che non sono inclusi nell'ambito di questa progettazione potrebbero essere in ascolto di questo tipo di evento e reagire eseguendo una logica specifica per lo scopo aziendale, ovvero inviare un messaggio di posta elettronica allo stato dell'ordine spedito all'utente.
Se si prevede di distribuirlo in un altro servizio di calcolo, ad esempio il servizio Azure Kubernetes pub-sub pattern application boilplate, può essere implementato con due contenitori nello stesso pod. Un contenitore esegue l'ambassador che interagisce con il bus di messaggi di preferenza mentre l'altro esegue la logica di business. L'approccio con due contenitori nello stesso pod migliora le prestazioni e la scalabilità. L'ambasciatore e il servizio aziendale condividono la stessa rete consentendo bassa latenza e velocità effettiva elevata.
Per evitare operazioni di ripetizione dei tentativi a catena che potrebbero portare a più sforzi, i servizi aziendali devono contrassegnare immediatamente messaggi inaccettabili. È possibile arricchire tali messaggi usando codici motivo noti o un codice dell'applicazione definito, in modo che possa essere spostato in una coda di messaggi non recapitabili (DLQ). Valutare la possibilità di gestire i problemi di coerenza che implementano Saga dai servizi downstream. Ad esempio, un altro servizio potrebbe gestire messaggi non recapitabili a scopo di correzione solo eseguendo una compensazione, una transazione pivot o una correzione.
I servizi aziendali sono idempotenti per assicurarsi che le operazioni di ripetizione dei tentativi non comportino risorse duplicate. Ad esempio, il servizio pacchetto usa operazioni upsert per aggiungere dati all'archivio dati.
Risorse correlate
Considera questi modelli nel tuo design per la coreografia.
Modularizzare il servizio aziendale usando il modello di progettazione ambassador.
Implementare un modello di livellamento del carico basato su coda per gestire i picchi del carico di lavoro.
Usare la messaggistica distribuita asincrona tramite il modello publisher-subscriber.
Usare transazioni di compensazione per annullare una serie di operazioni riuscite in caso di esito negativo di una o più operazioni correlate.
Per informazioni sull'uso di un broker di messaggi in un'infrastruttura di messaggistica, vedere Opzioni di messaggistica asincrona in Azure.