SAP BTP MTA 应用解决的架构痛点

SAP BTP MTA 应用解决的架构痛点

SAP BTP MTA 规范解决了云和本地平台的生命周期和编排复杂性，其官方定义如下：

多目标应用程序 (MTA) 由多个部分（modules）组成，使用不同的技术创建并部署到不同的目标，但具有单一、通用的生命周期。

MTA 通过正式的独立于目标和技术的应用程序模型将开发人员与特定于部署 target 的本机工具（如 Cloud Foundry 的 cf push）隔离开来，解决了部署挑战。 开发人员负责描述应用程序的模块、与其他模块的依赖关系、MTA 和（微）服务，以及所需和公开的接口。

MTA 应用程序的生命周期管理框架，负责在本地和云平台上验证、编排和自动化 MTA 部署。

MTA 在逻辑上是一个单一的应用程序，由多个相关和相互依赖的部分（这里称为 modules）组成，这些部分使用不同的技术或编程范例开发，并设计为在不同的目标运行时环境中运行，具有单一、一致的生命周期。

模块不一定需要是在运行时容器中执行的代码。 相反，它可能包含使应用程序运行所需的其他 artifact. 例如，考虑要部署到文档 Web 服务器的文档，或者要部署到 API 网关的 API 元数据，或者要部署到中央注册表的配置数据。

MTA 模型用于以下目的：

MTA 模型是开发人员（使用开发工具）和 MTA 部署人员之间的 former contract. 部署器是一个工具，它使用 MTA 模型的描述并将其转换为目标平台特定的 native 命令，用于配置运行时容器、创建和绑定资源（例如，Cloud Foundry 或 SAP XS Advanced 上的 service instance）， 以及安装、运行和更新应用模块。 MTA 部署器可能不仅仅是一个工具，因为它可以包含用于维护配置和聚合多个目标平台特定部署器的工具。 开发环境也包含这样的功能，因为部署（例如用于测试）是开发过程中不可或缺的一部分。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。