Considerazioni sulle architetture a più livelli
Sono stati esaminati gli elementi che costituiscono un'architettura a più livelli ed è stato distribuito un esempio di architettura a tre livelli. Verranno ora esaminati alcuni vantaggi e alcune problematiche di questo stile di architettura, nonché le procedure consigliate per ottimizzarlo in termini di prestazioni e sicurezza.
Vantaggi
Il vantaggio di questo stile di architettura è la semplicità. È uno schema architetturale ben definito e usato spesso, sia in locale che nelle distribuzioni cloud, e può essere applicato a un'ampia gamma di applicazioni.
È un'architettura indipendente dalla piattaforma e adatta per le applicazioni distribuite in Windows o Linux. Come illustrato nell'ambiente di esempio, è possibile usare servizi PaaS o IaaS a qualsiasi livello.
Con l'applicazione suddivisa in livelli, ogni livello può essere ridimensionato o aggiornato in modo indipendente. Se le richieste al sito Web aumentano, è possibile aggiungere altri server Web al carico, senza alcun impatto sugli altri livelli. Analogamente, se le richieste al livello dati aumentano, è possibile ridimensionare il database in modo da avere maggiore capacità per gestire le richieste.
La separazione della rete è un risultato naturale di questa architettura. Poiché l'applicazione è suddivisa in livelli, è consigliabile isolare ogni livello e consentire l'accesso alla rete solo quando necessario. Il livello presentazione può essere esposto al Web, il database può essere completamente protetto da più livelli di rete e l'applicazione continua a funzionare nello stesso modo. Con la protezione dell'accesso di rete tra i livelli si riduce la superficie di attacco dell'applicazione e se ne aumenta la sicurezza.
Problematiche e considerazioni
Quando si separa l'applicazione in più livelli, evitare i livelli intermedi che eseguono solo operazioni di database. Ogni livello deve aggiungere un valore specifico all'architettura. L'aggiunta di livelli aumenta la complessità, il tempo di elaborazione, la latenza e infine ritarda la comunicazione con l'utente.
Poiché le API per ogni dominio a livello applicazione non vengono separate in singoli servizi, devono essere ridimensionate insieme. Se un metodo di una singola applicazione richiede più potenza di elaborazione o deve gestire più richieste rispetto ad altri, per gestire il carico è necessario ridimensionare il livello applicazione nel suo complesso, invece di un singolo servizio.
In alcuni casi, si può sviluppare un'applicazione come un'architettura a più livelli, ma comunque deve essere distribuita in modo monolitico. Se si separa completamente ogni livello, è consigliabile distribuire ogni livello in modo indipendente. La separazione completa implica la rimozione delle dipendenze condivise e un maggiore affidamento sulle chiamate API tra livelli. Se fatto nel modo appropriato, garantisce flessibilità nelle distribuzioni dell'applicazione.
Le applicazioni in un'architettura a più livelli vengono spesso distribuite in macchine virtuali. È un primo passo utile, tuttavia l'evoluzione dell'applicazione verso l'uso di servizi PaaS offre numerosi vantaggi in termini di sicurezza, scalabilità e amministrazione. Questa evoluzione viene spesso trascurata e le architetture a più livelli restano residenti nelle macchine virtuali.
Lo stile di architettura a più livelli è di tipo classico, che in molti scenari è stato sostituito da altri modelli di progettazione moderni, ad esempio un'architettura a microservizi. Vale spesso la pena investire tempo per valutare altre architetture per vedere se sono più idonee alla propria applicazione.
Procedure consigliate per le architetture a più livelli
Sono molti gli aspetti su cui intervenire per assicurarsi che l'architettura a più livelli desiderata venga eseguita al meglio. Il diagramma riportato di seguito illustra come apportare miglioramenti a un'architettura a più livelli.
Ottimizzare le prestazioni
Di seguito vengono descritti alcuni modi per ottimizzare un'architettura a più livelli in termini di prestazioni e sicurezza.
Scalabilità automatica
Con l'applicazione suddivisa in livelli, è possibile usare le funzionalità cloud, ad esempio la scalabilità automatica, per adattarla al carico di sistema. Quando gli utenti o le richieste aumentano, usare la scalabilità automatica a più livelli per aggiungere altre risorse per gestire le richieste. Quando le richieste diminuiscono, la scalabilità automatica riduce le risorse di calcolo e riduce anche l'importo in fattura. La scalabilità automatica rende più facile assicurarsi che gli utenti abbiano un'esperienza ottimale e che i costi rimangano bassi. È possibile usare set di scalabilità di macchine virtuali di Azure per i carichi di lavoro basati su macchine virtuali e in molti servizi PaaS, ad esempio Servizio app di Azure, le funzionalità di scalabilità automatica sono integrate.
Bilanciamento del carico
Quando si ridimensiona l'applicazione con la scalabilità automatica, l'utilizzo del bilanciamento del carico diventa una parte necessaria dell'architettura. Con il bilanciamento del carico, quando si aggiungono altre risorse di elaborazione al livello, queste vengono aggiunte alla distribuzione del servizio di bilanciamento del carico per sfruttare la potenza di elaborazione aggiuntiva. Quando invece in un sistema si verifica un errore, il sistema viene rimosso dal carico per ridurre al minimo l'impatto sugli utenti, che potrebbero a quel punto subire una riduzione delle prestazioni o richieste errate. In questo modo le richieste degli utenti passano a sistemi con stato integro. Il servizio di bilanciamento del carico di Azure è una funzionalità integrata delle funzionalità di rete. Il gateway applicazione offre una soluzione di bilanciamento del carico HTTP più ricca di funzionalità.
Messaggistica
L'uso di un servizio di messaggistica tra livelli ha un effetto positivo sulle prestazioni, soprattutto sulle richieste che sono per natura asincrone. Il servizio inserisce un messaggio in una coda, dove resta finché non viene elaborato, compensando così l'impatto del carico a valle. Se si verifica un'interruzione del sistema, un servizio di messaggistica garantisce che il messaggio venga comunque gestito. Il messaggio rimane nella coda e viene elaborato al ripristino della connessione del sistema. Azure offre diverse soluzioni di messaggistica tra cui scegliere a seconda delle proprie esigenze. Il bus di servizio di Azure, le code di Archiviazione di Azure e Hub eventi di Azure sono alcune soluzioni da considerare quando si cerca un servizio di messaggistica.
Memorizzazione di dati nella cache
Usare una cache per i dati con accesso frequente e bassa frequenza di modifica o per i dati che non richiedono persistenza a lungo termine, ad esempio lo stato della sessione. I sistemi di memorizzazione nella cache si trovano tra i livelli e riducono i tempi di recupero dei dati per questi tipi di dati. Cache Redis di Azure è un servizio PaaS ideale per questo scenario.
Ottimizzare la sicurezza
Il processo di ottimizzazione ai fini della sicurezza non si può mai considerare del tutto "concluso". Sebbene l'applicazione sia suddivisa in livelli, sono comunque necessarie procedure di sicurezza ben pianificate integrate nell'architettura. Più si aggiungono livelli, più occorre proteggerli e più il sistema risulta complesso. Sono molti gli aspetti su cui intervenire per assicurarsi che l'architettura offra un ambiente sicuro per l'esecuzione dell'applicazione.
Isolamento della rete
Quando si esegue un'architettura a più livelli in macchine virtuali, assicurarsi che ogni livello si trovi nella propria subnet. Questa subnet funge da limite di sicurezza, permettendo così di isolare la connettività usando elenchi di controllo di accesso alla rete. La subnet facilita comunque la gestione, assicurando che i nuovi sistemi della subnet ricevano le stesse regole. In Azure questa operazione viene eseguita in modo nativo con i gruppi di sicurezza di rete (NSG). Considerazioni simili valgono per i servizi PaaS, tuttavia le funzionalità di integrazione di rete variano tra i servizi ed è consigliabile valutarle singolarmente. È buona norma assicurarsi che ogni livello possa comunicare solo con il livello successivo sottostante. Il livello presentazione deve poter comunicare solo con il livello applicazione e il livello applicazione solo con il livello dati. La riduzione al minimo di questa connettività rappresenta un approccio a strati alla sicurezza di rete e migliora la sicurezza complessiva di un'architettura.
Web application firewall
Dopo avere impostato l'isolamento di sicurezza tra le subnet, occorre assicurarsi che il front-end esposto al pubblico sia sicuro e che l'accesso sia consentito solo alle risorse necessarie. È consigliabile che solo il livello presentazione sia esposto al traffico in ingresso. Una tecnologia web application firewall (WAF) davanti al livello presentazione consente di migliorare la sicurezza a questo livello. I web application firewall ispezionano il traffico in cerca di attività dannose, assicurano che le comunicazioni vengano crittografate e avvisano se si verifica un evento fuori dall'ordinario. In Azure il gateway applicazione è un servizio di bilanciamento del carico HTTP con WAF integrato che può essere abilitato all'occorrenza.