Infrastruttura distribuita scalabile, affidabile e ad elevate prestazioni

Dopo tutte le verifiche ed i test, la messa in esercizio (Deployment) è la vera "prova del 9" della riuscita del progetto, in cui il committente approva definitivamente l'opera e il team può festeggiare... quasi sempre.

L'obiettivo principale della fase di Deployment è quello di fornire il prodotto finito al cliente, che nel caso di applicazioni più complesse (come quelle di tipo "distribuito"), può consistere nell'installazione su più server dedicati.

Inizialmente, l’infrastruttura è concordata con il committente, sulla base dei carichi di lavoro previsti. In generale, si avrà un’architettura di questo tipo:

  • HTTP Server + Application Server – una prima macchina che si occuperà di gestire tutte le richieste HTTP e del motore della business logic
  • DB Server – una seconda macchina che ospita il DBMS (MySql, DB2, ecc.).

Talvolta, però, la configurazione iniziale non basta, soprattutto in presenza di carichi di informazioni sempre crescenti (si pensi, ad esempio, ad un progetto che gestisca gli sportelli di una Banca, situati in più città o regioni, o ad un progetto che gestisca il processo di gestione dei curricula per una società di recruiting).


In tali sistemi che sono particolarmente complessi in termini sia di numero che entità di transazioni concorrenti le parole d'ordine sono tre:

  • scalabilità, cioè la capacità di un sistema di crescere e decrescere in funzione delle mutate esigenze senza stravolgere l'architettura originaria
  • affidabilità, cioè la capacità di preservare il funzionamento dell'intero sistema anche in caso di guasti di uno o più dei sottosistemi
  • elevate prestazioni, cioè garantire tempi di risposta costanti al crescere degli utenti concorrenti.

In termini di infrastruttura, è possibile immaginare l’estensione dell’architettura secondo diverse direttrici:

  1. aumentando i server di front-end (App Server) e gestendo la suddivisione del carico attraverso un load balancer (o un cluster di load balancer) con strategia sticky;
  2. implementando meccanismi di caching in modo da ottenere un ulteriore e significativo incremento delle prestazioni. Tali cache possono essere implementate ad esempio a livello di accesso ai dati (cache di primo e secondo livello di Hibernate);
  3. implementando un server di clustering di oggetti condivisi (Terracotta Server). Gli oggetti che potrebbero essere interessati a questa condivisione tra gli App Server di front-end sono:
  • le indicizzazioni (ottenute, ad esempio, tramite Lucene)
  • HTTPSession
  • cache (gestite tramite EHCache)
  • POJO di Spring
  • le cache di Hibernate

Gli oggetti vengono condivisi in maniera trasparente tra i singoli App Server; il server Terracotta in fase di creazione, modifica e cancellazione dei singoli oggetti condivisi si occuperà di aggiornare tutti gli App Server mantenendo la coerenza dell'intero cluster.

Il server Terracotta potrebbe essere anche implementato sotto forma di array di server. Uno solo di questi server è attivo e gli altri vivono in modalità “passive” in attesa di eventuali failure di quello attivo.

Lo sviluppo futuro dell’architettura potrebbe, dunque, essere rappresentato con la seguente figura:

La realizzazione di una simile infrastruttura garantisce scalabilità (è possibile aggiungere ad esempio numerosi server di front-end), affidabilità (nessun nodo è indispensabile) e elevate prestazioni (non ci sono colli di bottiglia). Grazie all’implementazione di un server Terracotta, infine, non è necessaria la riscrittura della business logic ma l’installazione di librerie di condivisione (TC LIB) sui singoli server di front-end.

Web application. Scarica la case history!

Meetweb realizza web application personalizzate. Guarda quelle che abbiamo già realizzato per i nostri clienti.

Articoli correlati

Scrivi un commento

* I campi con l'asterisco sono obbligatori