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'organizzazione.
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 gestione degli 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 usando 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
bus di servizio dispone di 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 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 utilizzare bus di servizio messaggi, è 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 set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.
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à.
- Microsoft Entra ID: Microsoft Entra ID è una piattaforma SaaS distribuita a livello globale e a disponibilità elevata. Per informazioni dettagliate sulla disponibilità garantita, vedere il contratto di servizio .
- Gestione API: Gestione API può essere distribuito in diverse configurazioni a disponibilità elevata, in base ai requisiti aziendali e alla tolleranza ai costi. Per una revisione completa delle opzioni, vedere Garantire Gestione API disponibilità e affidabilità. Per informazioni dettagliate sulla disponibilità garantita, vedere anche il contratto di servizio .
- App per la logica: l'archiviazione con ridondanza geografica è disponibile per 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 indicazioni. Per informazioni dettagliate sulla disponibilità garantita, vedere anche il 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 in 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, vedere Ripristino di emergenza geografico tra aree . Per informazioni dettagliate sulla disponibilità garantita, vedere anche il contratto di servizio .
- bus di servizio: bus di servizio Premium supporta il ripristino di emergenza geografico e le zone di disponibilità. La replica è disponibile per bus di servizio Standard. Per informazioni dettagliate sulla disponibilità garantita, vedere anche il contratto di servizio .
Sicurezza
La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.
Per proteggere bus di servizio, usare l'autenticazione di Microsoft Entra associata alle identità gestite. L'integrazione di Microsoft Entra per le risorse di bus di servizio fornisce il controllo degli accessi in base al ruolo di Azure per il controllo con granularità fine sull'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 l'ID Entra di Microsoft non è disponibile, è possibile usare la firma di accesso condiviso .Where Microsoft Entra ID 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 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.
- bus di servizio Premium può essere associato a un endpoint del servizio subnet di rete virtuale (VNet), proteggendo lo spazio dei nomi per accettare solo il traffico dalle reti virtuali autorizzate. Usare anche gli endpoint privati per bloccare il traffico della rete virtuale verso il traffico privato tramite collegamento privato.
- App per la logica Standard e App per la logica Premium possono essere configurate per accettare il traffico in ingresso tramite endpoint privati e per inviare il traffico in uscita tramite l'integrazione della rete virtuale.
- Gestione API offre diverse opzioni per proteggere l'accesso alle API e all'istanza 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 i costi per tutte le istanze di Gestione API quando sono in esecuzione. Se è stato eseguito un aumento delle prestazioni e non è necessario che questo livello di prestazioni venga ridotto manualmente o configurato automaticamente.
Per i carichi di lavoro di utilizzo leggero, prendere in considerazione il livello di consumo, ovvero un'opzione serverless a basso costo. Il livello a consumo viene fatturato per ogni 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.
bus di servizio code, argomenti e sottoscrizioni
bus di servizio code e sottoscrizioni supportano modelli push e pull tramite proxy per il recapito dei messaggi. Nel modello pull ogni richiesta di polling viene a consumo come azione. Anche con il polling lungo a 30 sec (impostazione predefinita), il costo può essere elevato. A meno che non sia necessario il recapito in tempo reale dei messaggi, è consigliabile usare il modello push proxy.
bus di servizio code sono incluse in tutti i livelli (livelli Basic, Standard e Premium). Mentre bus di servizio argomenti e sottoscrizioni 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'inserimento di eventi in domini o argomenti, corrispondenze avanzate, tentativi di recapito e chiamate di gestione. L'utilizzo di un massimo di 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 Basic Enterprise Integration fornisce indicazioni sui modelli DevOps, allineati al pilastro Dell'eccellenza operativa di Well-Architected Framework.
L'automazione delle operazioni di ripristino il più possibile è un componente integrale dell'eccellenza operativa. Tenendo presente l'automazione, è possibile combinare Monitoraggio log di Azure con Automazione di Azure per automatizzare il failover delle risorse bus di servizio. Per un esempio di logica di automazione per avviare un failover, vedere il diagramma nella documentazione del flusso di failover.
Efficienza prestazionale
L'efficienza delle prestazioni è la capacità di dimensionare il carico di lavoro per 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à. Per una revisione dei vantaggi del livello Premium, vedere la documentazione bus di servizio livelli di messaggistica Premium e Standard. Vedere anche la documentazione sulle funzionalità di scalabilità automatica per informazioni sulla configurazione della scalabilità automatica delle unità di messaggistica.
Altre raccomandazioni per bus di servizio sono disponibili in Procedure consigliate per migliorare le prestazioni usando bus di servizio Messaggistica.
Passaggi successivi
Per altre informazioni, vedere la documentazione di 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
- bus di servizio funzionalità di scalabilità automatica
- Procedure consigliate per i miglioramenti delle prestazioni tramite bus di servizio Messaggistica