Platforma HIT4B3 - Architektura
Zapoznaj się z rewolucyjną architekturą platformy HIT4B3
Nowoczesny model wieloprocesowy
W tradycyjnej (dotychczasowej) architekturze systemów serwerowych, serwer aplikacji składał się z jednego procesu i wielu wątków. Pojedynczy proces mógł być plikiem wykonywalnym lub procesem roboczym ISAPI, Apache czy ewentualnie usługą systemu Windows. We wszystkich tych przypadkach, wszystkie sesje znajdowały się w jednym procesie, a kilka wątków tego samego procesu było używanych do obsługi przychodzących żądań.
Architektura HyperServer zmienia powyższy model i wprowadza go w model wieloprocesowy, wielowątkowy. W tym nowym modelu uruchamianych jest kilka procesów roboczych, obsługujących tę samą aplikację internetową. Sesje są podzielone pomiędzy procesy robocze i w zależności od konfiguracji, może powstać / istnieć wiele procesów roboczych dla tej samej weblikacji. Procesy robocze są zarządzane i koordynowane przez inny proces, którym w rzeczywistości jest sam HyperServer.
Punkt wejścia
HyperServer będzie głównym punktem wejścia dla wszystkich przychodzących żądań. Przyjmuje on wszystkie żądania i rozdziela je pomiędzy procesami roboczymi.
Zarządzanie węzłami
HyperServer jest odpowiedzialny za tworzenie nowych procesów roboczych (węzłów), gdy jest to potrzebne, i ponowne ich przetwarzanie.
Kierowanie sesji
Ponieważ sesje HIT4B3 są stanowe, HyperServer kieruje przychodzące żądania do właściwego procesu roboczego, który utworzył daną sesję.
Poprawa stabilności i wydajności
Zastosowana architektura HyperServer ma na celu drastyczną poprawę stabilności. HyperServer osiąga ten cel poprzez wdrożenie różnych mechanizmów: jest wewnętrzne równoważenie obciążenia i recykling węzłów. Równoważenie obciążenia rozdziela całkowite obciążenie serwera pomiędzy węzłami.
Recykling węzłów skraca cykl życia węzłów poprzez ich recykling w oparciu o wcześniej zdefiniowane zasady. Recykling zapewnia, że węzły będą znajdować się w przestrzeni pamięci procesu tylko przez określony czas. W przeciwieństwie do klasycznego modelu, który utrzymuje proces serwera aplikacji w pamięci przez czas nieokreślony.
Głównym zadaniem HyperServera jest upewnienie się, że cały serwer aplikacji nie ulegnie awarii w wyniku defektu pamięci lub innego problemu w węźle (Node).
Struktura systemu
Architektura HyperServer jest podzielona na dwie zasadnicze części:
- Plik wykonywalny HyperServer - punkt wejścia dla aplikacji internetowej, obsługujący żądania klientów.
- Klaster węzłów - weblikacje składowe HIT4B3 (np. EKAIZEN).
Zdalne wdrażanie i ciągłość pracy
Kolejną funkcją HyperServera jest możliwość zdalnego wdrażania nowych wersji weblikacji bez konieczności zatrzymywania serwera. Zapewnia to ciągłość pracy w modelu 24/7/365.
Można zdalnie załadować nową wersję weblikacji, a HyperServer stopniowo i automatycznie zaktualizuje węzły. Nowe sesje trafią do nowej wersji, a stare węzły zostaną usunięte po wylogowaniu wszystkich użytkowników.
Dodając do tego warstwę dostępu do danych, realizowaną za pomocą serwera bazy danych w standardzie SQL (w naszej implementacji jest to Firebird Database Server), uzyskujemy pełny obraz architektury całego systemu HIT4B3.