一个经常被问到的问题是如何在基于服务的体系结构中使用多目标应用程序（MTA）。在这个博客中，物联网断路器，我展示了mta与µ服务的关系取决于开发和部署过程的具体设置以及团队职责的分配方式。有一个相关的博客，根据Martin Fowler等人给出的定义，对µ服务和MTA进行了整理

为了说明，这个博客仅限于SAP云平台的云铸造环境作为目标平台，但一切都会转移到Neo环境和SAP HANA XS Advanced（内部部署）中。

基本的Cloud Foundry部署单元是一个"CF应用程序"。它被"推送"到平台上，从而创建一个具有合适环境的容器来运行CF-app工件。CF应用程序几乎没有附加元数据。然而，更多的元数据将有助于通过开发和持续集成/部署（包括质量管理和阶段过程）来发展和跟踪应用程序。作为一个显然微不足道的例子，CF应用程序没有定义良好的ID和版本。人们以某种方式将所有这些信息编码到CF应用程序名称中，此外，CF应用程序名称还必须承担编码蓝色/绿色部署状态的负担。

有三个主要原因（如下所列），即为什么应用程序所有者和开发人员正在基于这组元数据寻找合适的元数据和工具。通过构建用于编排和配置CF应用程序部署的脚本的并行代码世界来弥补这一不足。

这三个原因是：

应用程序由多个应用程序组成零件：适当的应用程序被"管理"的级别（即，开发、测试、部署、更新、操作、监视，等等）不一定是CF应用程序的级别。尽管每个CF应用程序可能对应于一个微服务，但是有一个完整的分布式应用程序的概念来作为一个整体来开发、管理和监控它仍然是有价值的整体.CF-构成更大应用程序的应用程序甚至可能不具备成为微服务的资格。尽管被推到单个容器中，但它们可能缺少作为独立组件的基本微服务特性。如果它们不公开稳定的公共API契约，就会发生这种情况。有时，创建这样的契约是不值得的，因为单独的CF应用程序可能不是由领域驱动的设计方法创建的，只是为了实现应用程序的独立扩展零件。另一个常见的模式是将应用程序分解为前端部分（充当初始用户请求处理阶段）和后端部分，每个部分都使用适当的技术实现（例如。节点.js与Java）。这两个部分可以紧密耦合，因为新的后端特性需要反映在前端。后端api的纯兼容演化是一个很大的开销，特别是对于不成熟的产品。应用程序具有依赖性：应用程序最多只能自我描述其运行时和部署时依赖性（这里我们不讨论构建时依赖性）。这种依赖关系可以是来自其他应用程序的必需服务实例或api应用程序。如果应用程序将附带这样的描述，工具可以验证所需资源的存在，可以分配缺少的资源，并将应用程序绑定到所需资源。今天，当通过应用程序清单（yml）进行推送时，有一些方面是这样的。缺少一些重要的方面，比如服务实例创建，并且很难在开发人员团队中共享一个清单，因为每个开发人员都希望维护单独的变量进行测试，这很容易破坏这些变量之间的一致性。另外，原生云Foundry没有应用程序间依赖性的概念。部署的多样性：出于我们的目的，让我们将"部署配置数据"定义为那些最终出现在CF应用程序的环境变量中的数据。它是应用程序设计的一部分，用于定义哪些变量目的引入配置的根本原因是为了在不更改应用程序代码的情况下启用应用程序的多个不同行为的部署。应用程序不是全局单例。DEV-spaces与PROD-spaces的使用，多个数据中心，以及大型企业对私有云的日益使用，都导致了数据的多样性部署。用于作为部署人员角色，创建部署变体应该尽可能简单和自动化。如果应用程序声明了它的配置变量、它们的特性（例如可选性、默认值）以及从何处获取该值的期望，淘客联盟，那么这就变得更简单了。设想一个由两个微服务S1和S2组成的应用程序。为什么人类要关心S2寻址S1所需的URL？基于足够的元数据，部署工具可以创建到S1的"任意"路由并将其注入到S2的环境中。只有在某些情况下，才有可能"从源"部署，例如，基于Git URL。一般来说，可部署是构建和测试的结果。分发存档格式是通过防火墙移动可部署文件所必需的。企业策略将软件分发限制为仅作为可审核过程的一部分部署签名存档的过程。

声明性应用程序模型（MTA模型）涵盖了所有这三个方面，该模型保存在描述符文件中。有关MTA的更多信息，请参阅文档"多目标应用程序模型-了解多目标应用程序的指南"。