Pattern di choreography e orchestration

Quando i microservizi devono collaborare per completare un processo aziendale, esistono due pattern fondamentali di coordinamento. Orchestration utilizza un coordinatore centrale (come Step Functions) che impartisce comandi espliciti a ciascun servizio. Choreography non prevede un coordinatore centrale: i servizi ascoltano gli eventi e reagiscono in modo indipendente. Capire quale utilizzare e quando combinarli è una competenza architetturale fondamentale verificata nell'esame SAA-C03.

Nell'orchestration, un servizio centrale (l'orchestratore) controlla la sequenza delle operazioni. Chiama il Servizio A, attende la risposta, quindi chiama il Servizio B e così via. L'orchestratore ha piena visibilità dello stato del processo, gestisce errori e nuovi tentativi e può prendere decisioni basate sui risultati intermedi. In AWS, Step Functions è l'orchestratore di riferimento: definisce l'intero flusso di lavoro come una macchina a stati e gestisce ogni fase.

Nella choreography, i servizi comunicano tramite eventi senza un coordinatore centrale. Il Servizio A completa la propria attività e pubblica un evento (ad esempio, OrderValidated) su un event bus o un topic. Il Servizio B ascolta gli eventi OrderValidated ed elabora il pagamento, quindi pubblica PaymentCharged. Il Servizio C ascolta PaymentCharged e spedisce l'ordine. Ogni servizio è autonomo e disaccoppiato: conosce solo gli eventi che consuma e produce, non gli altri servizi.

In AWS, Step Functions è lo strumento principale per l'orchestration. Per la choreography, gli strumenti principali sono Amazon EventBridge (per instradare gli eventi tra i servizi con il filtraggio basato sul contenuto), Amazon SNS (per un semplice fan-out) e Amazon SQS (per lo scambio di messaggi point-to-point tra servizi). È possibile combinare i pattern: utilizzi EventBridge per la choreography tra contesti delimitati di domini diversi e Step Functions per orchestrare le fasi all'interno di un singolo dominio.

L'orchestration offre una visibilità centralizzata: la cronologia delle esecuzioni di Step Functions mostra esattamente a che punto si trova un flusso di lavoro, quanto è durata ogni fase e cosa non ha funzionato. Il debug è semplice. La choreography distribuisce la visibilità tra più servizi ed event bus: per tracciare una singola transazione aziendale è necessario correlare log ed eventi tra numerosi servizi. Per questo i sistemi basati sulla choreography fanno ampio affidamento sugli ID di correlazione e sul tracing distribuito (AWS X-Ray) per ottenere visibilità end-to-end.

La choreography offre un accoppiamento più debole: aggiungere un nuovo servizio che ascolta eventi esistenti non richiede modifiche ai servizi esistenti. Ad esempio, aggiungere un servizio di analisi che ascolta gli eventi OrderPlaced non ha alcun impatto sui servizi degli ordini o dei pagamenti. L'orchestration introduce un accoppiamento più stretto tra l'orchestratore e tutti i servizi che chiama: aggiungere una nuova fase richiede la modifica della definizione della macchina a stati, anche se i singoli servizi rimangono isolati.

L'orchestration rende esplicita la gestione degli errori: i blocchi Catch di Step Functions definiscono stati di fallback per ogni tipo di errore e l'intera cronologia del flusso di lavoro mostra il contesto dell'errore. Nella choreography, la gestione degli errori è distribuita: ogni servizio deve gestire i propri errori e può eventualmente pubblicare un evento di errore a cui gli altri possono reagire. Implementare le sagas (transazioni compensative per annullare il lavoro quando una fase non riesce) è molto più complesso nella choreography che nell'orchestration.

Preferisca l'orchestration quando: il processo aziendale presenta una sequenza lineare o ramificata chiara, con esiti espliciti di successo o di errore; è necessaria una visibilità centralizzata sullo stato del processo per motivi operativi o di conformità; la gestione degli errori include una logica di compensazione complessa; oppure il flusso di lavoro è di lunga durata e deve sopravvivere ai riavvii dei servizi. Esempi: evasione degli ordini, onboarding dei pazienti, elaborazione delle richieste di risarcimento assicurativo: tutti flussi di lavoro con requisiti chiari di inizio, fine e audit.

Preferisca la choreography quando: i servizi sono gestiti da team diversi che non dovrebbero essere strettamente coordinati; il sistema deve poter essere esteso con nuovi servizi senza modificare quelli esistenti; gli eventi rappresentano fatti anziché comandi (ad esempio, 'OrderShipped' e non 'ShipOrder'); oppure desidera la massima scalabilità, poiché non esiste un collo di bottiglia centrale. Esempi: acquisizione di dati analitici, fanout delle notifiche, registrazione degli audit: tutti casi in cui più consumatori indipendenti reagiscono allo stesso evento.

La maggior parte delle architetture AWS reali utilizza entrambi i pattern a diversi livelli di granularità. Un approccio ibrido comune consiste nell'utilizzare la coreografia con EventBridge per disaccoppiare i contesti delimitati (ad esempio, il dominio degli ordini emette eventi, mentre i domini Inventario, Pagamenti e Spedizioni rispondono ciascuno in modo indipendente), mentre all'interno del dominio Pagamenti si utilizza l'orchestrazione con Step Functions per coordinare le fasi del flusso di pagamento interno (addebito, controllo antifrode, autorizzazione, regolamento). In questo modo si ottiene un accoppiamento debole tra i domini e, al contempo, chiarezza nei processi interni.

Durante l'esame, presti attenzione a questi indicatori. Parole chiave della coreografia: «accoppiamento debole», «i servizi reagiscono agli eventi», «i team sono proprietari di servizi indipendenti», «fan-out verso più consumer», «aggiungere un nuovo servizio senza modificare quelli esistenti». Parole chiave dell'orchestrazione: «coordinare i passaggi in sequenza», «tenere traccia dello stato del flusso di lavoro», «gestire gli errori parziali con compensazione», «fase di approvazione umana», «processo di lunga durata con gestione degli errori». Una domanda che descrive un coordinatore centrale che dirige altri servizi riguarda sempre l'orchestrazione.

Verifichi la propria comprensione dei concetti AWS Solutions Architect (SAA-C03) trattati in questa lezione.

In questa lezione ha imparato che: l'orchestrazione utilizza un coordinatore centrale (Step Functions) per un controllo esplicito e visibile del flusso di lavoro, la coreografia utilizza gli eventi (EventBridge) per ottenere un accoppiamento debole e favorire l'estensibilità e la maggior parte delle architetture di produzione combina entrambi i pattern a diversi livelli di granularità. Nel prossimo argomento analizzeremo il formato dell'esame SAA-C03 e una strategia basata sul peso dei domini.