多目标应用程序（MTA）是一个开发过程的结果，该过程最终可以构建一个包含多个软件或内容块的存档，这些软件或内容块由一个唯一的版本号标记。MTA的目的是为所有这些包含的软件片段强制执行一个共同的生命周期，尽管运行时表示可能是分布式的。

一个经常听到的问题是，作为云软件的主要架构原则，它如何适用于µ服务。在这个博客中，我想解释MTA和（µ）服务这两个概念是如何结合在一起的。

最近有一个关于这个主题的博客，它将"MTA与µ服务"放在了应用程序从开发到部署过程的设计背景下。我建议先阅读这篇文章……

如果某些技术组件共同代表提供专用（业务）功能的服务，那么有充分的理由将它们的生命周期耦合起来。mta提供了一个选项，可以将它作为一个隐藏的实现细节，显示这样一个服务由多少运行时组件组成。现在，人们可能会认为mta可能会导致单片应用程序，与服务方法相矛盾。这不是目的。为了避免这种情况，决定哪些组件应该具有这种耦合的生命周期是至关重要的。此外，大数据应用技术，µ服务体系结构包含一组原则，在使用MTA时也必须正确应用这些原则。

如果考虑到这一点，MTA与µ服务并不矛盾，但两者相辅相成。在设计MTA时，您仍然需要做组件化作业，以避免出现整体。但是，mta允许您根据与"粗粒度"服务和"细粒度"服务相关的权衡决定来选择服务的"大小"。此外，MTA还可以帮助您管理与他人的依赖关系，这项任务在您身边的µ服务越多就越困难。

让我们先简要回顾一下Fowler是如何推动µ服务的（请参阅博客Microservices–James Lewis和Martin Fowler对这个新架构术语的定义，可在https://martinfowler.com/articles/microservices.html–我最后一次通读是在2018年1月）。基本上有两个承诺：（1）改进扩展行为和（2）根据业务能力而不是技术能力和技能进行组件化，跨职能团队（每个团队负责一个业务能力）将形成一个根据业务能力进行集群的体系结构。这里还必须考虑的是UI和数据库（Fowler在其博客中概述的服务视图中遗漏了什么）。当将Fowler的观点与UI和数据库相结合时，µ服务看起来是这样的：

图1：带有数据库和UI的微服务

因此，如果团队的责任是完整的业务能力，一般来说，他们的µ服务仍将由多个技术组件组成。如果他们想将一个生命周期（从开发到部署）附加到这些组件，那么µ服务就是MTA！

在某些情况下，可以通过拥有由多个µ服务共享的中央数据库"备份"服务，将数据库从µ服务中"删除"。但是，这引入了一个现在需要管理的依赖项。首先，您依赖于其他人来提供此支持服务，并且您的服务必须包含描述此依赖关系的元素。此依赖关系应该是可配置的，因为您可能希望将服务部署到不同的设置中（例如，测试与生产）。这就是你要为泄露数据库付出的代价。MTA帮助您管理其余的依赖项。您的µ服务现在看起来是这样的：

图2：依赖于数据库的Microservice

如果您想要或需要部署架构定义，或者想要将应用程序逻辑"下推"到此数据库（就像将代码下推到SAP HANA时一样），全国大数据中心，则数据库部分更难从µ服务中删除。您可以让业务逻辑代码模块负责保留DB schema definition+DB代码并将其下推到数据库中。

这有局限性，因为您可能希望将DB代码（例如DB procedures）视为一个代码模块，就像您为Java和其他应用程序所做的那样。您可能需要开发支持来创建、检查和调试这样的代码。当涉及到部署时，您需要一些东西来获取您的DB代码并将其部署到共享数据库中的适当模式中。您将希望DB代码和通常的Java代码有一个联合部署生命周期。突然，你不得不解决一个编排问题，因为您的µ服务看起来像这样：

图3：依赖于数据库和DB代码的微服务

MTA deploy Service implementations for SAP HANA XS Advanced和SAP Cloud Platform的Cloud Foundry环境帮助您协调DB代码部署与其他应用程序代码部署。

现在，让我们关心一下关于UI部分。如果您想通过服务器端呈现将UI相关资源"从"服务中移除，那么您可能会得到一个技术组件（忽略上面的代码下推方面），例如，云免费，一个配备了servlet、bean等的javaee服务器，这不适合类似sapfiori的UI策略，这意味着有丰富的JavaScript客户机和服务器组件为这些客户机提供静态内容。与DB过程类似，您需要将JavaScript UI代码开发为一个单独的模块，最终需要部署到某个地方。同样，您最终会遇到部署编排问题（可以通过MTA解决）。在这种情况下，您的µ服务将保持与以前一样的外观。