Questa architettura di esempio è basata sull'architettura di integrazione aziendale di base . Estende tale architettura per illustrare come integrare i sistemi back-end aziendali, usando broker di messaggi ed eventi per separare i servizi per una maggiore scalabilità e affidabilità. Assicurarsi di avere familiarità con la progettazione e i componenti usati nell'architettura di integrazione di base. Fornisce informazioni fondamentali sui componenti principali di questa architettura, che non verranno riprodotti qui.
Architettura
I sistemi back-end a cui si fa riferimento in questa progettazione possono includere sistemi SaaS (Software as a Service), servizi di Azure e servizi Web esistenti nell'azienda.
Scaricare un file di Visio di questa architettura.
Flusso di lavoro
L'architettura illustrata in questo articolo si basa su un'architettura più semplice illustrata nell'articolo Integrazione aziendale di base. Questa architettura usa App per la logica per orchestrare i flussi di lavoro direttamente con i sistemi back-end e Gestione API per creare cataloghi di API.
Questa versione dell'architettura aggiunge due componenti che contribuiscono a rendere il sistema più affidabile e scalabile:
bus di servizio di Azure. Il bus di servizio è un broker di messaggi sicuro e affidabile.
Griglia di eventi di Azure. Griglia di eventi è un servizio di routing di eventi. Usa un modello di eventi di pubblicazione/sottoscrizione (pub/sub).
La comunicazione asincrona tramite un broker di messaggi offre i vantaggi seguenti rispetto all'esecuzione di chiamate dirette e sincrone ai servizi back-end:
- Fornisce il livellamento del carico per gestire i picchi di carichi di lavoro usando lo Schema di livellamento del carico basato sulle code.
- Fornisce la trasmissione di messaggi a più consumer tramite il modello Publisher-Subscriber.
- Tiene traccia in modo affidabile dello stato di avanzamento dei flussi di lavoro a esecuzione prolungata che coinvolgono più fasi o più applicazioni.
- Consente di disaccoppiare le applicazioni.
- Si integra con i sistemi di messaggistica esistenti.
- Consente di accodare il lavoro quando un sistema back-end non è disponibile.
Griglia di eventi consente ai vari componenti del sistema di reagire agli eventi man mano che si verificano, anziché basarsi su attività pianificate o di polling. Come per una coda di messaggi e argomenti, consente di separare applicazioni e servizi. Un'applicazione o un servizio può pubblicare eventi e i sottoscrittori interessati riceveranno una notifica. È possibile aggiungere nuovi sottoscrittori senza aggiornare il mittente.
Molti servizi di Azure seguenti supportano l'invio degli eventi a Griglia di eventi. Ad esempio, un'app per la logica può essere in ascolto di un evento quando nuovi file vengono aggiunti a un archivio BLOB. Questo modello consente flussi di lavoro reattivi, in cui il caricamento di un file o l'inserimento di un messaggio in coda dà il via a una serie di processi. I processi possono essere eseguiti in parallelo o in una sequenza specifica.
Consigli
A questa architettura si applicano i consigli descritti in Integrazione aziendale di base.
Bus di servizio
Il bus di servizio ha due modalità di recapito, push pull o proxy. Nel modello pull il ricevitore esegue continuamente il polling di nuovi messaggi. Il polling può risultare inefficiente, soprattutto se sono presenti molte code che ricevono alcuni messaggi o se è presente molto tempo tra i messaggi. Nel modello push proxy il bus di servizio invia un evento tramite Griglia di eventi quando sono presenti nuovi messaggi. Il ricevitore sottoscrive l'evento. Quando viene attivato l'evento, il ricevitore eseguire il pull del successivo batch di messaggi dal bus di servizio.
Quando si crea un'app per la logica per l'utilizzo dei messaggi del bus di servizio, è consigliabile usare il modello push proxy con l'integrazione di Griglia di eventi. Spesso è più efficiente in termini di costi, perché l'app per la logica non deve eseguire il polling del bus di servizio. Per altre informazioni, vedere Panoramica dell'integrazione del bus di servizio di Azure in Griglia di eventi. Attualmente, è necessario il livello Premium del bus di servizio per le notifiche di Griglia di eventi.
Usare PeekLock per accedere a un gruppo di messaggi. Con PeekLock, l'app per la logica può eseguire i passaggi per convalidare ogni messaggio prima di completarlo o abbandonarlo. Questo approccio protegge dalla perdita accidentale dei messaggi.
Griglia di eventi
Quando viene attivato un trigger di Griglia di eventi, significa che si è verificato almeno un evento. Ad esempio, quando un'app per la logica riceve un trigger di Griglia di eventi per un messaggio del bus di servizio, dovrebbe presumere che diversi messaggi potrebbero essere disponibili per l'elaborazione.
Considerazioni
Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.
Affidabilità
L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere Panoramica del pilastro dell'affidabilità.
- Azure AD: Azure AD è una piattaforma SaaS distribuita a livello globale e a disponibilità elevata. Per informazioni dettagliate sulla disponibilità garantita, fare riferimento al contratto di servizio.
- Gestione API: Gestione API possono essere distribuite in diverse configurazioni a disponibilità elevata, in base ai requisiti aziendali e alla tolleranza ai costi. Per una revisione completa delle opzioni, vedere Garantire la disponibilità e l'affidabilità Gestione API. Per informazioni dettagliate sulla disponibilità garantita, fare riferimento anche al contratto di servizio.
- App per la logica: L'archiviazione con ridondanza geografica è disponibile per Le app per la logica nel livello piano a consumo. Per informazioni sulla progettazione di una soluzione di continuità aziendale e ripristino di emergenza, vedere le linee guida. Per informazioni dettagliate sulla disponibilità garantita, fare riferimento anche al contratto di servizio.
- Griglia di eventi: Le definizioni delle risorse di Griglia di eventi per argomenti, argomenti di sistema, domini e sottoscrizioni di eventi e dati degli eventi vengono replicate automaticamente tra tre zone di disponibilità (se disponibili) nell'area. Quando si verifica un errore in una delle zone di disponibilità, le risorse di Griglia di eventi eseguono automaticamente il failover in un'altra zona di disponibilità senza alcun intervento umano. Per indicazioni sulla progettazione di una soluzione di ripristino di emergenza per il failover in un'altra area, fare riferimento al ripristino di emergenza geografico tra aree . Per informazioni dettagliate sulla disponibilità garantita, fare riferimento anche al contratto di servizio.
- Bus di servizio: Il bus di servizio Premium supporta il ripristino di emergenza geografico e zone di disponibilità. La replica è disponibile per il bus di servizio Standard. Per informazioni dettagliate sulla disponibilità garantita, fare riferimento anche al contratto di servizio.
Sicurezza
La sicurezza offre garanzie contro attacchi intenzionali e l'abuso dei dati e dei sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.
Per proteggere il bus di servizio, usare l'autenticazione di Azure Active Directory (Azure AD) associata alle identità gestite. L'integrazione di Azure AD per le risorse del bus di servizio fornisce il controllo degli accessi in base al ruolo di Azure per un controllo con granularità fine dell'accesso di un client alle risorse. È possibile usare il controllo degli accessi in base al ruolo di Azure per concedere autorizzazioni a un'entità di sicurezza, che può essere un utente, un gruppo o un'entità servizio dell'applicazione (in questo caso un'identità gestita).
Se Azure AD non è disponibile, è possibile usare la firma di accesso condiviso.Where Azure AD isn't available, you can use shared access signature (SAS). È possibile usare l'autenticazione basata sulla firma di accesso condiviso per concedere agli utenti l'accesso alle risorse del bus di servizio con diritti specifici.
Se è necessario esporre una coda o un argomento del bus di servizio come endpoint HTTP, ad esempio per pubblicare nuovi messaggi, usare Gestione API per proteggere la coda front-end. L'endpoint può quindi essere protetto tramite certificati o autenticazione OAuth, a seconda delle esigenze. Il modo più semplice per proteggere un endpoint è quello di usare un'app per la logica con un trigger di richiesta/risposta HTTP come intermediario.
Il servizio Griglia di eventi consente di proteggere il recapito dell'evento tramite un codice di convalida. Se si usa App per la logica per gestire l'evento, la convalida viene eseguita automaticamente. Per altre informazioni, vedere Event Grid security and authentication (Sicurezza e autenticazione di Griglia di eventi).
Sicurezza di rete
La sicurezza di rete deve essere considerata in tutta la progettazione.
- Il bus di servizio Premium può essere associato a un endpoint di servizio della subnet di rete virtuale (VNet), proteggendo lo spazio dei nomi per accettare solo il traffico dalle reti virtuali autorizzate. Inoltre, usare gli endpoint privati per bloccare il traffico della rete virtuale al traffico privato tramite collegamento privato.
- App per la logica Le app per la logica Standard e Premium possono essere configurate per accettare il traffico in ingresso attraverso endpoint privati e per inviare il traffico in uscita tramite l'integrazione della rete virtuale.
- Gestione API offre diverse opzioni per proteggere l'accesso all'istanza e alle API di Gestione API usando una rete virtuale di Azure. Per una revisione approfondita delle opzioni, vedere la documentazione Usare una rete virtuale con Azure Gestione API. Sono supportati anche gli endpoint privati.
Ottimizzazione dei costi
L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.
In linea generale, usare il calcolatore dei prezzi di Azure per stimare i costi. Ecco alcune altre considerazioni.
Gestione API
Vengono addebitati addebiti per tutte le istanze di Gestione API durante l'esecuzione. Se si è ridimensionato e non è necessario che il livello di prestazioni sia stato ridimensionato manualmente o configurato automaticamente.
Per i carichi di lavoro di utilizzo leggeri, prendere in considerazione il livello di consumo, ovvero un'opzione serverless a basso costo. Il livello di consumo viene fatturato per chiamata API, mentre gli altri livelli vengono fatturati all'ora.
App per la logica
App per la logica funziona come modello senza server. La fatturazione viene calcolata in base all'esecuzione del connettore e dell'azione. Per altre informazioni, vedere Prezzi di App per la logica.
Code, argomenti e sottoscrizioni del bus di servizio
Le code e le sottoscrizioni del bus di servizio supportano modelli push e pull per la distribuzione di messaggi. Nel modello pull ogni richiesta di polling viene misurata come azione. Anche con il polling lungo a 30 secondi (impostazione predefinita), il costo può essere elevato. A meno che non sia necessario il recapito in tempo reale dei messaggi, prendere in considerazione l'uso del modello push proxied.
Le code del bus di servizio sono incluse in tutti i livelli (livelli Basic, standard e Premium). Mentre gli argomenti e le sottoscrizioni del bus di servizio sono disponibili nei livelli standard e Premium. Per altre informazioni, vedere prezzi bus di servizio di Azure.
Griglia di eventi
Griglia di eventi usa un modello senza server. La fatturazione viene calcolata in base al numero di operazioni (esecuzioni di eventi). Le operazioni includono l'ingresso di eventi in domini o argomenti, corrispondenze avanzate, tentativi di recapito e chiamate di gestione. L'utilizzo di fino a 100.000 operazioni è gratuito.
Per altre informazioni, vedere Prezzi di Griglia di eventi.
Per altre informazioni, vedere la sezione sui costi in Microsoft Azure Well-Architected Framework.
Eccellenza operativa
L'architettura di riferimento di base per l'integrazione aziendale fornisce indicazioni sui modelli DevOps, che si allineano al pilastro dell'eccellenza operativa di Well-Architected Framework.
L'automazione delle operazioni di ripristino il più possibile è un componente integrale dell'eccellenza operativa. Con l'automazione, è possibile combinare Monitoraggio log di Azure con Automazione di Azure per automatizzare il failover delle risorse del bus di servizio. Vedere il diagramma nella documentazione del flusso di failover per un esempio di logica di automazione per avviare un failover.
Efficienza delle prestazioni
L'efficienza delle prestazioni è la capacità di ridimensionare il carico di lavoro soddisfare in modo efficiente le richieste poste dagli utenti. Per altre informazioni, vedere Panoramica dell'efficienza delle prestazioni.
Il piano Premium del bus di servizio consente di aumentare il numero di unità di messaggistica per offrire una maggiore scalabilità. Vedere la documentazione dei livelli di messaggistica Premium e Standard del bus di servizio per una revisione dei vantaggi del livello Premium. Vedere anche la documentazione sulla scalabilità automatica delle funzionalità per informazioni sulla configurazione della scalabilità automatica delle unità di messaggistica.
Altre raccomandazioni per il bus di servizio sono disponibili in Procedure consigliate per i miglioramenti delle prestazioni usando la messaggistica del bus di servizio.
Passaggi successivi
Per altre informazioni, vedere la documentazione del bus di servizio:
- Panoramica dell'integrazione del bus di servizio di Azure in Griglia di eventi
- Livelli di messaggistica Standard e Premium del bus di servizio
- Funzionalità di scalabilità automatica del bus di servizio
- Procedure consigliate per i miglioramenti delle prestazioni usando la messaggistica del bus di servizio