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 模型用于以下目的：

1. 定义一个由多个（异构，heterogeneous）子组件组成的应用程序（好处：工具可以为这些子组件建立一个独特的生命周期）

2. 在运行时和/或部署时声明应用程序依赖的资源（好处：工具可以分配和绑定这些资源）

3. 定义配置变量（及其关系），其值区分应用程序的不同部署（好处：工具可以绑定子组件，可以根据默认设置自动部署，或者交互请求缺失的强制值）

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

这篇关于SAP BTP MTA 应用解决的架构痛点的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！