Mendix 的十二要素云原生应用程序支持 | Mendix 评估指南

Skip navigation

Twelve-Factor Architecture

什么是十二要素应用程序方法?

尽管十二要素应用程序方法还未形成一套严格的架构原则,但这一方法是一套行之有效的云原生应用程序最佳实践。

Mendix Runtime 如何支持十二要素云原生应用程序?

以下章节描述了 Mendix 如何满足十二要素应用程序方法要求。

  • 代码库

    默认情况下,通过 Mendix 创建的每个应用程序的源代码都存储在 Mendix Team Server 代码存储库中。在您部署应用程序时,系统会基于这些存储在 Team Server 中的模型创建一个程序包。这个程序包可以部署到您用于验收或生产等不同的环境中。

  • 依赖项

    应用程序模块使用的所有依赖项(例如模块和库)都是应用程序模型的一部分。这意味着您的环境中不存在对工具的隐性依赖关系,这样可以确保部署的可靠性。

  • 配置

    配置需求可通过常量在您的应用程序模型中来定义。这些值可以在部署时通过环境来指定,也可以通过在 CI/CD 通道中调用的 API 来指定。实际的配置值不是模型的组成部分,这意味着相同的部署包可以部署到任何环境中,无需更改应用程序模型。

  • 支持服务

    所有外部需求(例如用于存储应用程序数据的数据库)和将从应用程序中调用的服务均可在部署时配置。和之前的需求一样,这样可确保相同的经过测试的部署包可用于任何情况和任何支持服务,无需更改模型。

  • 构建、发布、运行

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

    在 Mendix 开发人员门户中,您需要先根据模型构建一个程序包,然后将其部署到您的环境中。如果要在生产中更改代码,则必须修改模型,然后构建新的程序包。Mendix 还提供 API 用于构建和部署应用程序,这样就可以将这种方法合并到自定义 CI/CD 通道中。

  • 流程

    Mendix Runtime 是完全无状态的,它通过数据库共享数据,确保轻松实现可扩展性和韧性。

  • 端口绑定

    为了简化同一应用程序在不同环境中的扩展和运行,应用程序必须相对独立(即,它监听客户端请求的位置应该可配置)。Mendix 应用程序可以通过这种方式进行配置,从而使底层的平台即服务 (PaaS)(例如 Cloud Foundry)能够轻松扩展(用于托管应用程序)容器的数量。

  • 并发性

    Mendix 使用 Java 线程和流程组合来扩展最终用户的需求。十二要素应用程序方法的重点在于需要通过流程进行扩展;否则,您的扩展需求将受限于单个 Java 虚拟机 (JVM) 可以支持的最大数量(垂直扩展)。同时由于支持流程扩展,您可以始终轻松添加额外的资源(水平扩展)。

  • 可处置性

    Mendix Runtime 实例可以根据需要停止和启动。在多实例环境中,用户通常将不会察觉某个运行时实例是否重新启动过。这样做的优势是,您可以简单快速地进行水平扩展,并快速部署新版本或新配置。

  • 开发/生产奇偶校验

    为了保证质量,无论是部署在测试环境中还是生产环境中,应用程序的操作行为应保持一致。在 Mendix Cloud 中,所有环境均采用相同的配置方式。唯一的区别在于配置、数据和您的应用程序。数据可以通过备份和还原在不同环境之间移动,确保对最具代表性的数据进行测试。

  • 日志

    Mendix Cloud 使用 Cloud Foundry 防火墙来收集您所有应用程序中的所有日志事件。您可以在 Mendix 开发人员门户中查看和过滤这些日志。

  • 管理流程

    为避免同步出现问题,十二要素应用程序方法建议同时提供管理代码与应用程序代码。Mendix 会强制执行此操作,因此在应用程序环境中运行的代码一定是您应用程序的代码。这意味着您需要将管理代码包括在模型中。用户通常在管理页面中使用管理逻辑来实现此目的,可以通过执行要在应用程序启动后运行的微流,也可以创建 API 以触发管理操作。