在上一篇文章中，我们看到多目标应用程序由一组模块组成，国内云服务器，这些模块一起执行，形成一个具有自己生命周期的业务应用程序。我们还发现，这些模块是作为微服务执行的。

微服务是独立的模块，因为它们可以单独执行和部署。它们也彼此隔离，彼此之间不共享任何资源，即使这意味着将同一个库在不同的模块中打包两次，并打包到它们自己的运行时环境中。这些模块还提供了相互通信的接口（例如OData服务、JDBC等）。

我认为微服务体系结构中的一个关键行为，有助于理解隔离性和独立性，就是它们可以分开部署。换句话说，您可以对进行一些更改，例如节点.js模块，重新构建并重新部署它，您将不需要重新启动或重新部署其他两个模块。

这也意味着，如果一个服务由于任何原因（通常不是我们的错，我们是优秀的开发人员……）崩溃，那么剩下的服务就不一定会崩溃中断或至少有机会优雅地崩溃。一个非常具体的例子是，您可以更改UI5库的服务实例，只重新构建web模块，并立即看到执行中的更改。这个节点.js数据库模块甚至不会注意到（如果你仔细想想，他们通常没有理由注意到）。

当你"激活"你的应用程序（或推送，在我们新的CloudFoundry术语中），每个模块的微服务都会被创建。

我不想重复，但这些独立的、孤立的等服务会没有任何意义，除非他们都粘在一起，并服务于商业目的。我对自己解释说，相当于一个FRICEW对象，有自己的缺口或者业务需求需要完成的是多目标应用，有一个文件声明这个模块组合是一个单一的应用程序，它还解释了这些服务如何相互绑定以及它们应该按什么顺序部署。

当您在Web IDE中创建模块时，这个名为development descriptor的文件大部分是自动填充的。当然，你需要添加必要的信息来把你的模块粘在一起，因为它还不能读懂你的心思MTA.yaml公司)对于web模块依赖于节点.js模块（自称为"jsapi"）和结束：

本yaml未考虑某些细节（如认证）。随着我们的进步，我们会更深入地了解它。

我们有一只令人惊讶的小猫，我们不能责怪它。当您第一次创建MTA应用程序并添加数据库模块时，该"hdi容器"及其参数将添加到mta.yaml公司在开发描述符文件的第一部分，您（实际上是Web IDE）添加了应该相互绑定和处理的模块作为商务应用程序，

其中一个模块是"数据库"模块。在这里，在这种特殊情况下，您将创建一个名为"实体"的设计时工件，云服务服务器，然后它将成为一个名为"表"的运行时工件（是的，良好的ol'表），然后您将施展一些其他核心数据服务咒语。

您还将向这些实体添加数据，访问由另一个开发人员甚至其他开发人员创建的表组从ECC系统复制到HANA的模式（在计算视图中使用的漂亮的BKPF表…你这个淘气的家伙）。

hdi容器是你自己的数据库。它是您的数据库模块访问自己的HANA所需要的。这是你自己的备份服务

备份、应用程序和Mashup服务

为什么hdi容器在那里？因为你需要访问数据库（很简单吧？）

那么您是否只需要创建一个模式并硬编码一些凭证，以便其他模块访问？你真的认为让一个完整的开发人员完全访问完整的数据库是个好主意吗？我们为之奋斗的孤立、独立以及随之而来的健壮性会发生什么变化？

不，我的朋友们，企业管理的软件，我们不会停在这里。您正在以托管服务的形式获得自己的数据库（服务）片段（实例）。数据库、用户帐户和身份验证服务、作业调度程序—它们都是支持服务，企业信息化应用系统，是跨不同空间为不同应用程序提供服务的基础层。

让我们以示例的形式来理解。这是一些正在运行的服务在控制台中的样子：

这是正在运行的服务的列表，例如，在"开发"空间（资源共享并可以相互访问的环境）中。

您可以看到它们有一个名称。其中一些被调用，就好像有人在用户ID和应用程序名称之间的键盘上添加了一个愤怒的标记。这不是一时的愤怒，而是一个自动生成的id（这就是计算机不执行创造性任务的原因）。

您可以将自己预定义的名称作为参数添加到服务中，以在mta.yaml公司例如，好的云服务器，文件。我继续回到mta.yaml公司因此，您了解它是如何协调大部分工作的。

计划指明了分配给该资源的资源或功能的范围或级别。这些将因服务而异。例如，"hana"服务的服务计划，您可以使用"schema"作为普通模式，或使用"hdi shared"作为hdi容器（模式加元数据）。该计划还与您在描述符中声明的类型相关联。

当您右键单击MTA应用程序并单击build时，文件将上载到平台，并调用BuildPack以生成可执行文件。上传的是一个名为"