宇航资讯

低代码开发平台—Mendix架构体系概述(三) 完结篇

2021/04/12 04:04:06

Runtime Architecture


什么是Mendix Runtime? 它如何支持关键架构原则?

Mendix Runtime在云原生架构的上下文中执行您的应用程序。在本节中,我们将介绍Mendix Runtime的核心组件及其相关功能, 我们还将深入研究Runtime执行的几个重要方面。

01


哪个组件负责模型的执行?

Mendix Runtime解释并执行应用程序的模型。Runtime采用业界领先的Java和Scala技术的12-Factor App兼容设计。


02


Mendix是如何执行模型的?

Mendix运行时直接执行模型,这意味着模型是应用程序,而不是中介。与可视化建模设计实际生成代码的方法(例如Java或.NET)不同,Mendix模型解释方法具有许多独特的特征和优点,如下所述。

1

变更管理

能够更容易地适应应用程序的更改。另外,由于模型就是应用程序,所以Mendix保证了应用程序和模型的兼容性。

2

自定义扩展

自定义代码扩展模型是自定义代码并将其包含在一致性检查中,而不是将自定义代码插入生成的代码中,因此更加优雅。Mendix的模型解释方法解决了代码生成的基本往返问题,即模型中的变更会与定制代码的扩展相冲突。此外,在生成的代码中没有自定义更改,即可以在不影响模型的情况下对平台的技术架构进行现代化,这意味着从技术创新中更容易获益且成本更低。

3

监测

与预先定义的检测参数相比,可以更加动态和灵活地对Runtime中应用程序行为的监测和分析进行设置。

4

调试

开发人员无需了解生成的代码与可视化模型的关系,在模型上就可完成调试和解决问题,无需在生成的代码上操作,因此对开发人员来说,调试和解决问题变得更加容易。


03


Mendix如何实现无状态架构?

为了确保可扩展性、性能和高可用性,Mendix实现了无状态Runtime;这意味着不管是先前的请求还是后续的请求,任何可用的Runtime实例都可以处理用户的请求。为了实现这一点,Runtime实例在用户请求期间具有状态。在请求结束时,所有已提交的状态都将被保存到数据库中;所有未提交的状态将与客户所需的其他数据一起返回给客户端。




Mendix Runtime的组件是什么?

Runtime由两个主要组件组成:

  • 客户端——web和移动客户端

  • Runtime服务器——处理服务器端逻辑的可扩展Runtime

1.jpg

01


服务器架构

Mendix服务器体系结构由多个组件组成,用于执行逻辑、管理数据、客户端通信以及实现安全性。下图概述了所有组件,并简要说明了它们的职责:

2.jpg


Mendix Runtime由以下组件组成:


  • Platform core – 负责应用程序的启动和关闭,且加载所需的库和扩展

  • Object cache – 处理对象的创建和删除

  • Session manager – 管理用户会话的创建,清理已注销或已废弃的会话

  • HTTP服务器 – 在Mendix Runtime中,用于处理来自Web和移动客户端的请求以及服务请求

  • Microflow engine – 执行微流和微流动

  • Data layer – 从应用程序数据库中持久存储并检索对象;且负责创建和更新保存数据所需的数据库结构:数据层支持大量不同的数据库,并且通过使用通用数据模型设计最佳实践来存储数据

  • Integration layer – 处理Web服务,REST API,应用程序服务和OData的传入和传出服务请求

  • Client API – 负责与Web和移动客户端的通信; 该API用于检索数据,保持数据更改和执行微流逻辑

  • Configuration API – Developer Portal和容器buildpack使用该JSON API来配置Runtime

  • Monitoring API – Developer Portal和容器buildpack使用该JSON API来检索监测指标

  • Custom APIs –该Java API用于扩展Mendix Runtime(例如,用于微流活动或实体侦听器)

02


客户端架构

Mendix Client由UI组件层、执行离线逻辑的逻辑层和离线存储的数据层组成,负责用户交互。

3.jpg

Mendix Client 由以下组件组成:


  • Communications layer——使用HTTP协议上的安全JSON与Mendix Runtime服务器交换元数据、会话管理和数据

  • Data layer——管理前端使用的数据;基于React-Flux模式处理状态并将更改推送给UI组件

  • Logic layer ——使用Mendix nanoflows处理数据验证和更复杂的逻辑

  • UI component layer——管理组件的生命周期和组件之间的通信,并提供开箱即用的组件

1

移动客户端

移动应用程序使用相同的HTML5-、CSS-和基于React的客户端架构,但它们使用Apache Cordova进行部署。这个框架让使用最先进的Web技术构建的移动应用程序能够提供出色的移动用户体验:


  • Accessibility – 可以在标准设备应用程序商店中找到应用程序,将其安装在移动设备上,并通过图标打开。

  • Offline availability – 由于应用程序安装在移动设备上(包括所有必需的资源与可能的缓存数据),最终用户可以离线使用Mendix应用程序,相关的应用程序数据缓存在设备上的SQLite数据库中。

  • Support for native functionality – JavaScript应用程序通过Apache Cordova使用本地设备功能,从而让您可以从移动设备中的所有传感器获益,例如照相机和麦克风。

2

Web客户端

Web客户端使用单页面架构,其中单个JavaScript Web页面被加载到浏览器中,然后浏览器将根据用户操作的要求更新页面并与Mendix Runtime交互。这可能包括部分Web页面的检索以及数据的检索和存储。


客户端主要使用HTML5,带Sass和Bootstrap的CSS以及React框架实现。 



图片

12-Factor Architecture



什么是12-Factor App应用方法?

尽管不是严格的一组架构原则,但12-Factor App方法是一组用于云原生应用程序的最佳实践。



Mendix Runtime如何支持12-Factor 云原生应用程序?

以下描述了Mendix如何遵循12-Factor App方法的要求。

01


代码库

默认情况下,使用Mendix构建的每个应用程序的源代码都被存储在Mendix Team Server的代码存储库中。部署应用程序时,将基于存储在Team Server中的模型创建程序包,并将其部署到不同的环境中,比如验收或生产。

02


依赖性

应用程序模块使用的所有依赖项(如模块和库)都属于它的一部分,这意味着环境中对工具不具有隐式依赖,保证了部署的可靠性。

03


配置

配置需求通过常量在应用程序模型中定义,您可以在环境中部署期间指定这些值,或者通过CI/CD管道中调用的API来指定。因为实际的配置值不属于模型的一部分,所以相同的部署包可以在无需更改应用程序模型的情况下,部署在任何环境中。

04


支持服务

所有外部需求(如存储应用程序数据的数据库)和从应用程序调用的服务都可以在部署时配置。与前面的需求一样,这确保了在任何条件下可以使用同一个经过测试的部署包,具有支持服务,且无需更改模型。

05


构建、发布、运行

如果在生产环境中可以修改代码,那么应用程序的扩展将变得不可预测且不可靠,从而使调试和解决问题变得更加困难。为了避免这个问题,Mendix平台明确地将构建和运行阶段区分开来。


在Mendix Developer Portal中,首先需在模型里构建一个数据包,然后将其部署到您的环境中。如果您想在产品中更改代码,则需修改您的模型,然后构建一个新的数据包。Mendix还提供用于构建和部署应用程序的API,因此您可以将此方法合并到自定义的CI/CD管道中。

06


流程

Mendix运行时是完全无状态的,通过数据库共享数据,确保了扩展以及恢复的可行性。

07


端口绑定

为了简化同一个应用程序在不同环境中的扩展和运行,该应用程序应该是自包含的(也就是说,它配置了接收客户端的请求)。Mendix应用程序在这种方式的配置下,使底层平台即服务(PaaS)——例如,Cloud foundry——能够轻松地扩展其托管的应用程序的容器数量。

08


并发

Mendix使用Java线程和流程的组合来扩展最终用户的需求。12-Factor App方法强调通过流程进行扩展的必要性;否则,您的扩展需求将被限制在一个Java虚拟机(JVM)所能支持的最大范围内(垂直扩展)。通过流程的扩展,您可以很轻松地添加额外的资源(水平扩展)。

09


可处置性

Mendix Runtime实例可以根据需要停止和启动。在多实例环境中,用户通常很难察觉到Runtime实例是否重启了;这样让水平扩展变得更简单、更快,新版本或新配置的部署也会更快。

10


开发和生产保价

为了保证质量,部署在测试环境中的应用程序行为与在生产环境中的行为应该一致。在Mendix Cloud中,所有环境是相同的,唯一的区别是配置、数据以及应用程序。数据可以通过备份和恢复在环境之间移动,从而保证代表性数据的测试。

11


日志

Mendix Cloud使用Cloud Foundry firehose收集所有应用程序的日志事件,并且能在Mendix Developer Portal中查看与筛选。

12


流程管理

为了避免同步问题,12-Factor App方法建议将管理代码与应用程序代码一起传送。Mendix采取了这种做法,因此唯一在应用程序环境中运行的代码就是属于该应用程序一部分的代码。换句话说,您需要将管理代码作为模型的一部分。用户通常在管理页面中通过管理逻辑来实现此功能:在应用程序启动后执行微流,或者创建API来触发管理操作。





关于Mendix

Mendix,a Siemens business是全球企业级低代码的领导者,正在从根本上重塑数字化企业构建应用的方式。企业可通过Mendix低代码软件快速开发平台来扩展自身的开发能力,打破软件开发的瓶颈。借助Mendix开发平台,企业可以打造具备智能、主动性和人机互动等原生体验的智能化应用,对核心系统进行现代化升级并实现规模化应用开发,以跟上业务增长的速度。Mendix低代码软件快速开发平台可在保持最高安全、质量和治理标准的前提下,促进业务与IT团队之间的密切合作,大大缩短应用开发周期,帮助企业自信迈向数字化未来。Mendix的“Go Make It”平台已被全球4000多家领先公司采用。


快速链接
»产品中心
»方案中心
»新闻中心
»视频中心
联系我们
咨询热线: 400-930-1658
宇航总部: 0755-66858836
邮箱地址: service@u-infor.com
总部地址:深圳市龙岗区布吉李朗创新软件园C5栋3楼3045-3048
关注我们

官方微信

西门子铂金合作伙伴&Expert Partner