HIT4B3-Plattform - Architektur
Lernen Sie die revolutionäre Architektur der HIT4B3-Plattform kennen
Modernes Multiprozessmodell
In der traditionellen (bisherigen) Architektur von Serversystemen bestand der Anwendungsserver aus einem einzigen Prozess und mehreren Threads. Ein einzelner Prozess konnte eine ausführbare Datei oder ein ISAPI-, Apache-Worker-Prozess oder möglicherweise ein Windows-Dienst sein. In all diesen Fällen befanden sich alle Sitzungen in einem Prozess, und mehrere Threads desselben Prozesses wurden zur Bearbeitung eingehender Anfragen verwendet.
Die HyperServer-Architektur ändert das obige Modell und führt es in ein Multiprozess-, Multithread-Modell ein. In diesem neuen Modell werden mehrere Worker-Prozesse gestartet, die dieselbe Webanwendung unterstützen. Sitzungen werden auf Worker-Prozesse verteilt und je nach Konfiguration können mehrere Worker-Prozesse für dieselbe Weblication erstellt werden/existieren. Worker-Prozesse werden von einem anderen Prozess verwaltet und koordiniert, der eigentlich der HyperServer selbst ist.
Einstiegspunkt
HyperServer wird der Haupt-Einstiegspunkt für alle eingehenden Anfragen sein. Er nimmt alle Anfragen entgegen und verteilt sie auf die Worker-Prozesse.
Knotenverwaltung
HyperServer ist dafür verantwortlich, bei Bedarf neue Worker-Prozesse (Knoten) zu erstellen und diese erneut zu verarbeiten.
Sitzungsrouting
Da HIT4B3-Sitzungen zustandsbehaftet sind, leitet HyperServer eingehende Anfragen an den richtigen Worker-Prozess weiter, der diese spezielle Sitzung erstellt hat.
Verbesserung von Stabilität und Leistung
Die angewandte HyperServer-Architektur zielt darauf ab, die Stabilität drastisch zu verbessern. HyperServer erreicht dieses Ziel durch die Implementierung verschiedener Mechanismen: es gibt einen internen Lastausgleich und ein Knoten-Recycling. Der Lastausgleich verteilt die gesamte Serverlast auf die Knoten.
Knoten-Recycling verkürzt den Lebenszyklus von Knoten, indem sie auf der Grundlage vordefinierter Regeln recycelt werden. Das Recycling stellt sicher, dass sich Knoten nur für eine bestimmte Zeit im Prozessspeicherbereich befinden. Im Gegensatz zum klassischen Modell, das den Anwendungsserverprozess unbegrenzt im Speicher hält.
Die Hauptaufgabe von HyperServer besteht darin, sicherzustellen, dass der gesamte Anwendungsserver nicht infolge eines Speicherfehlers oder eines anderen Problems in einem Knoten (Node) abstürzt.
Systemstruktur
Die HyperServer-Architektur ist in zwei Hauptteile unterteilt:
- Ausführbare HyperServer-Datei - Einstiegspunkt für die Webanwendung, die Client-Anfragen bearbeitet.
- Knoten-Cluster - HIT4B3-Komponenten-Weblications (z. B. EKAIZEN).
Remote-Bereitstellung und Betriebskontinuität
Eine weitere Funktion von HyperServer ist die Möglichkeit, neue Versionen von Weblications remote bereitzustellen, ohne den Server stoppen zu müssen. Dies gewährleistet die Betriebskontinuität im Modell 24/7/365.
Sie können eine neue Version der Weblication remote hochladen, und HyperServer wird die Knoten schrittweise und automatisch aktualisieren. Neue Sitzungen werden an die neue Version geleitet, und alte Knoten werden entfernt, sobald alle ihre Sitzungen abgemeldet sind.
Fügt man die Datenzugriffsschicht hinzu, die mit einem SQL-Standard-Datenbankserver (in unserer Implementierung ist dies der Firebird Database Server) realisiert wird, erhält man ein vollständiges Bild der Architektur des gesamten HIT4B3-Systems.