Modifica

Condividi tramite

Stile dell'architettura a più livelli

Archiviazione di Azure
Servizi cloud di Azure
Macchine virtuali di Azure

Un'architettura a più livelli divide un'applicazione in livelli logici e livelli fisici.

diagramma logico di uno stile di architettura a più livelli

I livelli sono un modo per separare le responsabilità e gestire le dipendenze. Ogni livello ha una responsabilità specifica. Un livello superiore può usare i servizi in un livello inferiore, ma non in altro modo.

I livelli sono separati fisicamente, in esecuzione in computer separati. Contrattualmente, il livello può avere i propri modelli di comunicazione rigorosi o rilassati. Nel modello strict, una richiesta deve passare attraverso livelli adiacenti, uno alla sola e non può ignorare alcun livello tra di essi. Ad esempio, dal web application firewall al livello Web, quindi al livello intermedio 1 e così via. Al contrario, nell'approccio rilassato, la richiesta può ignorare alcuni livelli, se necessario. L'approccio rigoroso ha maggiore latenza e sovraccarico e l'approccio rilassato ha più accoppiamenti e successivamente è più difficile cambiare. Un sistema può usare un approccio ibrido: avere livelli sia rilassati che rigorosi, se necessario.

Un livello può chiamare direttamente a un altro livello o usare modelli di messaggistica asincrona tramite una coda di messaggi. Anche se ogni livello potrebbe essere ospitato nel proprio livello, non è obbligatorio. Diversi livelli potrebbero essere ospitati nello stesso livello. La separazione fisica dei livelli migliora la scalabilità e la resilienza, ma aggiunge anche la latenza dalle comunicazioni di rete aggiuntive.

Un'applicazione tradizionale a tre livelli ha un livello di presentazione, un livello intermedio e un livello di database. Il livello intermedio è facoltativo. Le applicazioni più complesse possono avere più di tre livelli. Il diagramma precedente mostra un'applicazione con due livelli intermedi, incapsulando diverse aree di funzionalità.

Un'applicazione a più livelli può avere un'architettura a più livelli chiusa o un'architettura livello aperto:

  • In un'architettura di livello chiuso, un livello può chiamare solo il livello successivo immediatamente verso il basso.
  • In un'architettura a livello aperto, un livello può chiamare uno dei livelli sottostanti.

Un'architettura del livello chiuso limita le dipendenze tra i livelli. Tuttavia, potrebbe creare traffico di rete non necessario, se un livello passa semplicemente le richieste al livello successivo.

Quando usare questa architettura

Le architetture a più livelli vengono in genere implementate come applicazioni IaaS (Infrastructure-as-Service), con ogni livello in esecuzione in un set separato di macchine virtuali. Tuttavia, non è necessario che un'applicazione a più livelli sia pura IaaS. Spesso, è vantaggioso usare i servizi gestiti per alcune parti dell'architettura, in particolare la memorizzazione nella cache, la messaggistica e l'archiviazione dei dati.

Si consideri un'architettura a più livelli per:

  • Applicazioni Web semplici.
  • Un buon punto di partenza quando i requisiti architetturali non sono ancora chiari.
  • Migrazione di un'applicazione locale ad Azure con refactoring minimo.
  • Sviluppo unificato di applicazioni locali e cloud.

Le architetture a più livelli sono molto comuni nelle applicazioni locali tradizionali, quindi è una soluzione naturale per la migrazione di carichi di lavoro esistenti ad Azure.

Benefici

  • Portabilità tra cloud e locale e tra piattaforme cloud.
  • Curva di apprendimento inferiore per la maggior parte degli sviluppatori.
  • Costo relativamente basso non riprogettando la soluzione
  • Evoluzione naturale del modello applicativo tradizionale.
  • Open to eterogene environment (Windows/Linux) (Open to eterogene environment (Windows/Linux)

Sfide

  • È facile finire con un livello intermedio che esegue solo operazioni CRUD sul database, aggiungendo una latenza aggiuntiva senza eseguire operazioni utili.
  • La progettazione monolitica impedisce la distribuzione indipendente delle funzionalità.
  • La gestione di un'applicazione IaaS è più funzionante rispetto a un'applicazione che usa solo servizi gestiti.
  • Può essere difficile gestire la sicurezza di rete in un sistema di grandi dimensioni.
  • I flussi di utenti e dati si estendono in genere su più livelli, aggiungendo complessità a problemi come test e osservabilità.

Procedure consigliate

Architettura a più livelli nelle macchine virtuali

Questa sezione descrive un'architettura a più livelli consigliata in esecuzione nelle macchine virtuali.

diagramma fisico di un'architettura a più livelli

Ogni livello è costituito da due o più macchine virtuali, inserite in un set di disponibilità o in un set di scalabilità di macchine virtuali. Più macchine virtuali offrono resilienza nel caso in cui una macchina virtuale non riesca. I servizi di bilanciamento del carico vengono usati per distribuire le richieste tra le macchine virtuali in un livello. Un livello può essere ridimensionato orizzontalmente aggiungendo altre macchine virtuali al pool.

Ogni livello viene posizionato anche all'interno della propria subnet, ovvero gli indirizzi IP interni rientrano nello stesso intervallo di indirizzi. In questo modo è facile applicare le regole del gruppo di sicurezza di rete e instradare le tabelle ai singoli livelli.

I livelli Web e business sono senza stato. Qualsiasi macchina virtuale può gestire qualsiasi richiesta per tale livello. Il livello dati deve essere costituito da un database replicato. Per Windows, è consigliabile usare SQL Server usando i gruppi di disponibilità AlwaysOn per la disponibilità elevata. Per Linux scegliere un database che supporti la replica, ad esempio Apache Cassandra.

I gruppi di sicurezza di rete limitano l'accesso a ogni livello. Ad esempio, il livello di database consente l'accesso solo dal livello business.

Nota

Il livello "Livello business" nel diagramma di riferimento è un moniker per il livello della logica di business. Analogamente, chiamiamo anche il livello presentazione "Livello Web". In questo esempio si tratta di un'applicazione Web, anche se le architetture multilivello possono essere usate anche per altre topologie (ad esempio le app desktop). Assegnare un nome ai livelli più adatti al team per comunicare la finalità di tale livello logico e/o fisico nell'applicazione. È anche possibile esprimere tale denominazione nelle risorse che si sceglie di rappresentare tale livello( ad esempio vmss-appName-business-layer).

Considerazioni aggiuntive

  • Le architetture a più livelli non sono limitate a tre livelli. Per applicazioni più complesse, è comune avere più livelli. In tal caso, prendere in considerazione l'uso del routing di livello 7 per instradare le richieste a un determinato livello.

  • I livelli sono il limite di scalabilità, affidabilità e sicurezza. Prendere in considerazione la possibilità di avere livelli separati per i servizi con requisiti diversi in tali aree.

  • Usare i set di scalabilità di macchine virtuali per scalabilità automatica.

  • Cercare le posizioni nell'architettura in cui è possibile usare un servizio gestito senza refactoring significativo. In particolare, esaminare la memorizzazione nella cache, la messaggistica, l'archiviazione e i database.

  • Per una maggiore sicurezza, posizionare una rete perimetrale davanti all'applicazione. La rete perimetrale include appliance virtuali di rete che implementano funzionalità di sicurezza, ad esempio firewall e ispezione dei pacchetti. Per altre informazioni, vedere architettura di riferimento della rete perimetrale di rete .

  • Per la disponibilità elevata, inserire due o più appliance virtuali di rete in un set di disponibilità, con un servizio di bilanciamento del carico esterno per distribuire le richieste Internet tra le istanze. Per altre informazioni, vedere Distribuire appliance virtuali di rete a disponibilità elevata.

  • Non consentire l'accesso DIRETTO RDP o SSH alle macchine virtuali che eseguono il codice dell'applicazione. Gli operatori devono invece accedere a un jumpbox, detto anche host bastion. Si tratta di una macchina virtuale nella rete usata dagli amministratori per connettersi alle altre macchine virtuali. Il jumpbox ha un gruppo di sicurezza di rete che consente RDP o SSH solo da indirizzi IP pubblici approvati.

  • È possibile estendere la rete virtuale di Azure alla rete locale usando una rete privata virtuale da sito a sito (VPN) o Azure ExpressRoute. Per altre informazioni, vedere architettura di riferimento di rete ibrida .

  • Se l'organizzazione usa Active Directory per gestire l'identità, è possibile estendere l'ambiente Active Directory alla rete virtuale di Azure. Per altre informazioni, vedere architettura di riferimento di gestione delle identità .

  • Se è necessaria una disponibilità superiore rispetto al contratto di servizio di Azure per le macchine virtuali, replicare l'applicazione in due aree e usare Gestione traffico di Azure per il failover. Per altre informazioni, vedere Eseguire macchine virtuali Linux in più aree.