Piattaforma HIT4B3 - Architettura
Scopri la rivoluzionaria architettura della piattaforma HIT4B3
Moderno modello multiprocesso
Nell'architettura tradizionale (precedente) dei sistemi server, il server applicativo consisteva in un singolo processo e più thread. Un singolo processo poteva essere un file eseguibile o un processo worker ISAPI, Apache o eventualmente un servizio Windows. In tutti questi casi, tutte le sessioni risiedevano in un unico processo e diversi thread dello stesso processo venivano utilizzati per gestire le richieste in entrata.
L'architettura HyperServer cambia il modello sopra descritto e lo introduce in un modello multiprocesso e multithread. In questo nuovo modello, vengono avviati diversi processi worker che supportano la stessa applicazione web. Le sessioni sono divise tra i processi worker e, a seconda della configurazione, possono essere creati/esistere più processi worker per la stessa weblication. I processi worker sono gestiti e coordinati da un altro processo, che è in realtà l'HyperServer stesso.
Punto di ingresso
HyperServer sarà il punto di ingresso principale per tutte le richieste in entrata. Accetta tutte le richieste e le distribuisce tra i processi worker.
Gestione dei nodi
HyperServer è responsabile della creazione di nuovi processi worker (nodi) quando necessario e del loro riprocessamento.
Instradamento delle sessioni
Poiché le sessioni HIT4B3 sono stateful, HyperServer instrada le richieste in entrata al processo worker corretto che ha creato quella particolare sessione.
Miglioramento della stabilità e delle prestazioni
L'architettura HyperServer applicata mira a migliorare drasticamente la stabilità. HyperServer raggiunge questo obiettivo implementando vari meccanismi: bilanciamento del carico interno e riciclo dei nodi. Il bilanciamento del carico distribuisce il carico totale del server tra i nodi.
Il riciclo dei nodi accorcia il ciclo di vita dei nodi riciclandoli in base a regole predefinite. Il riciclo assicura che i nodi rimangano nello spazio di memoria del processo solo per un tempo specificato. Al contrario del modello classico, che mantiene il processo del server applicativo in memoria indefinitamente.
Il compito principale di HyperServer è garantire che l'intero server applicativo non si blocchi a causa di un difetto di memoria o di un altro problema in un nodo (Node).
Struttura del sistema
L'architettura HyperServer è divisa in due parti principali:
- File eseguibile HyperServer - punto di ingresso per l'applicazione web, che gestisce le richieste dei clienti.
- Cluster di nodi - weblication componenti di HIT4B3 (es. EKAIZEN).
Distribuzione remota e continuità operativa
Un'altra funzione di HyperServer è la possibilità di distribuire in remoto nuove versioni delle weblication senza dover arrestare il server. Ciò garantisce la continuità operativa nel modello 24/7/365.
È possibile caricare in remoto una nuova versione della weblication e HyperServer aggiornerà gradualmente e automaticamente i nodi. Le nuove sessioni andranno alla nuova versione e i vecchi nodi verranno rimossi non appena tutte le loro sessioni saranno terminate.
Aggiungendo lo strato di accesso ai dati, implementato utilizzando un server di database standard SQL (nella nostra implementazione è Firebird Database Server), otteniamo un quadro completo dell'architettura dell'intero sistema HIT4B3.