十二要素架构

什么是十二要素应用方法？

虽然严格来说不是一套建筑原则，但 十二要素应用程序 方法论是一套针对云原生应用的最佳实践。

怎么样？ Mendix 运行时支持十二要素云原生应用吗？

以下部分描述了如何 Mendix 符合十二因素应用方法论要求。

• 代码库

  默认情况下，您创建的每个应用程序的源代码 Mendix 存储在 Mendix 团队服务器代码存储库。部署应用时，会根据团队服务器中存储的模型创建一个包。然后，会将此包部署到您的不同环境中，例如验收环境或生产环境。

• 依赖

  应用模块使用的所有依赖项（如模块和库）都是应用模型的一部分。这意味着您的环境中不存在对工具的隐式依赖。这可确保可靠的部署。

• 配置

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

• 支持服务

  所有外部要求（如用于存储应用程序数据的数据库）和要从应用程序调用的服务都可以在部署时配置。与之前的要求一样，这可确保相同的经过测试的部署包可在任何情况下与任何支持服务一起使用，而无需更改模型。

• 构建、发布、运行

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

  在 Mendix Portal，您首先必须从模型构建一个包，然后可以将其部署到您的环境中。如果您想在生产中更改代码，您必须修改模型，然后构建一个新的包。 Mendix 还提供用于构建和部署应用程序的 API，因此您可以在自定义 CI/CD 管道中采用这种方法。

• 流程

  - Mendix Runtime 的设计完全是无状态的。它通过数据库共享数据，确保易于扩展和具有弹性。

• 端口绑定

  为了简化同一应用程序在不同环境中的扩展和运行，应用程序应该是独立的（这意味着，它监听客户端请求的位置应该是可配置的）。 Mendix 应用程序可以通过这种方式进行配置，从而支持底层平台即服务 (PaaS) — 例如 Cloud Foundry — 轻松扩展托管应用程序的容器数量。

• 并发

  Mendix 使用 Java 线程和进程的组合来扩展以满足最终用户的需求。十二要素应用方法强调需要通过进程进行扩展；否则，您的扩展要求将受到 Java 虚拟机 (JVM) 所能支持的最大值的限制（垂直扩展）。通过支持进程扩展，始终可以轻松添加额外资源（水平扩展）。

• 一次性使用

  Mendix 运行时实例可以根据需要停止和启动。在多实例环境中，用户通常不会注意到某个运行时实例是否重新启动。这样做的好处是水平扩展更简单、更快速，新版本或新配置的部署也变得更快。

• 开发/生产平价

  为了保证质量，在测试环境中部署的应用程序应该在生产环境中表现类似。在 Mendix 云，所有环境都以相同的方式配置。唯一的区别在于配置、数据和应用程序。可以通过备份和恢复在环境之间移动数据，以确保使用代表性数据进行测试。

• 日志

  Mendix Cloud 使用 Cloud Foundry Firehose 收集所有应用程序的所有日志事件。您可以在 Mendix 门户。

• 管理流程

  为了避免同步问题，十二要素应用方法建议将管理代码与应用程序代码一起运送。 Mendix 强制执行此做法，因此唯一会在您的应用环境中运行的代码是属于您应用的代码。这意味着您需要将管理代码作为模型的一部分。用户通常在管理页面中使用管理逻辑来实现这一点，方法是实现在应用启动后运行的微流程或创建 API 来触发管理操作。