Bienvenido a leer "Descripción general del sistema de arquitectura Mendix (1)" y "Descripción general del sistema de arquitectura Mendix (2)" Este capítulo explicará la arquitectura de tiempo de ejecución y la arquitectura de 12 factores de Mendix.

Arquitectura en tiempo de ejecución

¿Qué es Mendix Runtime? ¿Cómo es compatible con los principios arquitectónicos clave?

Mendix Runtime ejecuta su aplicación en el contexto de la arquitectura nativa de la nube. En esta sección, presentaremos los componentes centrales y las funciones relacionadas de Mendix Runtime, y también profundizaremos en varios aspectos importantes de la ejecución de Runtime.

01. ¿Qué componente es responsable de la ejecución del modelo?

Mendix Runtime interpreta y ejecuta el modelo de la aplicación. Runtime adopta un diseño compatible con la aplicación de 12 factores líder en la industria de la tecnología Java y Scala.

02. ¿Cómo ejecuta Mendix el modelo?

Mendix ejecuta el modelo directamente en tiempo de ejecución, lo que significa que el modelo es una aplicación, no un intermediario. A diferencia del método de diseño y modelado visual que realmente genera código (como Java o .NET), el método de interpretación del modelo de Mendix tiene muchas características y ventajas únicas, como se describe a continuación.

1. Gestión de cambios

Puede adaptarse más fácilmente a los cambios de aplicación. Además, dado que el modelo es una aplicación, Mendix garantiza la compatibilidad de la aplicación y el modelo.

2. Extensión personalizada

El modelo de extensión de código personalizado es personalizar el código e incluirlo en la verificación de coherencia, en lugar de insertar el código personalizado en el código generado, por lo que es más elegante. El método de interpretación del modelo de Mendix resuelve el problema básico de ida y vuelta de la generación de código, es decir, los cambios en el modelo entrarán en conflicto con la extensión del código personalizado. Además, no existen cambios personalizados en el código generado, es decir, la arquitectura técnica de la plataforma se puede modernizar sin afectar el modelo, lo que significa que es más fácil beneficiarse de la innovación tecnológica y a un menor costo.

3. Seguimiento

En comparación con los parámetros de detección predefinidos, la supervisión y el análisis del comportamiento de la aplicación en Runtime se pueden configurar de forma más dinámica y flexible.

4. Depuración

Los desarrolladores no necesitan comprender la relación entre el código generado y el modelo visual, y pueden depurar y resolver el problema en el modelo, sin operar en el código generado, por lo que es más fácil para el desarrollador depurar y resolver el problema.

03. ¿Cómo implementa Mendix una arquitectura sin estado?

Para garantizar la escalabilidad, el rendimiento y la alta disponibilidad, Mendix implementa un Runtime sin estado; esto significa que no importa si se trata de una solicitud anterior o posterior, cualquier instancia de Runtime disponible puede manejar las solicitudes de los usuarios. Para lograr esto, la instancia de Runtime tiene estado durante la solicitud del usuario. Al final de la solicitud, todos los estados enviados se guardarán en la base de datos; todos los estados no enviados se devolverán al cliente junto con otros datos requeridos por el cliente.

¿Cuáles son los componentes de Mendix Runtime?

El tiempo de ejecución consta de dos componentes principales:

Cliente- cliente web y móvil
Servidor en tiempo de ejecución: tiempo de ejecución escalable que maneja la lógica del lado del servidor

01. Arquitectura del servidor

La arquitectura del servidor Mendix consta de varios componentes para ejecutar la lógica, administrar los datos, la comunicación con el cliente y la implementación de la seguridad. El siguiente diagrama describe todos los componentes y explica brevemente sus responsabilidades:

Mendix Runtime consta de los siguientes componentes:

Núcleo de la plataforma: responsable del inicio y apagado de la aplicación, y de la carga de las bibliotecas y extensiones necesarias.
Caché de objetos: maneja la creación y eliminación de objetos
Administrador de sesiones: gestiona la creación de sesiones de usuario, limpia las sesiones desconectadas o abandonadas
Servidor HTTP: en Mendix Runtime, se utiliza para procesar solicitudes de clientes web y móviles y solicitudes de servicio.
Motor de microflujo : realice microflujo y microflujo
Capa de datos : almacenamiento y recuperación persistentes de objetos de la base de datos de la aplicación; y responsable de crear y actualizar la estructura de la base de datos necesaria para guardar los datos: la capa de datos admite una gran cantidad de bases de datos diferentes y almacena datos utilizando el mejor diseño de modelo de datos común. practicas
Capa de integración : maneja las solicitudes de servicio entrantes y salientes para servicios web, API REST, servicios de aplicaciones y OData
API de cliente: responsable de la comunicación con clientes web y móviles; esta API se utiliza para recuperar datos, mantener cambios de datos y ejecutar lógica de micro-flujo
API de configuración: el portal del desarrollador y el paquete de compilación de contenedores utilizan esta API JSON para configurar el tiempo de ejecución
API de supervisión: el portal de desarrolladores y el paquete de compilación de contenedores utilizan esta API JSON para recuperar métricas de supervisión
API personalizadas: esta API de Java se utiliza para extender el tiempo de ejecución de Mendix (por ejemplo, para actividades de micro-flujo o escuchas de entidades)

02. Arquitectura del cliente

Mendix Client está compuesto por la capa del componente UI, la capa lógica que ejecuta la lógica fuera de línea y la capa de datos que se almacena fuera de línea y es responsable de la interacción del usuario.

Mendix Client consta de los siguientes componentes:

Capa de comunicaciones: utilice JSON seguro sobre el protocolo HTTP para intercambiar metadatos, administración de sesiones y datos con el servidor Mendix Runtime.
Capa de datos : administre los datos utilizados por el front-end; procese el estado según el modelo React-Flux y envíe los cambios a los componentes de la interfaz de usuario.
Capa lógica: utilice nanoflujos de Mendix para manejar la validación de datos y una lógica más compleja
Capa de componentes de la interfaz de usuario: gestiona el ciclo de vida de los componentes y la comunicación entre los componentes, y proporciona componentes listos para usar.

1. Cliente móvil

Las aplicaciones móviles usan la misma arquitectura del lado del cliente basada en HTML5, CSS y React, pero usan Apache Cordova para la implementación. Este marco permite que las aplicaciones móviles creadas con las tecnologías web más avanzadas brinden una excelente experiencia de usuario móvil:

Accesibilidad: la aplicación se puede encontrar en la tienda de aplicaciones del dispositivo estándar, se puede instalar en el dispositivo móvil y se puede abrir mediante el icono.
Disponibilidad sin conexión: desde que la aplicación está instalada en el dispositivo móvil (incluidos todos los recursos necesarios y los posibles datos almacenados en caché), el usuario final puede usar la aplicación Mendix sin conexión y los datos de la aplicación relacionados se almacenan en caché en la base de datos SQLite del dispositivo.
Compatibilidad con la funcionalidad nativa : las aplicaciones JavaScript utilizan la funcionalidad del dispositivo nativo a través de Apache Cordova, lo que le permite beneficiarse de todos los sensores de su dispositivo móvil, como cámaras y micrófonos.

2. Cliente web

El cliente web utiliza una arquitectura de página única, donde se carga una sola página web JavaScript en el navegador, y luego el navegador actualizará la página e interactuará con Mendix Runtime de acuerdo con los requisitos de la operación del usuario. Esto puede incluir la recuperación de algunas páginas web y la recuperación y almacenamiento de datos.

El cliente se implementa principalmente utilizando HTML5, CSS con Sass y Bootstrap y el marco React.

Arquitectura de 12 factores

¿Cuál es el método de aplicación de la aplicación 12-Factor?

Aunque no es un conjunto estricto de principios arquitectónicos, el enfoque de la aplicación de 12 factores es un conjunto de mejores prácticas para aplicaciones nativas de la nube.

¿Cómo admite Mendix Runtime las aplicaciones nativas en la nube de 12 factores?

A continuación se describe cómo Mendix sigue los requisitos del método de la aplicación de 12 factores.

01. Biblioteca de códigos

De forma predeterminada, el código fuente de cada aplicación creada con Mendix se almacena en el repositorio de códigos de Mendix Team Server. Al implementar una aplicación, se creará un paquete basado en el modelo almacenado en Team Server y se implementará en diferentes entornos, como aceptación o producción.

02. Dependencia

Todas las dependencias (como módulos y bibliotecas) utilizadas por los módulos de la aplicación son parte de ella, lo que significa que no hay dependencias implícitas de las herramientas en el entorno, lo que garantiza la confiabilidad de la implementación.

03. Configuración

Los requisitos de configuración se definen en el modelo de aplicación a través de constantes, y puede especificar estos valores durante la implementación en el entorno o mediante API llamadas en la canalización de CI / CD. Debido a que los valores de configuración reales no forman parte del modelo, el mismo paquete de implementación se puede implementar en cualquier entorno sin cambiar el modelo de la aplicación.

04. Servicio de soporte

Todos los requisitos externos (como una base de datos que almacena datos de la aplicación) y los servicios llamados desde la aplicación se pueden configurar en el momento de la implementación. Al igual que con los requisitos anteriores, esto garantiza que el mismo paquete de implementación probado se pueda utilizar en todas las condiciones, con servicios de soporte, y no se requieren cambios de modelo.

05. Construya, libere y ejecute

Si el código se puede modificar en un entorno de producción, la extensión de la aplicación se volverá impredecible y poco confiable, lo que dificultará la depuración y la resolución de problemas. Para evitar este problema, la plataforma Mendix separa claramente las fases de construcción y ejecución.

En el portal para desarrolladores de Mendix, primero debe crear un paquete de datos en el modelo y luego implementarlo en su entorno. Si desea cambiar el código en el producto, debe modificar su modelo y luego crear un nuevo paquete de datos. Mendix también proporciona API para crear e implementar aplicaciones, por lo que puede incorporar este método en una canalización de CI / CD personalizada.

06. Proceso

Mendix es completamente sin estado en tiempo de ejecución, compartiendo datos a través de la base de datos para garantizar la viabilidad de expansión y recuperación.

07 . Puerto Encuadernación

Para simplificar la expansión y el funcionamiento de la misma aplicación en diferentes entornos, la aplicación debe ser autónoma (es decir, estar configurada para recibir solicitudes de clientes). La aplicación Mendix se configura de esta manera, lo que permite que la plataforma subyacente como servicio (PaaS), por ejemplo, la fundición en la nube, expanda fácilmente el número de contenedores de sus aplicaciones alojadas.

08 . Concurrente

Mendix utiliza una combinación de procesos y subprocesos de Java para ampliar las necesidades de los usuarios finales. El método de la aplicación de 12 factores enfatiza la necesidad de expansión a través del proceso; de lo contrario, sus necesidades de expansión se limitarán al rango máximo que una máquina virtual Java (JVM) puede admitir (expansión vertical). Mediante la expansión del proceso, puede agregar fácilmente recursos adicionales (expansión horizontal).

09. Desechabilidad

Las instancias de Mendix Runtime se pueden detener e iniciar según sea necesario. En un entorno de múltiples instancias, generalmente es difícil para los usuarios detectar si la instancia de Runtime se ha reiniciado; esto hace que la expansión horizontal sea más fácil y rápida, y la implementación de nuevas versiones o nuevas configuraciones será más rápida.

10. Precio asegurado de desarrollo y producción

Para garantizar la calidad, el comportamiento de la aplicación implementada en el entorno de prueba debe ser coherente con el comportamiento en el entorno de producción. En Mendix Cloud, todos los entornos son iguales, la única diferencia es la configuración, los datos y las aplicaciones. Los datos se pueden mover entre entornos a través de la copia de seguridad y la recuperación, lo que garantiza la prueba de datos representativos.

11 . Conectarse

Mendix Cloud usa Cloud Foundry Firehose para recopilar eventos de registro de todas las aplicaciones, y se puede ver y filtrar en el Portal para desarrolladores de Mendix.

12 . Gestión de Procesos

Para evitar problemas de sincronización, el método de la aplicación 12-Factor recomienda transferir el código de gestión junto con el código de la aplicación. Mendix adoptó este enfoque, por lo que el único código que se ejecuta en el entorno de la aplicación es el código que forma parte de la aplicación. En otras palabras, debe administrar el código como parte del modelo. Los usuarios generalmente implementan esta función a través de la lógica de administración en la página de administración: ejecutan microflujos después de que se inicia la aplicación o crean API para desencadenar operaciones de administración.

Para obtener más información, visite el siguiente enlace:

Sitio web oficial de Mendix: https://www.mendix.com/zh/

Soluciones industriales de Mendix: https://solutions.mendix.com/

Guía de la plataforma Mendix: https://www.mendix.com/evaluation-guide/

Pantalla de animación de Mendix: https://www.mendix.com/demos/

Cuenta pública Mendix

Descripción general del sistema de arquitectura Mendix (tres): el final