Condividi tramite

Stili di architettura

  • Articolo

Uno stile di architettura è una famiglia di architetture che condividono determinate caratteristiche. Ad esempio lo stile a più livelli è uno stile di architettura comune. Più di recente le architetture di microservizi hanno iniziato ad acquisire consenso. Gli stili di architettura non richiedono l'uso di tecnologie particolari, ma alcune tecnologie sono più adatte per alcune architetture. Ad esempio i contenitori sono una scelta naturale per i microservizi.

È stato identificato un set di stili di architettura che si trovano in genere nelle applicazioni cloud. L'articolo per ogni stile include:

  • Una descrizione e un diagramma logico dello stile.
  • Raccomandazioni su quando scegliere lo stile.
  • Vantaggi, sfide e procedure consigliate.
  • Una distribuzione consigliata utilizzando servizi di Azure pertinenti.

Una breve panoramica degli stili

Questa sezione fornisce una breve panoramica degli stili di architettura che abbiamo identificato insieme ad alcune considerazioni generali sul loro utilizzo. Si noti che l'elenco non è esaustivo. Altre informazioni sono disponibili negli argomenti collegati.

A più livelli

Diagramma logico di uno stile di architettura a più livelli.

L'architettura a più livelli è un'architettura tradizionale per le applicazioni aziendali. Le dipendenze vengono gestite suddividendo l'applicazione in livelli che eseguono funzioni logiche, come presentazione, logica di business e accesso ai dati. Un livello può chiamare solo il livelli che si trovano al di sotto. Tuttavia, questa sovrapposizione orizzontale può essere un ostacolo. Può essere difficile apportare modifiche in una sola parte dell'applicazione senza toccare il resto. Questo rende difficoltosi gli aggiornamenti frequenti, limitando la frequenza con cui è possibile aggiungere nuove funzionalità.

L'architettura a più livelli è una scelta naturale per la migrazione delle applicazioni esistenti che già usano un'architettura a livelli. Per questo motivo, l'architettura a più livelli si vede più spesso nelle soluzioni di infrastruttura distribuita come servizio (Iaas) o un'applicazione che usa una combinazione di IaaS e servizi gestiti.

Web-coda-ruolo di lavoro

Diagramma logico dello stile dell'architettura Web-Queue-Worker.

Per una soluzione esclusivamente PaaS, prendere in considerazione un'architettura Web-coda-ruolo di lavoro. In questo stile l'applicazione dispone di un front-end Web che gestisce le richieste HTTP e un ruolo di lavoro back-end che esegue attività a elevato utilizzo della CPU o operazioni a esecuzione prolungata. Il front-end comunica con il ruolo di lavoro tramite una coda di messaggi asincroni.

L'architettura Web-coda-ruolo di lavoro è adatta per i domini relativamente semplici con alcune attività a elevato utilizzo di risorse. Come quella a più livelli, anche questa architettura è facile da capire. L'uso dei servizi gestiti semplifica la distribuzione e le operazioni. Ma con i domini complessi, può risultare difficile gestire le dipendenze. Il front-end e il ruolo di lavoro possono diventare facilmente componenti monolitici di grandi dimensioni, difficoltosi da gestire e aggiornare. Come con più livelli, questo può ridurre la frequenza degli aggiornamenti e limitare l'innovazione.

Microservizi

Diagramma logico dello stile dell'architettura dei microservizi.

Se l'applicazione include un dominio più complesso, può essere preferibile passare a un'architettura di microservizi. Un'applicazione di microservizi è composta da molti servizi di piccole dimensioni indipendenti. Ogni servizio implementa una singola funzionalità di business. I servizi sono accoppiati in modo debole e comunicano tramite contratti API.

Ogni servizio può essere compilato da un team di sviluppo mirato di piccole dimensioni. I singoli servizi possono essere distribuiti senza molta coordinamento tra i team, che incoraggia aggiornamenti frequenti. Un'architettura di microservizi è più complessa da creare e gestire rispetto sia all'architettura a più livelli sia a quella Web-coda-ruolo di lavoro. Richiede uno sviluppo maturo e una cultura DevOps. Ma eseguito correttamente, questo stile può portare a una maggiore velocità di rilascio, un'innovazione più veloce e un'architettura più resiliente.

Architettura basata su eventi

Diagramma di uno stile di architettura basato su eventi.

L'architettura basata su eventi usa un modello pubblicazione-sottoscrizione (pub-sub) in cui i produttori pubblicano eventi e i consumer li sottoscrivono. I produttori sono indipendenti dai consumer e i consumer sono indipendenti tra loro.

Si consideri un'architettura basata su eventi per le applicazioni che accettano ed elaborano una grande quantità di dati con una latenza molto bassa, come le soluzioni IoT. Lo stile è utile anche quando sottosistemi diversi devono eseguire diversi tipi di elaborazione sugli stessi dati di evento.

Big Data e Big Compute

Diagramma logico di uno stile di architettura di Big Data.

Big Data e Big Compute sono stili architettura specializzati per carichi di lavoro che soddisfano determinati profili specifici. Lo stile Big Data divide in blocchi un set di dati di dimensioni molto grandi, eseguendo l'elaborazione parallela sull'intero set per analisi e creazione di report. Lo stile Big Compute, anche chiamato calcolo ad alte prestazioni (HPC, high-performance computing), esegue calcoli paralleli in un numero elevato (migliaia) di core. I domini includono simulazioni, modellazione e rendering 3D.

Stili di architettura e vincoli

Uno stile di architettura impone vincoli sulla progettazione, incluso il set di elementi che possono essere visualizzati e le relazioni consentite tra gli elementi. I vincoli determinano la "forma" di un'architettura limitando l'universo di scelte. Quando un'architettura è conforme ai vincoli di un determinato stile, emerge determinate proprietà auspicabili.

Ad esempio, i vincoli nei microservizi includono:

  • Un servizio rappresenta un'unica responsabilità.
  • Ogni servizio è indipendente dagli altri.
  • I dati sono privati per il servizio che ne è proprietario. I servizi non condividono dati.

Aderendo a questi vincoli, emerge un sistema in cui i servizi possono essere distribuiti in modo indipendente, gli errori sono isolati, sono possibili aggiornamenti frequenti ed è facile inserire nuove tecnologie nell'applicazione.

Ogni stile di architettura ha i propri compromessi. Pertanto, prima di scegliere qualsiasi stile architettonico, assicurarsi di comprendere i principi e i vincoli sottostanti di tale stile. In caso contrario, si può ottenere una progettazione che è conforme con lo stile a un livello superficiale, ma non realizza il pieno potenziale dello stile. È necessario prestare maggiore attenzione al motivo per cui si sta scegliendo un determinato stile architettonico che su come implementarlo. È importante anche essere pratici. In alcuni casi è preferibile allentare un vincolo, anziché insistere sulla purezza dell'architettura.

La scelta di uno stile architettonico appropriato deve essere eseguita idealmente con un consenso di stakeholder del carico di lavoro informati. Il team del carico di lavoro deve innanzitutto identificare la natura del problema che sta tentando di risolvere. Devono quindi identificare i driver aziendali e le caratteristiche di architettura corrispondenti (noti anche come requisiti non funzionali) e quindi assegnarle priorità. Ad esempio, se hanno bisogno di tempi più brevi per il mercato, potrebbero classificare in ordine di priorità la gestibilità, la testabilità e l'affidabilità grazie alle funzionalità di distribuzione rapida. In alternativa, se il team del carico di lavoro ha un budget limitato, potrebbe dare priorità alla fattibilità e alla semplicità. La scelta e la gestione di uno stile architetturale non è un'attività occasionale, ma un approccio continuo: l'architettura deve essere misurata, convalidata e ottimizzata in modo continuo nel tempo. In genere si verifica un costo significativo per il cambio dello stile dell'architettura, quindi è possibile giustificare un maggiore impegno iniziale per l'efficienza del team a lungo termine e la mitigazione dei rischi.

La tabella seguente riepiloga il modo in cui ogni stile gestisce le dipendenze e i tipi di dominio più adatti.

Stile di architettura Gestione delle dipendenze Tipo di dominio
N livelli Livelli orizzontali divisi per subnet Dominio aziendale tradizionale. La frequenza degli aggiornamenti è bassa.
Web-queue-worker Processi front-end e back-end, disaccoppiati dalla messaggistica asincrona. Dominio relativamente semplice con alcune attività con utilizzo intensivo di risorse.
Microservizi Servizi scomposti verticalmente (funzionalmente) che di chiamano a vicenda attraverso le API. Dominio complicato. Aggiornamenti frequenti.
Architettura guidata dagli eventi Produttore/consumer. Vista indipendente per sottosistema. IoT e sistemi in tempo reale.
Big Data Dividere un set di dati di grandi dimensioni in piccoli blocchi. Elaborazione parallela in set di dati locali. Analisi dei dati in catch e in tempo reale. Analisi predittiva mediante ML.
Big Compute Allocazione di dati a migliaia di core. Domini ad alta intensità di calcolo, come la simulazione.

Considerare problemi e vantaggi

I vincoli creano anche sfide, pertanto è importante conoscere i vantaggi e svantaggi dell'adozione di qualsiasi di questi stili. I vantaggi dello stile di architettura superano le sfide, per questo sottodominio e il contesto associato?

Ecco alcuni dei tipi di problematiche da prendere in considerazione quando si seleziona uno stile di architettura:

  • Complessità. La complessità dell'architettura è giustificata per il dominio? Al contrario, lo stile è troppo semplicistico per il dominio? In tal caso, si rischia di ottenere un'architettura inesistente, perché non consente di gestire correttamente le dipendenze.

  • Messaggistica asincrona e coerenza finale. La messaggistica asincrona consente di disaccoppiare i servizi e aumentare l'affidabilità (perché è possibile ritentare i messaggi) e la scalabilità. Tuttavia, crea anche problemi di gestione della coerenza finale, nonché la possibilità di messaggi duplicati.

  • Comunicazione fra i servizi. Quando si scompone un'applicazione in servizi separati, c'è il rischio che la comunicazione tra i servizi causi una latenza accettabile o crei una congestione della rete (ad esempio in un'architettura di microservizi).

  • Gestibilità. Quanto è difficile gestire l'applicazione, monitorare, distribuire gli aggiornamenti e così via?