Azure Service Bus per la messaggistica disaccoppiata

Nelle architetture fortemente accoppiate, i servizi effettuano chiamate sincrone: se il servizio downstream è lento o non disponibile, anche il chiamante resta bloccato o non riesce a completare l'operazione. Le code di messaggi introducono un buffer asincrono tra produttori e consumer, evitando che la lentezza di un servizio downstream provochi una cascata di errori verso monte. Azure Service Bus è il servizio di messaggistica enterprise di Microsoft, progettato per garantire elevati livelli di affidabilità, e offre code (point-to-point) e topic (publish-subscribe), con funzionalità di consegna garantita, ordinamento e gestione dei messaggi non recapitabili.

Un namespace di Service Bus è il contenitore di livello superiore per tutte le entità di messaggistica (code e topic) e fornisce l'endpoint FQDN (ad esempio myns.servicebus.windows.net). I namespace sono disponibili in tre livelli: Basic (solo code, senza topic, dimensione massima dei messaggi di 256 KB), Standard (code e topic, massimo 256 KB) e Premium (code e topic, messaggi fino a 100 MB, capacità dedicata, integrazione con VNet e ripristino da emergenza geografica). Il livello Premium è necessario per i carichi di lavoro di produzione che richiedono prestazioni coperte da SLA.

Una coda di Service Bus archivia i messaggi in ordine FIFO e consegna ogni messaggio a un solo consumer. I consumer ricevono i messaggi usando un meccanismo di peek-lock: il messaggio viene temporaneamente nascosto agli altri consumer durante l'elaborazione. Se il consumer completa correttamente l'elaborazione, chiama CompleteMessage() per rimuovere il messaggio dalla coda. Se l'elaborazione non riesce, il consumer chiama AbandonMessage() e il messaggio torna visibile per un nuovo tentativo. Dopo un numero configurabile di tentativi di consegna, i messaggi che non possono essere elaborati vengono spostati nella coda dead-letter (DLQ).

I topic implementano il modello publish-subscribe: un produttore invia un messaggio a un topic e ogni sottoscrizione a quel topic riceve una copia del messaggio. Le sottoscrizioni possono avere filtri (espressioni SQL o di correlazione) per ricevere solo un sottoinsieme dei messaggi; ad esempio, una sottoscrizione HighPriority che riceve solo i messaggi in cui la proprietà Priority è uguale a High. In questo modo, un singolo topic può distribuire i messaggi a molti servizi downstream, ciascuno interessato a un sottoinsieme diverso di eventi.

Azure Service Bus SDK fornisce un ServiceBusClient per l'invio e la ricezione dei messaggi. Per inviare un messaggio, crei un ServiceBusSender e chiami SendMessageAsync(). Per riceverlo, crei un ServiceBusReceiver e chiami ReceiveMessageAsync() (basato sul pull), oppure usi un ServiceBusProcessor con un gestore di eventi per un'elaborazione continua basata sul push. L'uso di DefaultAzureCredential con Service Bus SDK elimina la necessità delle stringhe di connessione, mantenendo il modello senza password.

La coda dead-letter (DLQ) è una sottocoda che riceve automaticamente i messaggi che non possono essere consegnati. I messaggi vengono spostati nella coda dead-letter quando superano il numero massimo di consegne, scadono (è trascorso il TTL) oppure non superano la valutazione del filtro di una sottoscrizione a un topic. Il monitoraggio della DLQ è essenziale: una DLQ in crescita indica un errore sistematico nell'elaborazione. I messaggi della DLQ conservano il contenuto originale e includono le proprietà motivo del dead-letter e descrizione, aggiunte da Service Bus per facilitare la diagnosi della causa principale.

Le sessioni consentono di mantenere un ordinamento rigoroso per i messaggi appartenenti allo stesso gruppo logico. Ogni messaggio è contrassegnato con un SessionId (ad esempio un ID cliente o un ID ordine) e un consumer che supporta le sessioni riceve tutti i messaggi di una determinata sessione esclusivamente e in ordine FIFO. Le sessioni sono essenziali per i flussi di lavoro in cui i passaggi devono essere eseguiti in sequenza, ad esempio per elaborare tutti gli eventi di un ordine specifico: Created → PaymentReceived → Shipped → Delivered. Le sessioni vengono abilitate al momento della creazione della coda o della sottoscrizione.

Questi tre servizi di messaggistica Azure vengono spesso confusi: Service Bus è destinato alla messaggistica enterprise affidabile e transazionale, con ordinamento, sessioni e DLQ; è adatto all'elaborazione degli ordini, alle transazioni finanziarie e all'orchestrazione dei flussi di lavoro. Event Grid serve per il routing reattivo degli eventi (un blob è stato caricato, una VM è stata eliminata), con distribuzione a più gestori ma senza ordinamento né possibilità di riprodurre gli eventi. Event Hubs è destinato allo streaming di eventi ad alta velocità (milioni di eventi al secondo), con possibilità di riprodurli; è adatto alla telemetria IoT e all'acquisizione dei log. La scelta dipende dai requisiti di ordinamento, velocità effettiva e durabilità.

Il ripristino da emergenza geografica (Geo-DR) di Service Bus replica i metadati del namespace (code, topic, sottoscrizioni e criteri di accesso) in un'area secondaria. Le aree associate condividono un unico nome host alias; se l'area primaria non è disponibile, si avvia un failover e l'alias viene risolto nell'area secondaria. Si noti che i dati dei messaggi (i messaggi in transito) non vengono replicati nel livello Standard: solo il Geo-DR del livello Premium replica i messaggi. Per la messaggistica mission-critical, usi Premium + Geo-DR per soddisfare i requisiti di RTO e RPO.

Per gli scenari ad alta velocità effettiva, abiliti il partizionamento di code e topic al momento della creazione. Le entità partizionate usano internamente più broker di messaggi e frammenti di archiviazione, moltiplicando la capacità effettiva. Nel livello Standard, le entità partizionate hanno una dimensione complessiva massima di 80 GB. Ogni messaggio viene instradato a una partizione in base alla proprietà PartitionKey (per impostazione predefinita, l'ID della sessione se le sessioni sono abilitate). Il partizionamento è una decisione da prendere una sola volta, al momento della creazione: non è possibile partizionare una coda esistente. Usi il livello Premium per ottenere la massima velocità effettiva garantita senza la complessità del partizionamento.

Metriche chiave di Service Bus da monitorare in Azure Monitor: Active Messages (profondità della coda: un aumento indica un ritardo dei consumer), Dead-lettered Messages (errori di elaborazione), Server Errors e User Errors (problemi di autenticazione e limitazione della velocità), e Incoming Requests (velocità effettiva complessiva). Configuri avvisi sulle metriche per notificare ai team operativi quando la coda dead-letter supera una determinata soglia o quando i messaggi attivi non vengono consumati per un periodo prolungato.

Verifichi la Sua comprensione dei concetti di Microsoft Azure Fundamentals (AZ-900) trattati in questa lezione.

In questa lezione ha imparato che: le code di Service Bus forniscono messaggistica point-to-point con consegna tramite peek-lock e una coda dead-letter per i messaggi non riusciti; topic e sottoscrizioni distribuiscono i messaggi a più consumer usando regole di filtro; infine, le sessioni consentono di elaborare in ordine i messaggi appartenenti allo stesso gruppo logico. Ora esamineremo Azure Container Apps per la distribuzione di microservizi moderni.