Plataforma HIT4B3 - Arquitectura
Conozca la revolucionaria arquitectura de la plataforma HIT4B3
Modelo multiproceso moderno
En la arquitectura tradicional (anterior) de los sistemas de servidor, el servidor de aplicaciones consistía en un solo proceso y múltiples hilos. Un solo proceso podía ser un archivo ejecutable o un proceso de trabajo ISAPI, Apache o, posiblemente, un servicio de Windows. En todos estos casos, todas las sesiones se encontraban en un solo proceso y se utilizaban varios hilos del mismo proceso para atender las solicitudes entrantes.
La arquitectura HyperServer cambia el modelo anterior y lo introduce en un modelo multiproceso y multihilo. En este nuevo modelo, se inician varios procesos de trabajo, que admiten la misma aplicación web. Las sesiones se dividen entre los procesos de trabajo y, según la configuración, se pueden crear o pueden existir varios procesos de trabajo para la misma weblication. Los procesos de trabajo son gestionados y coordinados por otro proceso, que es en realidad el propio HyperServer.
Punto de entrada
HyperServer será el punto de entrada principal para todas las solicitudes entrantes. Acepta todas las solicitudes y las distribuye entre los procesos de trabajo.
Gestión de nodos
HyperServer es responsable de crear nuevos procesos de trabajo (nodos) cuando sea necesario y de volver a procesarlos.
Enrutamiento de sesiones
Dado que las sesiones de HIT4B3 tienen estado, HyperServer dirige las solicitudes entrantes al proceso de trabajo correcto que creó esa sesión en particular.
Mejora de la estabilidad y el rendimiento
La arquitectura HyperServer aplicada tiene como objetivo mejorar drásticamente la estabilidad. HyperServer logra este objetivo mediante la implementación de varios mecanismos: equilibrio de carga interno y reciclaje de nodos. El equilibrio de carga distribuye la carga total del servidor entre los nodos.
El reciclaje de nodos acorta el ciclo de vida de los mismos al reciclarlos según reglas predefinidas. El reciclaje garantiza que los nodos solo residirán en el espacio de memoria del proceso durante un tiempo específico. Al diferencia del modelo clásico, que mantiene el proceso del servidor de aplicaciones en memoria indefinidamente.
La tarea principal de HyperServer es asegurarse de que todo el servidor de aplicaciones no falle como resultado de un defecto de memoria u otro problema en un nodo (Node).
Estructura del sistema
La arquitectura HyperServer se divide en dos partes principales:
- Archivo ejecutable de HyperServer - punto de entrada para la aplicación web, que gestiona las solicitudes de los clientes.
- Clúster de nodos - weblications componentes de HIT4B3 (p. ej., EKAIZEN).
Despliegue remoto y continuidad del trabajo
Otra función de HyperServer es la posibilidad de desplegar de forma remota nuevas versiones de weblications sin tener que detener el servidor. Esto garantiza la continuidad del trabajo en el modelo 24/7/365.
Se puede cargar de forma remota una nueva versión de la weblication y HyperServer actualizará gradual y automáticamente los nodos. Las nuevas sesiones irán a la nueva versión y los nodos antiguos se eliminarán tan pronto como se cierren todas sus sesiones.
Al añadir la capa de acceso a los datos, implementada mediante un servidor de base de datos estándar SQL (en nuestra implementación es Firebird Database Server), obtenemos una imagen completa de la arquitectura de todo el sistema HIT4B3.