Microsoft AZ-305: Architettura di integrazione e messaggistica — Guida allo studio

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

Fa parte della Microsoft Azure Solutions Architect Expert AZ-305 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

L’architettura di integrazione e messaggistica su Azure si basa sulla selezione del servizio corretto per la semantica di spostamento di comandi, eventi e dati; sulla progettazione per l’affidabilità, l’ordinamento e la scalabilità; e sull’integrazione sicura di sistemi ibridi. I componenti fondamentali includono Azure Service Bus per la messaggistica enterprise con broker avanzati, Azure Event Grid per il routing reattivo degli eventi, Azure Event Hubs per l’ingestion di flussi di dati ad alta velocità e Storage Queues per l’accodamento semplice. A questi si affiancano Azure Logic Apps per l’automazione dei processi, API Management per la governance e la developer experience, Azure Data Factory per ETL/ELT, Azure Relay per la connettività on-premise compatibile con i firewall e Azure Notification Hubs per le notifiche push per dispositivi mobili. Una progettazione solida utilizza il servizio giusto per ogni compito, modella esplicitamente i contratti e le modalità di errore e applica pattern di orchestrazione o coreografia dove appropriato.

Messaggistica ed Eventing su Azure

Azure Service Bus è il broker enterprise per comandi e flussi di lavoro che richiedono consegna ordinata, transazioni, FIFO all’interno di gruppi e gestione dei messaggi non recapitabili (dead-letter). Le code (Queues) forniscono una messaggistica point-to-point tra un produttore e un gruppo di consumer in competizione. I topic abilitano il modello pub/sub con sottoscrizioni multiple e indipendenti che possono filtrare e instradare i messaggi usando filtri e azioni simili a SQL. Le sessioni di messaggi (Message sessions) raggruppano messaggi correlati sotto un sessionId, abilitando l’elaborazione FIFO e stateful per ogni gruppo; il blocco della sessione (session lock) garantisce che un singolo consumer elabori una sessione alla volta. Le code di messaggi non recapitabili (Dead-letter queues) catturano i “poison message” (messaggi non elaborabili) quando viene superato il numero massimo di tentativi di consegna, il TTL scade o quando vengono esplicitamente contrassegnati come non recapitabili, permettendo la quarantena e l’ispezione successiva; ogni coda o sottoscrizione ha una sottocoda $DeadLetterQueue. Le transazioni consentono operazioni atomiche di invio/ricezione/completamento tra entità all’interno dello stesso namespace, garantendo, ad esempio, che un messaggio venga completato solo se i messaggi successivi vengono inviati con successo (il meccanismo “send-via” supporta flussi di lavoro tra entità diverse).

Azure Event Grid è un router di eventi completamente gestito per pattern reattivi basati su push. Utilizza lo schema nativo di Event Grid o CloudEvents 1.0. Le sottoscrizioni agli eventi (Event subscriptions) hanno come destinazione endpoint come Functions, Logic Apps, Service Bus, Event Hubs, WebHooks e Storage Queues, con filtri sull’oggetto (subject) e filtri avanzati per ridurre il “rumore”. La consegna viene ritentata con un backoff esponenziale; le sottoscrizioni supportano una policy di tentativi configurabile (numero massimo di tentativi di consegna e tempo di vita dell’evento) e possono inviare gli eventi non recapitabili a un account di Storage (dead-lettering). La convalida tramite handshake protegge gli endpoint WebHook e le identità gestite (managed identities) semplificano la pubblicazione e la consegna agli endpoint di Azure.

Azure Event Hubs acquisisce telemetria e dati in streaming su larga scala tramite log partizionati. Le partizioni forniscono parallelismo e ordinamento all’interno di una singola partizione; scegliere una chiave di partizione (partition key) per mantenere ordinati gli eventi correlati. Il numero di partizioni determina la scalabilità e non può essere ridotto dopo la creazione, quindi è necessario dimensionarlo per la velocità effettiva (throughput) futura. I gruppi di consumer (Consumer groups) forniscono viste indipendenti del flusso di eventi per diverse applicazioni senza interferire con gli offset degli altri. La funzionalità Capture scarica i dati in modo persistente su Azure Blob Storage o Data Lake Storage quasi in tempo reale, basandosi su finestre temporali o di dimensione, tipicamente in formato Avro, abilitando l’analisi batch senza impattare l’ingestion. Lo Schema Registry integrato memorizza schemi Avro/JSON con policy di versioning e compatibilità, consentendo a produttori e consumatori di convalidare e far evolvere i contratti in modo sicuro.

Le Storage Queues offrono una consegna “at-least-once” (almeno una volta) semplice ed economica, con timeout di invisibilità e una gestione di base dei messaggi non recapitabili tramite il TTL del messaggio e la gestione dei “poison message” a livello applicativo. Mancano di transazioni, sessioni e routing avanzato, ma eccellono nel disaccoppiamento di base e in scenari di fan-out su larga scala a basso costo.

Quando scegliere quale servizio:

Usare Service Bus per comandi, flussi di lavoro e scenari di integrazione che richiedono FIFO (tramite sessioni), transazioni, rinvio (deferral), rilevamento dei duplicati e auditing dei messaggi non recapitabili.
Usare Event Grid per notifiche leggere, basate su push e con fan-out provenienti da servizi Azure o app personalizzate, con filtraggio granulare e reazioni quasi in tempo reale.
Usare Event Hubs per l’ingestion di telemetria e log in streaming ad alta velocità, con consumer indipendenti e analisi a valle.
Usare Storage Queues per un semplice disaccoppiamento produttore/consumatore dove le funzionalità avanzate del broker non sono necessarie e la semplicità dei costi è fondamentale.

Integrazione, API e Connettività Ibrida

Azure Logic Apps fornisce l’automazione di flussi di lavoro gestiti con centinaia di connettori. Nel modello Consumption (multi-tenant), si paga per azione con scalabilità automatica e connettori multi-tenant; ideale per carichi di lavoro intermittenti (bursty). Il modello Standard (single-tenant) viene eseguito sul runtime di Functions con flussi di lavoro stateful/stateless, throughput più elevato, connettori personalizzati e connettori integrati eseguiti in-process, containerizzazione, sviluppo locale e integrazione con VNET/private endpoint; ideale per l’isolamento a livello enterprise e una capacità prevedibile. L’Integration Service Environment (ISE) è uno “stamp” dedicato legacy per il networking privato e la località dei dati; i nuovi progetti generalmente preferiscono Logic Apps Standard con integrazione VNET o la distribuzione su App Service Environment v3.

Azure API Management (APIM) fornisce un livello di astrazione e governance per le API. Le policy si applicano nelle fasi di inbound, backend e outbound per imporre requisiti trasversali (cross-cutting concerns) come validate-jwt, rate-limit-by-key, quota, set-header, retry, cache-lookup/store e set-backend-service per il routing dinamico. I Products raggruppano una o più API, aggregano il comportamento delle policy e sono pubblicabili a gruppi specifici. Le Subscriptions emettono chiavi per singolo consumer o per prodotto per misurare e controllare l’accesso; le chiavi possono essere ruotate e associate a quote. Il developer portal abilita flussi di lavoro self-service per la scoperta, la documentazione, il testing (try-it) e l’onboarding, mentre il self-hosted gateway consente implementazioni ibride control plane/edge per ambienti on-premise o altri cloud.

Azure Relay abilita la connettività in entrata (inbound) verso servizi on-premise senza la necessità di aprire porte firewall in entrata. Le Hybrid Connections utilizzano WebSockets su TLS 443 per comunicazioni socket bidirezionali generiche, avviate in uscita (outbound) dall’ambiente on-premise e dai client verso il Relay, utili per HTTP e protocolli arbitrari incapsulati su WebSockets. WCF Relay espone endpoint WCF on-premise (NetTcp/HTTP) attraverso il relay con sicurezza a livello di trasporto o di messaggio e accesso basato su claims; è ideale per servizi WCF esistenti che necessitano di un’esposizione sicura e compatibile con i firewall.

Azure Notification Hubs è un broker di notifiche push multipiattaforma che astrae i sistemi di notifica delle piattaforme (APNs per iOS, FCM per Android, WNS per Windows, ADM per Amazon). I backend registrano dispositivi o installazioni con tag e template per indirizzare e personalizzare le notifiche su larga scala. Sono richieste le credenziali della piattaforma per ogni PNS: chiave p8 o certificato APNs, chiave/credenziali del server FCM, package SID/secret WNS. Notification Hubs gestisce il fan-out, il throttling e la gestione dei token, in modo che il codice dell’applicazione rimanga agnostico rispetto al PNS.

Spostamento Dati e Analisi in Streaming

Azure Data Factory (ADF) orchestra l’integrazione dei dati tra ambienti ibridi. Gli Integration Runtimes (IRs) ospitano la capacità di calcolo per le attività: Azure IR per la copia serverless e i data flow all’interno di Azure, Self-hosted IR per lo spostamento/calcolo dei dati all’interno di reti private senza aprire porte in entrata, e Azure-SSIS IR per eseguire il lift-and-shift di pacchetti SSIS su cluster gestiti. Le Pipelines orchestrano le attività con un flusso di controllo (dipendenze, cicli, diramazioni, trigger) e parametrizzazione per il riutilizzo. I Mapping Data Flows forniscono trasformazioni code-free basate su Spark su larga scala, con gestione dello schema drift e controlli di partizionamento; da utilizzare quando le trasformazioni sono complesse ma si desidera una capacità di calcolo gestita. I Linked services definiscono i metadati di connessione e le credenziali per le origini (sources), le destinazioni (sinks) e la capacità di calcolo; i dataset e le origini/destinazioni dei data flow fanno riferimento a questi, abilitando il riutilizzo sicuro e il controllo degli accessi basato sui ruoli (RBAC).

Event Hubs si integra con gli strumenti di analisi tramite la funzione Capture su storage persistente; successivamente, Azure Synapse o Databricks possono elaborare i file Avro in micro-batch. Schema Registry semplifica la deserializzazione e l’evoluzione negli processi di streaming centralizzando i contratti, evitando una tipizzazione implicita e fragile tra producer e consumer.

Affidabilità e Pattern Event-Driven

La progettazione per l’affidabilità inizia con una gestione esplicita dei fallimenti. Service Bus fornisce code di messaggi non recapitabili (dead-letter queue, DLQ) per ogni entità; i consumer dovrebbero monitorare ed eseguire il triage delle DLQ, opzionalmente inoltrando automaticamente i messaggi a code di analisi. Utilizzare il rilevamento dei duplicati e handler idempotenti per evitare la doppia elaborazione. Sfruttare le transazioni per finalizzare atomicamente le ricezioni e inviare messaggi in uscita (outbox), e usare le sessioni per l’elaborazione ordinata per entità di business, scalando tra le sessioni. La policy di re-tentativo di Event Grid utilizza un backoff esponenziale con limiti configurabili; configurare il dead-lettering su Storage per l’auditabilità e costruire strumenti di riesecuzione (replay). Event Hubs garantisce una consegna at-least-once (almeno una volta); il checkpointing tramite SDK (o trigger di Azure Functions) assicura il tracciamento del progresso per partizione/gruppo di consumer. Storage Queues si basa su timeout di visibilità e pattern di messaggi non elaborabili (poison message) che si implementano esplicitamente.

L’architettura event-driven utilizza tipicamente la coreografia o l’orchestrazione. La coreografia distribuisce il coordinamento tra i servizi che reagiscono agli eventi dei loro pari. È debolmente accoppiata, scalabile e resiliente a fallimenti parziali, ma può diventare difficile da visualizzare e governare, e le compensazioni sono disperse. L’orchestrazione centralizza il controllo del flusso in un orchestratore come Azure Durable Functions, Logic Apps o un motore di workflow, migliorando l’osservabilità, la logica di timeout/compensazione e i passaggi con intervento umano (human-in-the-loop) al costo di un accoppiamento più stretto con l’orchestratore. Il pattern saga implementa transazioni a lunga durata e multi-step con azioni di compensazione invece di commit a due fasi. Nella coreografia, ogni servizio ascolta gli eventi di dominio ed emette compensazioni secondo necessità; nell’orchestrazione, l’orchestratore invoca attività e attiva compensazioni in caso di fallimento o timeout. Su Azure, si implementano le saga utilizzando Durable Functions (orchestrazione stateful, re-tentativi, timeout, pattern di compensazione) con Service Bus per la consegna affidabile dei comandi, o con Logic Apps Standard per workflow aziendali robusti e connettori integrati.

Scenario Pratico del Problema

Contoso Retail modernizza l’elaborazione degli ordini che coinvolge un ERP on-premise, un sito di e-commerce, app mobili e sistemi di analytics a valle. La soluzione deve supportare notifiche ai partner, analisi della telemetria in tempo reale, accesso sicuro on-premise e notifiche push su mobile, con un ordinamento rigoroso e compensazioni per pagamenti e inventario.

Ingestione e workflow dei comandi

Utilizzare i topic di Azure Service Bus per i comandi degli ordini. Le sottoscrizioni segmentano l’elaborazione (Pagamenti, Inventario, Spedizione). Abilitare le sessioni di messaggi basate sulla chiave OrderId per garantire l’ordine FIFO per singolo ordine e la concorrenza singola. Motivazione: Service Bus fornisce sessioni, transazioni e dead-lettering necessari per workflow di business ordinati e affidabili.

Orchestrazione e compensazioni

Implementare una saga con Azure Durable Functions. Le attività chiamano il gateway di pagamento, riservano l’inventario e creano la spedizione; le compensazioni rimborsano o riapprovvigionano in caso di fallimento. Utilizzare trigger e output di Service Bus all’interno di ambiti transazionali per completare atomicamente i messaggi in arrivo e pubblicare i passaggi successivi. Motivazione: L’orchestrazione centralizzata semplifica i timeout, i re-tentativi e le compensazioni, preservando l’affidabilità del broker.

Notifiche event-driven

Pubblicare eventi di dominio (OrderPlaced, OrderShipped) su topic personalizzati di Azure Event Grid. I partner e le app interne si sottoscrivono con filtri basati sul prefisso del soggetto. Configurare il dead-lettering su un account di Storage e una policy di re-tentativo con un numero limitato di tentativi. Motivazione: Event Grid offre una distribuzione push a bassa latenza con filtri granulari e audit tramite dead-letter per un ampio fan-out.

Streaming di telemetria e analytics

Inviare la telemetria dei clickstream e delle app ad Azure Event Hubs con 8 partizioni basate sulla chiave della sessione utente. Abilitare la funzione Capture su Data Lake Storage ogni 5 minuti o 100 MB. Registrare gli schemi Avro in Schema Registry e imporre la compatibilità degli schemi. Motivazione: Event Hubs scala l’ingestione indipendentemente dai consumer; Capture disaccoppia gli analytics; Schema Registry mantiene la disciplina dei contratti.

Integrazione dei dati

Utilizzare Azure Data Factory con un Self-hosted Integration Runtime on-premise per estrarre i dati dall’ERP in modo sicuro, e un Azure IR per depositare i dati curati in Synapse. Costruire pipeline e mapping data flow per l’elaborazione SCD (Slowly Changing Dimension) e l’arricchimento con i file di Event Hubs Capture. Motivazione: ADF orchestra lo spostamento e le trasformazioni di dati ibridi con calcolo gestito e connessioni governate tramite linked services.

API e governance dei partner

Esponi tutti gli endpoint rivolti ai partner con Azure API Management. Esporre le API per lo stato degli ordini e la registrazione dei webhook. Applicare policy: validate-jwt per i token emessi dai partner, rate-limit-by-key per limitazioni di velocità più severe per i partner, rewrite/set-backend-service per instradare le chiamate a Logic Apps esistenti senza modifiche al codice. Pubblicare un prodotto per i partner che richieda sottoscrizioni e chiavi; eseguire l’onboarding tramite il portale per sviluppatori. Motivazione: APIM impone la sicurezza, il throttling e fornisce un onboarding self-service senza toccare la logica di backend.

Automazione del workflow e connettori

Utilizzare Azure Logic Apps Standard per l’automazione di back-office (es. inviare email, aggiornare Dynamics) con connettori integrati e integrazione VNET. Motivazione: Le prestazioni single-tenant, la connettività privata e i connettori di livello enterprise semplificano l’integrazione con app SaaS e line-of-business.

Connettività ibrida

Esporre selettivamente i servizi ERP on-premise tramite Azure Relay WCF Relay per gli endpoint WCF esistenti e Hybrid Connections per applicazioni HTTP/WebSocket leggere, evitando modifiche al firewall in ingresso. Motivazione: Relay fornisce una connettività sicura, avviata in uscita, senza la complessità di una VPN.

Push su mobile

Inviare aggiornamenti sulla spedizione tramite Azure Notification Hubs utilizzando tag per la segmentazione per dispositivo/utente e template per la localizzazione. Configurare le credenziali dei token APNs e le chiavi FCM. Motivazione: Notification Hubs astrae le differenze dei PNS (Platform Notification Service) e scala la consegna delle notifiche push.

Questo design associa ogni requisito a servizi specifici: Service Bus per comandi affidabili, Durable Functions per saga orchestrate, Event Grid per notifiche push, Event Hubs + Capture + Schema Registry per analytics in streaming, ADF per ETL/ELT ibridi, APIM per la governance, Logic Apps per l’automazione aziendale, Relay per l’accesso on-premise e Notification Hubs per il coinvolgimento su mobile.

← Architettura della sicurezza e Zero Trust · Tutti i domini · Monitoraggio →

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