SAP BTP MTA 应用的应用场景

本文主要是介绍SAP BTP MTA 应用的应用场景，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

编程语言、软件设计架构（如微服务）、协议（如 OData）的最新趋势和进展，以及多层和分布式部署平台的多样性，加速了由更多、更小、解耦和多样化的模块构建应用程序的趋势。

在微服务架构下，越来越多的业务应用程序倾向于由使用不同语言和技术开发并部署到各种目标运行时环境的多个部分组成。

这种应用程序模块的多样性带来了许多生命周期挑战。开发、部署和配置复杂应用程序的所有独立部分涉及许多步骤，通常是目标平台或应用程序服务器特定的。所需的服务必须预先配置和供应，不同的模块必须以严格的特定顺序“连接”在一起、配置和部署在多个平台上，通常使用不同的工具，重复用于测试、登台和生产环境。

零停机升级(Zero downtime upgrade)是另一个复杂性的来源。

SAP BTP 创造了多目标应用程序 (MTA) 一词来表达这种生命周期管理要求的多样性，而业界广为流传的其他术语，如“分布式”、“多语言”、“多模块”、“多层”或“multi-headed”的应用程序，都不足以表述这种架构的多样性。但本质上，MTA 只是现有 multi-part 应用程序的自然演变。

例如，由 UI 和数据库模块甚至应用程序代码组成的 SAP HANA XS Advanced (XSA) 应用程序就是 MTA 的示例。开发人员和管理员希望将开发、版本、部署和操作这样的结构化应用程序作为一个逻辑单元进行管理。

另一个典型的 MTA 示例是 Java EE 应用程序，它由 bean、Web 和应用程序模块、资源适配器等组成，所有这些都受制于相同的开发生命周期并跨多个计算层部署。

SAP Business Technology Platform 为协调的跨平台部署引入了新的分发要求。当充当 SaaS 扩展平台并采用 Fiori 即服务 (FaaS) 概念时，应用程序开发人员需要跨异构目标（Java VM、前端服务器、SaaS 后端）分发他们的应用程序，每个目标都有自己的部署 API，同时提供，精心管理的单一应用程序生命周期。

对微服务设计原则、API 管理的日益关注以及 OData 协议作为丰富的服务 UI 边缘的出现，进一步鼓励了使用不同语言、IDE 和构建方法开发的应用程序模块的激增。

但是所有这些部分，UI、服务和数据模型，仍然必须作为一个连贯的应用程序运行。在部署方面几乎没有统一性。每个运行时、应用程序服务器或云框架都以自己独特的方式管理多目标方面，通过引入各种编排解决方案（大量清单文件和格式、项目 JSON 文件、应用程序描述符、存储库、SAP 的 CTS+ 等） .

Cloud Foundry 等 PaaS 以灵活的方式改进了传统的应用程序服务器，它们通过容器化支持各种应用程序运行时技术。这为选择实现技术（Java、Node.js、Python 等）带来了更多的自由。应用程序可以分解为多个模块，这些模块可以独立扩展，并且可以选择最适合每个模块关注的技术。例如，在 Node.js 中实现的可扩展请求预处理代理可能会覆盖实现业务逻辑的 Java 模块。虽然从运行时方面来看这是有利的，但这种分布式应用程序的开发和生命周期管理变得更加困难。

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