Plateforme HIT4B3 - Architecture
Découvrez l'architecture révolutionnaire de la plateforme HIT4B3
Modèle multiprocessus moderne
Dans l'architecture traditionnelle (précédente) des systèmes serveurs, le serveur d'application consistait en un processus unique et plusieurs threads. Un processus unique pouvait être un fichier exécutable ou un processus de travail ISAPI, Apache ou éventuellement un service Windows. Dans tous ces cas, toutes les sessions résidaient dans un processus unique, et plusieurs threads du même processus étaient utilisés pour gérer les requêtes entrantes.
L'architecture HyperServer modifie le modèle ci-dessus et l'introduit dans un modèle multiprocessus et multithread. Dans ce nouveau modèle, plusieurs processus de travail sont lancés, prenant en charge la même application web. Les sessions sont réparties entre les processus de travail et, selon la configuration, plusieurs processus de travail peuvent être créés/exister pour la même weblication. Les processus de travail sont gérés et coordonnés par un autre processus, qui est en réalité l'HyperServer lui-même.
Point d'entrée
HyperServer sera le point d'entrée principal pour toutes les requêtes entrantes. Il accepte toutes les requêtes et les distribue entre les processus de travail.
Gestion des nœuds
HyperServer est responsable de la création de nouveaux processus de travail (nœuds) en cas de besoin et de leur retraitement.
Routage des sessions
Étant donné que les sessions HIT4B3 sont avec état, HyperServer achemine les requêtes entrantes vers le processus de travail correct qui a créé cette session particulière.
Amélioration de la stabilité et des performances
L'architecture HyperServer appliquée vise à améliorer considérablement la stabilité. HyperServer atteint cet objectif en mettant en œuvre divers mécanismes : équilibrage de charge interne et recyclage des nœuds. L'équilibrage de charge répartit la charge totale du serveur entre les nœuds.
Le recyclage des nœuds raccourcit le cycle de vie des nœuds en les recyclant selon des règles prédéfinies. Le recyclage garantit que les nœuds ne résideront dans l'espace mémoire du processus que pendant une durée spécifiée. Contrairement au modèle classique, qui maintient le processus du serveur d'application en mémoire indéfiniment.
La tâche principale d'HyperServer est de s'assurer que l'ensemble du serveur d'application ne plante pas à la suite d'un défaut de mémoire ou d'un autre problème dans un nœud (Node).
Structure du système
L'architecture HyperServer est divisée en deux parties principales :
- Fichier exécutable HyperServer - point d'entrée pour l'application web, gérant les requêtes des clients.
- Cluster de nœuds - weblications composantes de HIT4B3 (ex. EKAIZEN).
Déploiement à distance et continuité d'activité
Une autre fonction de HyperServer est la possibilité de déployer à distance de nouvelles versions de weblications sans avoir à arrêter le serveur. Cela garantit la continuité d'activité dans le modèle 24/7/365.
Vous pouvez télécharger à distance une nouvelle version de la weblication, et HyperServer mettra à jour progressivement et automatiquement les nœuds. Les nouvelles sessions iront vers la nouvelle version, et les anciens nœuds seront supprimés dès que toutes leurs sessions seront terminées.
En ajoutant la couche d'accès aux données, implémentée à l'aide d'un serveur de base de données standard SQL (dans notre implémentation, il s'agit de Firebird Database Server), nous obtenons une image complète de l'architecture de l'ensemble du système HIT4B3.