Stili di architettura

Uno stile di architettura è una famiglia di architetture che condividono caratteristiche specifiche. Ad esempio, il livello N è uno stile di architettura comune. Più di recente, le architetture di microservizi stanno iniziando a guadagnare favore. Gli stili di architettura non richiedono l'uso di tecnologie specifiche, ma alcune tecnologie sono più adatte per determinate architetture. Ad esempio, i contenitori sono particolarmente adatti per i microservizi.

È stato identificato un set di stili di architettura comunemente presenti nelle applicazioni cloud. L'articolo per ogni stile include i componenti seguenti:

• Descrizione e diagramma logico dello stile
• Consigli per quando scegliere questo stile
• Vantaggi, sfide e procedure consigliate
• Distribuzione consigliata che usa i servizi di Azure pertinenti

Un rapido tour degli stili

Questa sezione illustra rapidamente gli stili di architettura identificati, insieme ad alcune considerazioni di alto livello per l'uso. Questo elenco non è esaustivo. Per altre informazioni, vedere gli articoli collegati.

N livelli

Il diagramma illustra la struttura a N livelli di un'architettura con una chiara separazione tra i componenti. Le richieste client vengono inserite tramite un web application firewall (WAF) che fornisce filtri di sicurezza prima di raggiungere il livello Web. Il livello Web funge da livello di presentazione. Gestisce le interazioni utente e il routing delle richieste ai componenti della logica di business appropriati. Due percorsi di elaborazione distinti emergono dal livello Web: un percorso passa direttamente al livello intermedio uno per le operazioni sincrone, mentre un altro percorso usa l'infrastruttura di messaggistica per comunicare con il livello intermedio 2 per l'elaborazione asincrona. Entrambi i livelli intermedi rappresentano livelli della logica di business che elaborano le richieste e interagiscono con il livello dati tramite meccanismi di memorizzazione nella cache per ottimizzare le prestazioni. Il livello dati funge da base. Archivia e gestisce i dati dell'applicazione supportando entrambi i livelli intermedi tramite modelli di accesso ai dati memorizzati nella cache.

Il livello N è un'architettura tradizionale per le applicazioni aziendali che divide un'applicazione in livelli logici e livelli fisici. Ogni livello ha una responsabilità specifica e i livelli gestiscono le dipendenze effettuando chiamate solo verso i livelli sottostanti. I livelli tipici includono presentazione, logica di business e accesso ai dati.

Le architetture a più livelli sono adatte per la migrazione di applicazioni esistenti che usano già un'architettura a più livelli. Questo approccio richiede modifiche minime quando si passa ad Azure e supporta ambienti misti con componenti locali e cloud. Tuttavia, la sovrapposizione orizzontale può rendere difficile introdurre modifiche senza influire su più parti dell'applicazione, che limita l'agilità per gli aggiornamenti frequenti.

Web-Queue-Worker

Il diagramma mostra una separazione pulita tra i componenti di elaborazione in background e rivolti all'utente. Le interazioni client iniziano con l'autenticazione tramite un provider di identità prima di raggiungere il front-end Web, che funge da interfaccia utente primaria. Il front-end Web mantiene tre relazioni operative distinte: può comunicare direttamente con i servizi remoti per le integrazioni esterne, accedere al database per operazioni immediate sui dati e accodare gli elementi di lavoro per l'elaborazione in background. La coda funge da meccanismo di disaccoppiamento. Consente al componente di lavoro di elaborare attività a elevato utilizzo di risorse o a esecuzione prolungata indipendentemente dalle richieste degli utenti. Il processo worker recupera i lavori dalla coda ed esegue operazioni sul database, con l'infrastruttura di caching che supporta sia il front-end web che il worker per un accesso ai dati ottimizzato. Inoltre, il contenuto statico viene distribuito tramite una rete per la distribuzione di contenuti (CDN) per migliorare le prestazioni per le applicazioni client.

Web-Queue-Worker è un'architettura costituita da un front-end Web, una coda di messaggi e un ruolo di lavoro back-end. Il front-end Web gestisce le richieste HTTP e le interazioni dell'utente, mentre il worker esegue attività a uso intensivo di risorse, flussi di lavoro a lunga durata o operazioni batch. La comunicazione tra l'interfaccia e il worker avviene tramite una coda di messaggi asincrona.

Questa architettura è ideale per le applicazioni con domini relativamente semplici con requisiti di elaborazione a elevato utilizzo di risorse. È facile comprendere e distribuire con servizi di Azure gestiti, ad esempio Servizio app e Funzioni di Azure. È possibile ridimensionare in modo indipendente il front end e il worker per offrire flessibilità nell'allocazione delle risorse. Ma senza un'attenta progettazione, entrambi i componenti possono diventare grandi e monolitici.

Microservizi

Il diagramma illustra un'architettura di microservizi distribuiti organizzata in livelli funzionali distinti. A sinistra, le applicazioni client e i sistemi esterni avviano richieste che passano attraverso un gateway API centralizzato, che funge da singolo punto di ingresso e meccanismo di routing per l'intero sistema. Il gateway API indirizza le richieste al livello di microservizi appropriato, che contiene più tipi di servizio: servizi di dominio che incapsulano funzionalità aziendali specifiche, servizi di composizione che orchestrano le interazioni tra i servizi di dominio e singoli servizi che gestiscono funzioni discrete. Ogni microservizio mantiene l'autonomia dei dati tramite il proprio database dedicato. Il diagramma mostra un approccio di persistenza poliglotta usando database SQL e NoSQL personalizzati in base ai requisiti di dati specifici di ogni servizio. I microservizi comunicano in modo asincrono tramite middleware orientato ai messaggi. Questo approccio consente l'accoppiamento libero tramite modelli di pubblicazione-sottoscrizione e interazioni guidate dagli eventi. Tre livelli fondamentali dell'infrastruttura supportano questa architettura distribuita: i sistemi di osservabilità forniscono monitoraggio, registrazione e traccia distribuita completi attraverso i limiti del servizio. Le piattaforme di gestione e orchestrazione gestiscono la distribuzione, il ridimensionamento e l'individuazione dei servizi automatizzati. Le toolchain DevOps consentono l'integrazione continua, i test e le pipeline di recapito per distribuzioni di servizi indipendenti.

L'architettura dei microservizi scompone le applicazioni in una raccolta di servizi autonomi di piccole dimensioni. Ogni servizio implementa una singola funzionalità aziendale all'interno di un contesto delimitato ed è indipendente con la propria archiviazione dei dati. I servizi comunicano tramite API ben definite e possono essere sviluppati, distribuiti e ridimensionati in modo indipendente.

I microservizi consentono ai team di lavorare in modo autonomo e supportare aggiornamenti frequenti con una maggiore velocità di rilascio. Questa architettura è particolarmente adatta per domini complessi che richiedono modifiche frequenti e innovazione. Ma introduce una notevole complessità in aree come l'individuazione dei servizi, la coerenza dei dati e la gestione del sistema distribuita. Il successo richiede procedure di sviluppo e DevOps mature, che lo rendono più adatto per le organizzazioni che dispongono di funzionalità tecniche avanzate.

Architettura basata su eventi

Il diagramma illustra un modello di comunicazione asincrono e disaccoppiato fondamentale per le architetture guidate dagli eventi. Più producer di eventi operano in modo indipendente. Flussi di eventi generati basati su attività aziendali, interazioni utente o modifiche dello stato del sistema senza alcuna conoscenza dei consumatori a valle. I produttori inseriscono gli eventi in un sistema di inserimento eventi centralizzato che funge da broker intelligente. Il broker riceve, convalida, mantiene e distribuisce in modo affidabile gli eventi nell'architettura. Il componente di inserimento eventi funge da punto di disaccoppiamento critico. Garantisce che i produttori rimangano isolati dai consumatori, fornendo garanzie relative al recapito, all'ordinamento e alla durabilità degli eventi. Da questo hub centrale, gli eventi vengono distribuiti tramite un modello di fan-out a più consumer di eventi indipendenti posizionati sul lato destro del diagramma. Ogni consumer rappresenta una capacità aziendale o un servizio distinto che sottoscrive tipi di eventi specifici rilevanti nell'ambito delle sue responsabilità di dominio. I consumer elaborano gli eventi in modo asincrono e parallelo, consentendo al sistema di scalare orizzontalmente mantenendo un accoppiamento debole. Questo modello di architettura rimuove le dipendenze dirette tra producer e consumer. Consente a ogni componente di evolversi, scalare e distribuire in modo indipendente, mantenendo la resilienza del sistema tramite le funzionalità di buffering e retry del broker di eventi.

Le architetture guidate dagli eventi usano un modello di pubblicazione-sottoscrizione in cui i produttori di eventi generano flussi di eventi e i consumer di eventi rispondono a tali eventi quasi in tempo reale. I produttori e i consumer sono separati l'uno dall'altro, con la comunicazione che avviene tramite canali di eventi o broker. Questa architettura supporta sia l'elaborazione semplice degli eventi che l'analisi dei modelli di eventi complessi.

Le architetture guidate dagli eventi sono eccellenti negli scenari che richiedono l'elaborazione in tempo reale con una latenza minima. Alcuni esempi sono soluzioni IoT, sistemi di trading finanziario o applicazioni che devono elaborare volumi elevati di dati di streaming. Le architetture guidate dagli eventi offrono un'eccellente scalabilità e isolamento degli errori, ma introducono sfide relative al recapito garantito, all'ordinamento degli eventi e alla coerenza finale tra i componenti distribuiti.

Big Data

Il diagramma presenta un'architettura di Big Data completa con due pipeline di elaborazione complementari che gestiscono velocità dei dati e requisiti analitici diversi. La pipeline di elaborazione batch inizia con origini dati diverse che si inseriscono in sistemi di archiviazione dati scalabili, in genere data lake o file system distribuiti in grado di archiviare volumi elevati di dati strutturati, semistrutturati e non strutturati. Il componente di elaborazione batch esegue trasformazioni, aggregazioni e calcoli analitici su larga scala sui dati cronologici. Opera su intervalli pianificati o quando si accumulano dati sufficienti. I risultati del flusso di elaborazione batch attraverso due percorsi: direttamente ai sistemi di analisi e creazione di report per l'utilizzo immediato e agli archivi dati analitici in cui i dati elaborati vengono mantenuti in formati ottimizzati per query complesse e analisi cronologiche. Contemporaneamente, la pipeline di elaborazione in tempo reale acquisisce i dati in streaming tramite sistemi di inserimento messaggi in tempo reale che gestiscono flussi di dati ad alta velocità da origini come dispositivi IoT, applicazioni Web o sistemi transazionali. I componenti di elaborazione dei flussi analizzano questi dati in movimento, eseguono aggregazioni in tempo reale, filtri e rilevamento dei criteri per generare informazioni immediate. I risultati in tempo reale seguono anche due percorsi, inserendoli sia direttamente nell'analisi che nella creazione di report per dashboard e avvisi istantanei e negli stessi archivi dati analitici per creare una visualizzazione unificata che combina i dati cronologici e correnti. Il livello di orchestrazione si estende su entrambe le pipeline. Coordina flussi di lavoro complessi, gestisce le dipendenze tra processi batch e di streaming, pianifica le attività di elaborazione e garantisce la coerenza dei dati nell'intera architettura. Questa orchestrazione consente di creare architetture lambda in cui l'elaborazione batch e in tempo reale può operare sugli stessi set di dati, fornendo sia analisi cronologiche complete che informazioni operative immediate.

Le architetture di Big Data gestiscono l'inserimento, l'elaborazione e l'analisi dei dati troppo grandi o complessi per i sistemi di database tradizionali. Queste architetture includono in genere componenti per l'archiviazione dei dati (ad esempio data lake), l'elaborazione batch per l'analisi cronologica, l'elaborazione dei flussi per informazioni dettagliate in tempo reale e gli archivi dati analitici per la creazione di report e la visualizzazione.

Le architetture di Big Data sono essenziali per le organizzazioni che devono estrarre informazioni dettagliate da set di dati di grandi dimensioni, supportare l'analisi predittiva usando Machine Learning o elaborare dati di streaming in tempo reale dai dispositivi IoT. Le implementazioni moderne usano spesso servizi gestiti come Microsoft Fabric per semplificare la complessità della creazione e della gestione di soluzioni Per Big Data.

Computazione su larga scala

Il diagramma illustra un sofisticato sistema operativo e distribuzione dei processi progettato per carichi di lavoro ad alte prestazioni. Nel punto di ingresso, le applicazioni client inviano processi computazionalmente intensivi tramite un'interfaccia di coda dei lavori che funge da meccanismo di buffer e di ricezione per le richieste di lavoro in ingresso. I lavori affluiscono a un componente pianificatore o coordinatore centralizzato che funge da cervello intelligente del sistema, responsabile dell'analisi delle caratteristiche dei lavori, dei requisiti delle risorse e delle dipendenze computazionali. L'utilità di pianificazione esegue funzioni critiche, tra cui la scomposizione dei processi, la pianificazione dell'allocazione delle risorse e l'ottimizzazione del carico di lavoro in base alle risorse di calcolo disponibili e alle interdipendenze delle attività. Da questo punto di coordinamento centrale, l'utilità di pianificazione instrada in modo intelligente il lavoro lungo due percorsi operativi distinti in base alle caratteristiche di calcolo di ogni processo. Il primo percorso indirizza il lavoro agli ambienti di gestione parallela delle attività progettati per carichi di lavoro in parallelo imbarazzante in cui le singole attività possono essere eseguite in modo indipendente senza richiedere la comunicazione tra le unità di elaborazione. Queste attività parallele vengono distribuite tra centinaia o migliaia di core contemporaneamente, con ciascun core che elabora unità di lavoro discrete in isolamento. Il secondo percorso gestisce attività strettamente associate che richiedono frequenti comunicazioni tra processi, accesso condiviso alla memoria o modelli di operazioni sincronizzati. Questi carichi di lavoro strettamente associati usano in genere interconnessioni ad alta velocità, ad esempio InfiniBand o reti RDMA (Remote Direct Memory Access) per consentire uno scambio rapido di dati tra i nodi di elaborazione. L'utilità di pianificazione monitora continuamente entrambi gli ambienti operativi, gestisce l'allocazione delle risorse, gestisce la tolleranza di errore e ottimizza le prestazioni regolando dinamicamente la distribuzione del lavoro in base a capacità di sistema, priorità del processo e requisiti di completamento. L'approccio biforcato consente all'architettura di gestire in modo efficiente carichi di lavoro di calcolo diversi, ottimizzando l'uso delle risorse nell'intera infrastruttura di elaborazione.

Le architetture di big computing supportano carichi di lavoro su larga scala che richiedono centinaia o migliaia di core per operazioni a elevato utilizzo di calcolo. Il lavoro può essere suddiviso in attività discrete eseguite contemporaneamente su molti core, con ogni attività che prende input, lo elabora e produce output. Le attività possono essere indipendenti (perfettamente parallele) o strettamente associate che richiedono comunicazioni ad alta velocità.

Il Big Compute è essenziale per simulazioni, modellazione dei rischi finanziari, calcolo scientifico, analisi dello stress tecnico e rendering 3D. Azure offre opzioni come Azure Batch per carichi di lavoro big compute gestiti o HPC Pack per la gestione dei cluster più tradizionale. Queste architetture possono espandere la capacità su richiesta e ridimensionarsi fino a migliaia di core all'occorrenza.

Stili di architettura come vincoli

Uno stile di architettura inserisce vincoli sulla progettazione, incluso il set di elementi che possono essere visualizzati e le relazioni consentite tra tali elementi. I vincoli guidano la "forma" di un'architettura limitando l'universo delle scelte. Quando un'architettura è conforme ai vincoli di uno stile specifico, emergono determinate proprietà desiderate.

Ad esempio, i vincoli nei microservizi includono:

• Un servizio rappresenta una singola responsabilità.
• Ogni servizio è indipendente dagli altri.
• I dati sono privati al servizio che li possiede. I servizi non condividono i dati.

Quando si rispetta questi vincoli, si ottiene un sistema che consente di eseguire le azioni seguenti:

• Distribuire i servizi in modo indipendente.
• Isolare gli errori.
• Distribuire aggiornamenti più frequenti.
• Introdurre nuove tecnologie nell'applicazione più facilmente.

Ogni stile di architettura ha i propri compromessi. Prima di scegliere uno stile architettonico, è essenziale comprendere i principi e i vincoli sottostanti. Senza tale comprensione, si rischia di creare un design che si conforma superficialmente allo stile senza rendersi conto dei suoi vantaggi completi. Concentrarsi maggiormente sul motivo per cui si seleziona uno stile specifico rispetto a come implementarlo. Siate pratici. A volte è meglio rilassare un vincolo che inseguire la purezza dell'architettura.

Idealmente, la scelta dello stile dell'architettura deve essere effettuata con l'input degli stakeholder del carico di lavoro informati. Il team del carico di lavoro deve iniziare identificando la natura del problema che sta risolvendo. Devono quindi definire i principali driver aziendali e le caratteristiche di architettura corrispondenti, noti anche come requisiti non funzionali e assegnarle priorità. Ad esempio, se il time-to-market è fondamentale, il team potrebbe classificare in ordine di priorità la gestibilità, la testabilità e l'affidabilità per abilitare la distribuzione rapida. Se il team ha vincoli di budget limitati, la fattibilità e la semplicità potrebbero avere la precedenza. La selezione e il mantenimento di uno stile architetturale non è un'attività monouso. Richiede misurazioni, convalida e perfezionamento in corso. Poiché il cambiamento della direzione dell'architettura in un secondo momento può essere costoso, spesso vale la pena investire più impegno iniziale per supportare l'efficienza a lungo termine e ridurre i rischi.

Nella tabella seguente viene riepilogato il modo in cui ogni stile gestisce le dipendenze e i tipi di dominio più adatti per ogni stile.

Stile di architettura	Gestione delle dipendenze	Tipo di dominio
A più livelli	Livelli orizzontali divisi per sottorete	Dominio aziendale tradizionale. La frequenza degli aggiornamenti è bassa.
Web-Queue-Worker	Processi front-end e back-end, separati dalla messaggistica asincrona.	Dominio relativamente semplice con alcune attività a elevato utilizzo di risorse.
Microservizi	Servizi scomposti verticalmente (funzionalmente) che si chiamano tra loro tramite le API.	Dominio complicato. Aggiornamenti frequenti.
Architettura guidata dagli eventi	Produttore o consumatore. Visualizzazione indipendente per ogni sottosistema.	Internet delle cose (IoT) e sistemi in tempo reale.
Big Data	Dividere un set di dati enorme in piccoli blocchi. Elaborazione parallela nei set di dati locali.	Analisi dei dati in batch e in tempo reale. Analisi predittiva con Machine Learning.
Big Compute	Allocazione dei dati a migliaia di core.	Domini a elevato utilizzo di calcolo, ad esempio la simulazione.

Prendere in considerazione sfide e vantaggi

I vincoli creano anche sfide, quindi è importante comprendere i compromessi quando si adotta uno di questi stili. Determinare se i vantaggi dello stile dell'architettura superano le sfide, per questo sottodominio e contesto delimitato.

Quando si seleziona uno stile di architettura, considerare i tipi di problemi seguenti:

• Complessità: La complessità dell'architettura deve corrispondere al dominio. Se è troppo semplicistico, può comportare una grande palla di fango, in cui le dipendenze non sono ben gestite e la struttura si suddivide.

• Messaggistica asincrona e coerenza finale: La messaggistica asincrona viene usata per separare i servizi e migliorare l'affidabilità perché è possibile ritentare i messaggi. Migliora anche la scalabilità. Tuttavia, la messaggistica asincrona crea anche problemi nella gestione della coerenza finale e della possibilità di messaggi duplicati.

• Comunicazione tra servizi: La scomposizione di un'applicazione in servizi separati potrebbe aumentare il sovraccarico di comunicazione. Nelle architetture di microservizi questo sovraccarico comporta spesso problemi di latenza o congestione della rete.

• Maneggiabilità: La gestione dell'applicazione include attività come il monitoraggio, la distribuzione degli aggiornamenti e la gestione dell'integrità operativa.

" output is necessary.)

• Dieci principi di progettazione per le applicazioni Azure

Passaggi successivi

• Creare applicazioni in Microsoft Cloud
• Procedure consigliate nelle applicazioni cloud
• modelli di progettazione cloud
• Test delle prestazioni e antipattern per le applicazioni cloud
• Progettare soluzioni multi-tenant in Azure
• Architettura del carico di lavoro cruciale in Azure
• Architettura per le startup