Usare un broker di messaggi ed eventi per integrare i sistemi aziendali

Griglia di eventi di Azure
Bus di servizio di Azure

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 Azure, servizi basati su messaggi e servizi Web esistenti nell'azienda.

Diagramma che mostra un'architettura di riferimento per l'integrazione aziendale che usa code ed eventi.

Scaricare un file Visio di questa architettura.

Dettagli dello scenario

L'architettura precedente si basa sull'architettura di integrazione aziendale di base. Usa App per la logica di Azure per orchestrare i flussi di lavoro direttamente con i sistemi back-end e usa Gestione API di Azure per creare cataloghi di API.

Questa versione dell'architettura aggiunge due componenti che contribuiscono a rendere il sistema più affidabile e scalabile:

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 caricoQueue-Based per gestire i burst nei carichi di lavoro tramite il livellamento del carico

  • Usa il modello diPublisher-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 di Azure in modo che vari componenti del sistema possano reagire agli eventi quando si verificano, invece di 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 Azure supportano l'invio di eventi a Griglia di eventi. Ad esempio, App per la logica di Azure può rilevare un evento quando vengono aggiunti nuovi file 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 offre due modelli di distribuzione: il modello pull e il modello push tramite proxy.

  • Modello pull: Il ricevitore controlla continuamente la presenza di 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 sottoscrive inizialmente 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 workflow di App per la logica standard che usa i messaggi di bus di servizio, usare i trigger del connettore integrato di bus di servizio. 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 dell'area operativa e sicurezza perché il connettore esegue continuamente cicli all'interno del motore di runtime di Logic Apps. Per altre informazioni, vedere trigger del connettore predefinito di bus di servizio.

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 set di principi guida che è possibile usare per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Well-Architected Framework.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'affidabilità.

Per informazioni sui dettagli della disponibilità garantita di ciascun servizio, consultare gli SLA per i servizi online.

Sicurezza

La sicurezza fornisce protezioni contro attacchi intenzionali e l'uso improprio dei dati e dei sistemi preziosi. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per la sicurezza.

Per proteggere bus di servizio, associare l'autenticazione Microsoft Entra con identità gestite. L'integrazione di Entra ID per le risorse di bus di servizio fornisce il controllo degli accessi in base al ruolo di Azure (Azure RBAC) per un controllo granulare dell'accesso dei client alle risorse. Puoi utilizzare RBAC di Azure per concedere autorizzazioni a un'entità di sicurezza, come un utente, un gruppo o un principal del servizio applicazione. L'entità servizio dell'applicazione in questo scenario è un'identità gestita.

Se non è possibile usare Entra ID, usare l'autenticazione con firma di accesso condiviso (SAS) per concedere agli utenti l'accesso e autorizzazioni specifiche alle risorse di bus di servizio.

Se è necessario esporre una coda o un argomento bus di servizio come endpoint HTTP, ad esempio per pubblicare nuovi messaggi, si usi API Management per contribuire a proteggere la coda proteggendo l'endpoint. È 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 usi Logic Apps per consumare 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.

Ottimizzazione dei costi

L'ottimizzazione dei costi è incentrata sui 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 prezzi Azure per stimare i costi. Di seguito alcune ulteriori considerazioni.

Gestione API

Vengono addebitati i costi per tutte le istanze di API Management quando sono attive. 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 piano di Consumo, un'opzione a basso costo e serverless. Il livello Consumo viene fatturato per ogni chiamata API. Gli altri livelli vengono fatturati all'ora.

Logic Apps Standard

Logic Apps Standard utilizza un modello di calcolo elastico. La fatturazione viene calcolata in base al numero di CPU e memoria usate all'ora. Per ulteriori informazioni, vedere Prezzi dei Logic Apps.

bus di servizio code di attesa, argomenti e sottoscrizioni

Le code di messaggio e le sottoscrizioni di bus di servizio supportano entrambi i modelli push e pull tramite proxy per recapitare messaggi. Nel modello pull, ogni richiesta di polling viene conteggiata come un'azione. Anche nel caso in cui si imposti 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.

Le code di bus di servizio 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, consulta prezzi di 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 inviati a domini o argomenti (topics), corrispondenze avanzate, tentativi di recapito e chiamate di gestione. L'utilizzo di un massimo di 100.000 operazioni è gratuito.

Per altre informazioni, vedi prezzi di Event Grid.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per ulteriori informazioni, vedere Lista di controllo per la revisione del design per l'Eccellenza Operativa.

L'architettura di riferimento di integrazione aziendale di base 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 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 del failover.

Efficienza delle prestazioni

L'efficienza delle prestazioni si riferisce alla capacità del carico di lavoro di ridimensionarsi per soddisfare in modo efficiente le esigenze degli utenti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'efficienza delle prestazioni.

Per ottenere una maggiore scalabilità, il livello bus di servizio Premium può aumentare il numero di unità di messaggistica. Per ulteriori informazioni, vedere livelli di messaggistica bus di servizio Premium e Standard e la funzionalità di autoscaling.

Per altre raccomandazioni su bus di servizio, vedere Migliori pratiche per miglioramenti delle prestazioni mediante l'uso della messaggistica di bus di servizio.

Passaggi successivi