Microsoft AZ-204: Soluzioni Basate su Eventi e Messaggi di Azure — Guida allo studio

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Fa parte della Microsoft Azure Developer Associate AZ-204 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Il portafoglio di servizi di messaggistica ed eventi di Azure comprende quattro servizi complementari: Event Grid per la gestione reattiva degli eventi, Event Hubs per l’ingestione di flussi di dati ad alta velocità, Service Bus per la messaggistica aziendale e il coordinamento dei flussi di lavoro, e Notification Hubs per le notifiche push su dispositivi mobili. La padronanza di questi servizi richiede la conoscenza delle astrazioni principali di ciascuno, delle semantiche di consegna e di ritentativo, dei modelli di scalabilità e di quando preferire un servizio rispetto a un altro nei pattern applicativi tipici come pub/sub, elaborazione di comandi, ingestione di telemetria e notifiche a dispositivi o utenti.

Event Grid: Argomenti, Sottoscrizioni, Schema, Filtraggio e Dead-Lettering

Event Grid è un fabric pub/sub completamente gestito, basato su push, per eventi discreti. I publisher inviano eventi a un argomento (topic); i sottoscrittori registrano sottoscrizioni di eventi su un argomento e ricevono gli eventi corrispondenti presso gestori (handler) supportati come webhook HTTPS, Azure Functions, Logic Apps, Service Bus, Storage Queues ed Event Hubs. Event Grid definisce due modelli di publisher. Gli argomenti di sistema (System topics) sono risorse di argomenti gestite da Azure che rappresentano servizi Azure di prima parte che pubblicano eventi all’interno della tua sottoscrizione o del tuo gruppo di risorse (ad esempio, la creazione di un blob in Storage, la rotazione di un segreto in Key Vault o eventi di Resource Manager). Gli argomenti personalizzati (Custom topics) sono endpoint di argomenti creati dall’utente a cui le tue applicazioni pubblicano, abilitando pattern event-driven tra i tuoi servizi e domini. Gli argomenti di sistema non richiedono codice da parte del publisher e semplificano la connessione delle risorse Azure a gestori reattivi; gli argomenti personalizzati ti danno il pieno controllo sui contratti e sul ciclo di vita degli eventi.

Gli eventi di Event Grid possono utilizzare lo schema nativo di Event Grid o la specifica CloudEvents v1.0. Con lo schema di Event Grid, ogni evento include id (identificatore univoco), eventType (l’azione), subject (percorso gerarchico che supporta il filtraggio), eventTime (UTC), data (payload), dataVersion, metadataVersion e topic. CloudEvents fornisce un set standardizzato di attributi come id, source, type, time, subject e data. La scelta di CloudEvents facilita l’interoperabilità tra piattaforme; lo schema di Event Grid mantiene la parità con gli eventi originati da Azure e un ricco filtraggio sul subject.

Le sottoscrizioni di eventi definiscono il routing, le opzioni di consegna e i filtri. I filtri di base includono l’inclusione del tipo di evento e il prefisso/suffisso del subject (subjectBeginsWith, subjectEndsWith), che sono efficienti per la denominazione gerarchica delle risorse. I filtri avanzati effettuano il matching su campi nell’evento di primo livello o all’interno dei dati (data) (ad esempio, confronti di intervalli numerici, contains senza distinzione tra maiuscole e minuscole per le stringhe, equals booleano e contains per gli array). È possibile combinare i filtri per un controllo preciso del fan-out, minimizzando il lavoro a valle e l’egress.

La consegna è di tipo push con semantica at-least-once (almeno una volta). Event Grid effettua tentativi con back-off esponenziale. È possibile configurare il numero massimo di tentativi e il time-to-live (TTL) dell’evento; quando la consegna fallisce definitivamente o l’evento scade, Event Grid può inviare l’evento in modalità dead-letter a un container di Blob Storage designato nella sottoscrizione. Il dead-lettering conserva i payload e i metadati per l’auditing o la rielaborazione; se necessario, si può utilizzare un processo separato per reidratare e rieseguire gli eventi. Gli endpoint webhook partecipano a un handshake di convalida per dimostrare la proprietà e, per reti con restrizioni, si possono preferire endpoint Azure gestiti (Functions, Service Bus, Storage Queue) che non necessitano di esposizione pubblica e possono utilizzare l’autorizzazione basata su Azure AD.

Event Hubs: Partizioni, Gruppi di Consumer, Throughput, Acquisizione e Consumo Affidabile

Event Hubs acquisisce flussi di telemetria e log ad alto volume con bassa latenza. I dati vengono aggiunti a partizioni, che sono commit log indipendenti e ordinati. Le partizioni vengono definite al momento della creazione per parallelizzare il throughput; i producer assegnano una chiave di partizione (partition key) per preservare l’ordinamento per chiave, e il servizio esegue l’hashing delle chiavi per assegnarle alle partizioni. Più lettori possono elaborare le partizioni in parallelo; all’interno di una partizione, l’ordinamento è garantito.

I gruppi di consumer (consumer group) forniscono viste indipendenti dello stream, consentendo a diverse applicazioni di elaborazione di mantenere la propria posizione senza interferire tra loro (ad esempio, un sistema di rilevamento anomalie in tempo reale e una pipeline di archiviazione). La scalabilità orizzontale dei lettori richiede il bilanciamento della proprietà delle partizioni (partition ownership); l’EventProcessorClient dell’SDK coordina l’assegnazione e il ribilanciamento delle partizioni tra le istanze.

Le Throughput Unit (TU) nel livello Standard definiscono la capacità: ogni TU dà diritto a quote di larghezza di banda in ingresso (ingress) e in uscita (egress). La funzione Auto-inflate può scalare automaticamente le TU verso l’alto per gestire i picchi di carico. Il livello Premium utilizza le Processing Unit con capacità di calcolo dedicata e latenza prevedibile. Monitorare le metriche di throttling per convalidare il provisioning. Event Hubs supporta il protocollo Kafka sullo stesso endpoint, semplificando il lift-and-shift da client Kafka senza la necessità di gestire broker.

I producer possono usare AMQP o HTTPS. AMQP (incluso AMQP-over-WebSockets sulla porta 443) fornisce connessioni persistenti e multiplexate e un batching efficiente, ed è raccomandato sia per l’invio che per la ricezione. HTTPS è adatto per invii semplici o sporadici ma non è supportato per la ricezione; il long-polling non è disponibile e si sacrificano l’efficienza e il controllo di flusso (flow control). In reti aziendali con restrizioni, AMQP-over-WebSockets preserva le prestazioni passando attraverso i tipici proxy in uscita.

Il checkpointing e la gestione degli offset sono critici per la correttezza dell’elaborazione. Ogni evento ha un numero di sequenza (sequence number) e un offset per partizione. I ricevitori (receiver) avanzano lungo lo stream e, dopo aver elaborato con successo un batch, salvano la loro posizione (checkpoint) su uno storage durevole, comunemente un container Azure Blob Storage tramite l’EventProcessorClient. In caso di riavvio o failover, il processore riprende dall’ultimo checkpoint, ottenendo un’elaborazione di tipo at-least-once (almeno una volta) con gestori idempotenti. Senza checkpoint, i consumer partono da una posizione predefinita (la più recente o la più vecchia) e rischiano di rielaborare o saltare eventi.

La funzione Capture fornisce un’archiviazione lato server scrivendo automaticamente file Avro in batch e in modalità append-only su Azure Blob Storage o Azure Data Lake Storage Gen2, in base a una finestra temporale o di dimensione configurabile. Questo elimina la necessità di creare meccanismi di batching personalizzati per l’analisi cold-path, consentendo a strumenti a valle (Spark, Synapse) di consumare segmenti di stream immutabili con semantica exactly-once relativa alla pipeline di acquisizione.

Service Bus e Queue Storage: Comandi, Flussi di Lavoro, Sessioni e Gestione dei Messaggi Avvelenati

Service Bus è un message broker di livello enterprise per comandi, flussi di lavoro e scenari di integrazione che richiedono garanzie di recapito avanzate. Le code (Queues) implementano la messaggistica point-to-point; un consumer concorrente riceve ogni messaggio. Gli argomenti (Topics) con sottoscrizioni (subscriptions) abilitano il modello pub/sub: i publisher inviano a un topic e le sottoscrizioni indipendenti ricevono copie in base a delle regole. Le regole di sottoscrizione possono essere filtri SQL, filtri di correlazione o filtri booleani “true” che calcolano l’inclusione per ogni messaggio e possono aggiungere o modificare le proprietà del messaggio tramite azioni.

Le sessioni (Sessions) forniscono un’elaborazione ordinata ed esclusiva per i messaggi correlati. Assegna un SessionId ai messaggi che appartengono allo stesso gruppo (ad esempio, tutti i passaggi dell’Ordine 123). Un ricevitore accetta il blocco della sessione (session lock) ed elabora i messaggi in ordine di arrivo per quella sessione, mantenendo uno stato di sessione opzionale, quindi rilascia la sessione per consentire al consumer successivo di assumerne la proprietà. Questo è il pattern preferito per ottenere il FIFO su larga scala. Senza sessioni, l’ordinamento non è garantito tra i consumer concorrenti.

Service Bus supporta le modalità PeekLock e ReceiveAndDelete. PeekLock è la modalità predefinita per l’affidabilità: un consumer blocca un messaggio per la durata del blocco (lock duration), lo elabora e poi lo finalizza con Complete. Se l’elaborazione fallisce, il consumer può eseguire un’operazione di Abandon (rendendolo di nuovo disponibile), Defer (posticipandone il recupero a un momento successivo tramite il numero di sequenza) o Dead-letter (spostandolo nella sottocoda dei messaggi non recapitabili, o dead-letter subqueue, dell’entità, con motivo e descrizione dell’errore). ReceiveAndDelete scambia l’affidabilità con il throughput, rimuovendo il messaggio immediatamente dopo la ricezione.

Le proprietà chiave controllano il ciclo di vita. Il Time to Live (TTL) può essere impostato a livello di entità e sovrascritto per ogni singolo messaggio; i messaggi scaduti vengono spostati nella coda dei messaggi non recapitabili (dead-lettered) o eliminati in base alla configurazione. La durata del blocco (Lock duration) controlla per quanto tempo un messaggio rimane bloccato per l’elaborazione; l’SDK può rinnovare automaticamente i blocchi per lavori di lunga durata, entro i limiti massimi. Il numero massimo di recapiti (Max delivery count) è configurato per coda o sottoscrizione; dopo tale numero di tentativi di recapito (Abandon o perdita del blocco), il messaggio viene spostato automaticamente nella coda dei messaggi non recapitabili (DLQ). Gli operatori svuotano la DLQ per la diagnostica o per rielaborare i messaggi con una logica correttiva.

Azure Queue Storage è un servizio di accodamento più semplice e massivamente scalabile con un’interfaccia REST, ideale per il disaccoppiamento di base, scenari ad alto fan-out e carichi di lavoro sensibili ai costi. Fornisce una garanzia di recapito “at-least-once” (almeno una volta), un visibility timeout per nascondere i messaggi durante l’elaborazione e un TTL per messaggio (predefinito 7 giorni, configurabile, inclusa l’opzione di non scadenza). I singoli messaggi hanno dimensioni limitate e funzionalità come sessioni, transazioni, garanzie di ordinamento, rilevamento dei duplicati, sottocode dei messaggi non recapitabili e filtri avanzati non sono disponibili. Scegli Queue Storage per semplici lavori in background e per un throughput molto elevato a basso costo. Scegli Service Bus quando hai bisogno di routing sofisticato (topics/subscriptions), FIFO tramite sessioni, consegna pianificata, rinvio (deferral), transazioni tra entità, finestre di rilevamento dei duplicati, supporto AMQP o quando l’affidabilità e la governance dell’integrazione sono importanti. Un pattern comune consiste nel convogliare (fan in) eventi leggeri tramite Event Grid o Queue Storage e coordinare i comandi critici per il business e le transizioni di stato su Service Bus.

Hub di notifica: Routing delle notifiche push e gestione delle credenziali della piattaforma

Notification Hubs è un motore di notifiche push multipiattaforma che gestisce le registrazioni dei dispositivi su larga scala e instrada notifiche mirate verso Apple (APNs), Android (FCM), Windows (WNS) e altre piattaforme. Le applicazioni registrano i dispositivi utilizzando tag ed espressioni di tag, consentendo una selezione precisa del pubblico (ad esempio, user:42 AND region:emea OR topic:promotions). I template permettono di inviare un singolo payload localizzato che i renderer specifici della piattaforma espandono, riducendo la logica del server e abilitando la personalizzazione per singolo dispositivo con ramificazioni minime nel backend. Il modello Installation semplifica la gestione del ciclo di vita dei dispositivi incapsulando l’handle della piattaforma, i tag e i template in una singola risorsa per dispositivo.

La gestione delle credenziali della piattaforma è centrale per un recapito affidabile. Per APNs, caricare credenziali basate su certificato o su token (con Key ID, Team ID e token .p8) e scegliere endpoint di sandbox o di produzione per hub o namespace per separare gli ambienti. Per FCM, configurare le credenziali del server appropriate (per HTTP v1, usare un account di servizio Google con ambiti OAuth2). Per WNS, registrare l’app per ottenere il Package SID e il segreto client. Le credenziali vengono ruotate periodicamente; pianificare la rotazione e monitorare i canali di feedback per individuare handle di dispositivo non validi. Notification Hubs utilizza SAS per l’autenticazione a livello di hub dal server della propria app, mentre i ruoli di Azure AD proteggono le operazioni di gestione. Utilizzare convenzioni di tagging per partizionare app multi-tenant e regolare la velocità degli invii con push pianificati o in batch per rispettare le quote della piattaforma.

Scenario di un Problema Pratico

Starbucks sta implementando un’esperienza di ordinazione mobile globale che deve notificare i clienti quando gli ordini sono pronti, elaborare in modo affidabile i passaggi del flusso di lavoro dei baristi e analizzare la telemetria delle attrezzature per la manutenzione proattiva.

1. Collegare il ciclo di vita degli ordini basato su eventi con Event Grid

• Creare un topic personalizzato di Event Grid OrderEvents e pubblicare eventi di dominio discreti come OrderPlaced, PaymentAuthorized e OrderReady. Utilizzare percorsi del soggetto (subject) come /stores/{storeId}/orders/{orderId} per abilitare il filtraggio per prefisso per punto vendita. Configurare le sottoscrizioni: una verso un topic di Service Bus per l’elaborazione del flusso di lavoro e una verso una Azure Function per un arricchimento leggero. Event Grid viene scelto per il fan-out a bassa latenza, la normalizzazione dello schema (CloudEvents) e il filtraggio efficiente che evita invocazioni downstream non necessarie.

2. Coordinare il flusso di lavoro dei baristi con i topic e le sessioni di Service Bus

• Definire un topic di Service Bus Orders con sottoscrizioni per ogni fase di elaborazione (Preparation, Handoff), ciascuna con filtri di correlazione o SQL su eventType. Pubblicare comandi come messaggi con SessionId = {orderId} per garantire il FIFO per ogni ordine. I consumer utilizzano PeekLock con rinnovo automatico del blocco e Complete in caso di successo; in caso di errore transitorio, Abandon attiva un nuovo tentativo; in caso di errore persistente o messaggi poison (avvelenati), il Max delivery count li sposta nella DLQ per un’ispezione successiva. Il TTL sui messaggi specifici della fase previene il lavoro obsoleto dopo la chiusura del punto vendita. Service Bus viene scelto per la gestione dei comandi ordinata e affidabile, la gestione avanzata del completamento (settlement) e il pub/sub basato su regole.

3. Inserire e archiviare la telemetria delle attrezzature con Event Hubs

• Effettuare il provisioning di un Event Hub Telemetry con partizioni sufficienti per parallelizzare per deviceId e abilitare l’auto-inflate delle TU per assorbire i picchi. I gateway dei dispositivi inviano tramite AMQP-over-WebSockets per attraversare i proxy aziendali in modo efficiente. Utilizzare EventProcessorClient con checkpointing su Blob Storage per eseguire il rilevamento delle anomalie e l’alerting in tempo quasi reale. Abilitare Capture su ADLS Gen2 per archivi Avro immutabili che supportano analisi offline in Synapse. Event Hubs viene scelto per un’ingestion sostenuta e ad alta velocità con offset durevoli e una facile esportazione per il cold-path.

4. Indirizzare le notifiche push con Notification Hubs

• Registrare i dispositivi mobili utilizzando il modello Installation, taggando ciascuno con user:{userId}, store:{storeId} e tag di piattaforma. Caricare le credenziali del token APNs per iOS e l’account di servizio FCM per Android; separare gli hub di sviluppo e produzione per isolare credenziali e feedback. Quando arrivano gli eventi OrderReady, la Azure Function invia una singola notifica basata su template a Notification Hubs, indirizzata ai tag user:{userId} AND store:{storeId}. Notification Hubs viene scelto per il routing agnostico rispetto alla piattaforma, le espressioni di tag e la gestione centralizzata delle credenziali su scala globale.

5. Garantire osservabilità e resilienza

• Configurare il dead-lettering di Event Grid verso un container Blob per conservare gli eventi non recapitabili per audit e riesecuzione (replay). Monitorare le DLQ di Service Bus ed esporre un flusso di lavoro per l’operatore per analizzare (triage) e reinserire in coda i messaggi corretti. Tracciare il ritardo (lag) del consumer di Event Hubs tramite le metriche per validare il checkpointing ed eseguire lo scale-out dei processori quando il backlog aumenta. Questa combinazione fornisce durabilità end-to-end: recapito at-least-once (almeno una volta) con percorsi di riesecuzione per condizioni eccezionali, mantenendo il percorso nominale (happy path) veloce ed efficiente in termini di costi.

Questa architettura separa nettamente le responsabilità: Event Grid guida l’orchestrazione reattiva, Service Bus garantisce la correttezza e l’ordinamento del flusso di lavoro, Event Hubs gestisce la telemetria continua su larga scala e Notification Hubs recapita notifiche precise e specifiche della piattaforma ai clienti con una complessità minima del backend.

← Azure API Management · Tutti i domini · Caching →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Microsoft →