Questa architettura si basa sull'architettura di integrazione aziendale di base, ma include come integrare i sistemi back-end aziendali. Questa architettura usa broker messaggi ed eventi per separare i servizi per una maggiore scalabilità e affidabilità. Assicurarsi di avere familiarità con la progettazione e i componenti nell'architettura di integrazione di base. Questi elementi forniscono informazioni fondamentali sui componenti principali di questa architettura.
Architettura
I sistemi back-end a cui fa riferimento questa progettazione includono sistemi SaaS (Software as a Service), servizi di Azure, servizi basati su messaggi e servizi Web esistenti nell'azienda.
Scaricare un file di Visio di questa architettura.
Dettagli dello scenario
L'architettura precedente si basa sull'architettura di integrazione aziendale di base più semplice che usa App per la logica di Azure per orchestrare i flussi di lavoro direttamente con i sistemi back-end e usa Azure 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 è un broker di messaggi sicuro e affidabile.
Griglia di eventi di Azure è un servizio di routing eventi. Usa un modello di pubblicazione e sottoscrizione di eventi.
Questa architettura usa la comunicazione asincrona tramite un broker di messaggi anziché effettuare chiamate dirette e sincrone ai servizi back-end. La comunicazione asincrona offre i vantaggi seguenti:
Usa il modello di livellamento del carico basato su coda per gestire i burst nei carichi di lavoro tramite il livellamento del carico
Usa il modello Publisher-Subscriber in modo da poter trasmettere messaggi a più consumer
Tiene traccia dello stato di avanzamento dei flussi di lavoro a esecuzione prolungata in modo affidabile, anche quando comportano più passaggi o più applicazioni
Aiuta a disaccoppiare le applicazioni
Si integra con sistemi basati su messaggi esistenti
Consente di accodare i messaggi quando un sistema back-end non è disponibile
Usare Griglia di eventi in modo che vari componenti del sistema possano reagire agli eventi quando si verificano, anziché basarsi sul polling o sulle attività pianificate. Analogamente a una coda di messaggi e argomenti, Griglia di eventi consente di disaccoppiare applicazioni e servizi. Se un'applicazione o un servizio pubblica eventi, tutti i sottoscrittori interessati ricevono 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 crea flussi di lavoro reattivi in cui il caricamento di un file o l'inserimento di un messaggio in una coda avvia una serie di processi. I processi possono essere eseguiti in parallelo o in una sequenza specifica.
Consigli
Prendere in considerazione i consigli seguenti. Per altre raccomandazioni, vedere Architettura di integrazione aziendale di base.
Bus di servizio
bus di servizio ha due modelli di recapito, il modello pull e il modello push proxied:
Modello pull: il ricevitore esegue continuamente il polling dei nuovi messaggi. Se è necessario gestire più code e tempi di polling, il polling potrebbe risultare inefficiente. Tuttavia, questo modello può semplificare l'architettura perché rimuove componenti aggiuntivi e hop dati.
Modello push con proxy: il ricevitore inizialmente sottoscrive un tipo di evento specifico in un argomento di Griglia di eventi. Quando è disponibile un nuovo messaggio, bus di servizio genera e invia un evento tramite Griglia di eventi. Questo evento attiva quindi il ricevitore per eseguire il pull del batch successivo di messaggi da bus di servizio. Questo modello consente ai sistemi di ricevere messaggi quasi in tempo reale, ma senza usare risorse per eseguire continuamente il polling dei nuovi messaggi. Questa architettura usa componenti aggiuntivi che è necessario distribuire, gestire e proteggere.
Quando si crea un flusso di lavoro di App per la logica Standard che utilizza bus di servizio messaggi, è consigliabile usare i trigger del connettore bus di servizio predefiniti. Il connettore predefinito attiva la maggior parte della configurazione del modello pull senza aggiungere costi aggiuntivi. Questa funzionalità offre il giusto equilibrio tra costi, gestione della superficie di attacco e sicurezza perché il connettore esegue continuamente cicli all'interno del motore di runtime di App per la logica. Per altre informazioni, vedere bus di servizio trigger del connettore predefiniti.
Usare la modalità 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 impedisce la perdita accidentale di 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 ottiene un trigger di Griglia di eventi per un messaggio di bus di servizio, potrebbero essere disponibili diversi messaggi da elaborare.
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 maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'affidabilità.
Microsoft Entra ID è una piattaforma SaaS distribuita a livello globale e a disponibilità elevata.
È possibile distribuire Gestione API in diverse configurazioni a disponibilità elevata, in base ai requisiti aziendali e alla tolleranza ai costi. Per altre informazioni, vedere Garantire Gestione API disponibilità e affidabilità.
Il livello a consumo di App per la logica supporta l'archiviazione con ridondanza geografica. Per altre informazioni, vedere Continuità aziendale e ripristino di emergenza per App per la logica.
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 le zone di disponibilità in un'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 altre informazioni, vedere Ripristino di emergenza tra aree e continuità aziendale.
bus di servizio Premium supporta il ripristino di emergenza geografico e le zone di disponibilità. bus di servizio Standard supporta la replica.
Per informazioni sui dettagli sulla disponibilità garantita di ogni servizio, vedere Contratti di servizio per Servizi online.
Sicurezza
La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per la sicurezza.
Per proteggere le bus di servizio, associare l'autenticazione di Microsoft Entra alle identità gestite. L'integrazione di Microsoft Entra ID per le risorse di bus di servizio fornisce il controllo degli accessi in base al ruolo di Azure per il controllo granulare 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, ad esempio un utente, un gruppo o un'entità servizio dell'applicazione. L'entità servizio dell'applicazione in questo scenario è un'identità gestita.
Se non è possibile usare Microsoft Entra ID, usare l'autenticazione di firma di accesso condiviso (SAS) per concedere agli utenti l'accesso e diritti specifici per bus di servizio risorse.
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. È quindi possibile usare i certificati o l'autenticazione OAuth per proteggere l'endpoint. Il modo più semplice per proteggere un endpoint consiste nell'usare un'app per la logica con un trigger di richiesta o risposta HTTP come intermediario.
Il servizio Griglia di eventi consente di proteggere il recapito degli eventi tramite un codice di convalida. Se si usa App per la logica per utilizzare l'evento, la convalida è automatica. Per altre informazioni, vedere Event Grid security and authentication (Sicurezza e autenticazione di Griglia di eventi).
Sicurezza di rete
Prendere in considerazione la sicurezza di rete in tutta la progettazione.
È possibile associare bus di servizio Premium a un endpoint servizio della subnet di rete virtuale. Questa configurazione consente di proteggere lo spazio dei nomi perché accetta solo il traffico dalle reti virtuali autorizzate. È anche possibile usare collegamento privato di Azure per consentire solo il traffico privato verso la rete virtuale tramite endpoint privati.
È possibile configurare App per la logica Standard e Premium per accettare il traffico in ingresso tramite endpoint privati e inviare il traffico in uscita tramite l'integrazione della rete virtuale.
È possibile usare una rete virtuale di Azure per proteggere l'accesso alle API e all'istanza di Gestione API. Questo metodo supporta endpoint privati. Per altre informazioni, vedere Usare una rete virtuale con Gestione API.
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 Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.
Usare il calcolatore dei prezzi di Azure per stimare i costi. Di seguito alcune ulteriori considerazioni.
Gestione API
Vengono addebitati i costi per tutte le istanze di Gestione API quando vengono eseguite. Se si aumentano le prestazioni e quindi non è più necessario tale livello di prestazioni, ridurre o configurare manualmente la scalabilità automatica.
Per i carichi di lavoro di utilizzo leggero, prendere in considerazione il livello Consumo, che è un'opzione serverless a basso costo. Il livello Consumo viene fatturato per ogni chiamata API. 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 al numero di azioni e chiamate al connettore. Per altre informazioni, vedere Prezzi di App per la logica.
Code, argomenti e sottoscrizioni del bus di servizio
bus di servizio code e sottoscrizioni supportano modelli push e pull proxy per recapitare i messaggi. Nel modello pull ogni richiesta di polling viene a consumo come azione. Anche se si imposta il polling lungo sul valore predefinito di 30 secondi, il costo può essere elevato. A meno che non sia necessario il recapito dei messaggi in tempo reale, è consigliabile usare il modello push proxy.
bus di servizio code sono incluse in tutti i livelli: Basic, Standard e Premium. bus di servizio argomenti e sottoscrizioni sono disponibili nei livelli Standard e Premium. Per altre informazioni, vedere Prezzi del bus di servizio.
Griglia di eventi
Griglia di eventi usa un modello senza server. La fatturazione viene calcolata in base al numero di operazioni. Le operazioni includono eventi che passano a 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 e Ottimizzazione dei costi del framework ben progettato.
Eccellenza operativa
L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'eccellenza operativa.
L'architettura di riferimento di base dell'integrazione aziendale fornisce indicazioni sui modelli DevOps, allineati al pilastro Well-Architected Framework Operational Excellence .
Automatizzare le operazioni di ripristino il più possibile per migliorare l'eccellenza operativa. Tenendo presente l'automazione, è possibile combinare il monitoraggio dei 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 Flusso di failover.
Efficienza delle prestazioni
L'efficienza delle prestazioni è la capacità di dimensionare il carico di lavoro per soddisfare in modo efficiente le richieste poste dagli utenti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'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 altre informazioni, vedere bus di servizio livelli di messaggistica Premium e Standard e funzionalità di scalabilità automatica.
Per altre raccomandazioni bus di servizio, vedere Procedure consigliate per i miglioramenti delle prestazioni usando bus di servizio messaggistica.
Passaggi successivi
- Panoramica dell'integrazione di griglia di eventi di bus di servizio a Griglia di eventi
- Esercitazione che usa la messaggistica per integrare sistemi non Microsoft tramite NServiceBus