SAP集成技术（四）五种集成架构

本文中，我们将介绍并解释五个主要的模型。我们主要区分直接集成、中间件导向集成以及两个一般的架构概念。直接集成（例如点对点集成）中的标准化很少，但中间件导向的拓扑（例如中心辐射型拓扑以及企业服务总线）追求尽可能标准化集成，并将来自单个应用的集成工作集中到一个中央消息平台。另外两个架构概念——服务导向架构和微服务——引入了对封装单个服务和分布式系统中的服务的架构模式，从而提高了灵活性和可重用性。

本文链接：https://www.cnblogs.com/hhelibeb/p/17845805.html

内容摘录自《SAP Interface Management Guide》，斜体字是我补充的个人理解。

点对点拓扑

两个应用系统之间的直接连接以实现应用的集成。为此，定义了一个公共接口，以便两个系统可以完全彼此通信。然后在两个参与系统中实现这个接口。因此，集成是没有中央平台的，而是从点到点（point to point）。这个过程也称为peer to peer。

图1，点对点拓扑

点对点集成架构具备以下特征：

每个参与的应用系统都可以作为服务器和客户端。
参与的应用系统之间的通信是直接进行的。
参与的应用系统保持其独立性和自主性。

这种集成拓扑形式在许多公司中仍然常见，是因为其有明显的优点。由于系统之间直接相互通信，点对点集成适合于有大量数据需求的情况，它没有中间的软件层减慢传输。

点对点架构的另一个优点是其比较便宜的实施。不会产生额外的许可费用，通常也不需要硬件扩展。与其他拓扑不同，不需要中央系统来管理和控制集成。因此，基础设施并未因额外的系统而变得更复杂，也需求少的配置工作。所有的转换工作都在接口内的转换模块或适配器中。如果可能，目标是避免对应用本身进行更改，而是将这些更改外包给上游适配器。

这种方法有助于开发团队在不先查看其他应用的依赖关系的情况下，很好地控制两个参与应用的集成方式。

然而，如图1所示，这种拓扑结构的示意布局意味着，随着集成程度的增加和相关接口数量的增加，复杂性会迅速增加。

随着应用系统数量的增加，集成景观的扩展性相当差。对于n个应用系统，最多需要n/2×（n-1）个（双向）连接。如果要集成新的系统，在最坏的情况下，必须定义和实现n-1个新的接口。具体来说，对于6个系统，总共需要15个接口，对于7个系统，必须实现21个接口，因此，在引入这第7个系统时，增加了6个额外的接口。当你需要集成的应用数量超过一定数量时，前面描述的成本优势可能会被抵消，因为实施的成本会呈指数增长。

同样，每个接口实现（或许一个转换模块的实现）都代表其自身的单独开发。由于缺乏标准程序，每两个应用之间的连接都需要编程一个单独的解决方案。当对参与的应用进行更改时，这些解决方案也必须单独记录并单独维护。

在这个上下文中，通常存在高度的功能冗余，因为相似或甚至相同的业务逻辑是由多个应用系统提供的。在缺乏中央平台的情况下，监控这些接口的问题也构成了相当大的挑战。其中一个困难将是在持续的生产运行中主动发现错误。在这种情况下，每个参与的系统都必须启动相应的错误处理过程，以相应地通知IT或专业部门。

结论：应用程序领域通常是以进化的方式出现的。往往是按需添加增强，却没有考虑重构。因此，接口往往不灵活，只能花费巨大的努力适应其他系统。如果未来需要对 IT 基础设施进行重构或扩展，这种限制将增加集成工作量。

中心辐射型拓扑

中心辐射型拓扑（Hub-and-spoke topologies）基于消息导向的中间件。上一节中介绍的点对点拓扑相比，中心辐射型架构中，有个叫做集线器的中央系统，是所有集成的应用系统（辐射）之间的通信被路由的地方。

这种架构允许基于消息头部或消息体中定义的元素的信息进行内容基础的路由。通过集中处理消息，处理规则可以应用于消息的内容，并可以针对消息的各个接收者。这种拓扑的示意结构如图2所示。

中心辐射型集成架构可以通过以下特征进行描述：

通过中央消息代理（Message Broker）将发送者和接收者解耦。
应用系统之间交换的消息基于规范的数据模型。
参与的应用系统保持其独立性和自主性。
通常，中心辐射型架构用于异步数据交换。

图2 中心辐射型拓扑结构示意图

中心辐射型架构的中心特点是通过中心消息导向的中间件 —— 集线器，也称为消息代理，将发送者和接收者在消息中解耦。这种中间件代表着验证和评估所有传入消息并将其传递给适当接收者的中心实体。除了数据层面的检查外，其任务还包括检查消息的语义，以及接收者是否存在或活跃，以及指定的消息是否包含正确的信息。成功验证后，集线器根据随消息发送的地址信息将消息转发给适当的接收者。因此，基于定义的路由逻辑，消息可以被发送到一个或多个接收者。

除了纯粹的消息路由外，消息代理还应该补偿各种应用程序使用的协议和数据格式的差异。例如，假设系统A通过HTTP协议发送一条消息，该消息必须以单独的格式在安全文件传输协议（SFTP）服务器上提供给接收系统B。为了满足这个要求，源系统和目标系统之间的应用系统（辐射）的接口中的消息使用消息转换器进行翻译。这些消息转换器执行相应的转换，包括协议和数据结构的转换。从技术上来说，这些协议和接口适配器是应用特定的，但从架构上来看，它们更可能被分配给集线器而不是单个应用程序。

然而，应用系统之间的转换带来了另一个问题。假设每个参与的应用系统都期望一个不同的数据格式。因此，消息代理必须能够将n种源格式转换为m种目标格式。可以使用这种集成架构在技术层面将系统连接数减少到最多n个，但在消息转换级别上并非如此。因此，你仍然需要使用消息转换器来处理所有可能的n个集成应用系统的消息组合。

为了避免这种额外的工作，可以使用一个全局元模型。这个模型，也被称为规范数据模型，描述了一个数据结构，其中所有连接的应用系统的消息都可以通过它描述。通过使用这个模型，系统之间需要的转换组件的数量从最多的n / 2 × (n - 1)，减少到最多的n。对于每个跨应用通信，消息首先被翻译成全局格式并发送到集线器，从那里消息被转发给接收者并再次翻译回来。注意，所有消息都转换使得转换数量得到了简化，但与此同时，最坏情况下需要两倍的计算工作 —— 导致整个架构的响应时间增加。

通过中心辐射型拓扑，集成新应用的过程明显简化，因为集成逻辑和应用逻辑是解耦的。在集成新应用时，你只需要实现一个消息转换器，将应用的消息转换为全局元格式。同样，修改现有的路由逻辑或定制应用特定消息也更容易。在消息代理中，你只需要为新消息类型和新系统作为相关现有系统的接收者，集中地添加适当的接收者。与点对点拓扑相比，有最多n / 2 × (n - 1)个双向接口，集线器和辐射架构只需要⩽ n个接口。在这种情况下，如果要集成四个或更多的应用，一个中心化的集成架构就是有意义的。

然而，集中式的消息处理也可能导致单点故障。因此，如果在这个中心节点出现问题，所有集成的应用系统也会受到影响。此外，虽然整个架构中可能的接口数量减少了，但集线器成为整个系统性能瓶颈的风险增大了。随着新集成应用系统的增加或消息数据传输的增加，增加的消息负载可能会成为问题。

结论：根据经验，很难以有意义和可持续的方式实现规范数据模型。构建一个考虑多种协议和每个参与应用系统及其流程的特点的数据结构，不仅耗时，而且资源密集。在极端情况下，数据结构的标准化甚至可能导致系统在可能的使用上受到限制。有时，由于数据模型的不灵活，你无法有效地映射所有业务，因为定义数据模型的原始基础系统已经改变了（从业务系统变成了集成平台）。

可以通过分布式或联邦集线器或适当的硬件/软件侧故障转移机制来对抗这些问题，但是在关键和复杂的IT环境中，这种架构模型仍然不够可扩展和高效。

尽管存在这些各种各样的缺点，但在SAP世界中也可以找到规范数据模型的实现方法。例如，较新的产品如SAP主数据集成或SAP One Domain Model基于一个集中的数据结构的想法，该结构被分发到周围的系统中。由于这些产品相当新，它们的实践效果还有待观察。

企业服务总线

从字面上看，企业服务总线（ESB）通过数据总线向企业提供服务。在核心，其主要任务是将客户端应用程序与服务提供者应用程序解耦。企业服务总线的工作方式如图3所示。

图3 企业服务总线的功能

企业服务总线将功能封装在一个捆绑的服务中，该服务提供给客户端应用程序，而不是直接与各个服务提供者通信。服务提供者的所需协议或数据格式对客户端保持隐藏。企业服务总线相应地确保了转换。因此，企业服务总线提供了公司范围的服务，这些服务与服务提供者应用程序中的实际实现解耦。其主要目标是使这些服务尽可能灵活和可重用，以便类似的应用程序可以基于现有的转换或路由规则集（称为服务存储库）。

企业服务总线拓扑依赖于一个中央消息总线作为系统间消息分发的主干。然而，与中心辐射型方法相比，这种方法允许在多个系统中分发集成活动。集成总线是系统间通信的链接。

进程和服务不一定在一个中心的企业服务总线服务器上运行，而可以分布在几个系统上 —— 这是企业服务总线架构在可扩展性和可靠性方面的一个主要优点。图4显示了集成总线拓扑的示意结构。

图4 集成总线拓扑的结构示意图

所有的应用程序都直接连接到企业服务总线系统。应用程序之间不直接通信。转换和路由规则存储在一个中心服务仓库中，当从已连接的应用程序系统接收到通信请求时，它们的分配给各个服务触发相关的后续进程。为此，仓库中检查相关的业务进程，相应的通信命令分发给所有参与的应用程序系统。在最简单的情况下，进程直接将消息传递给目标系统。

企业服务总线集成架构有以下特性：

发送者和接收者的解耦
转换模块的中心仓库
建立业务进程/规则的模型，消息传输基于此进行
适用于n个发送者和接收者之间的异步和同步通信
实现高度分布式和松散耦合的服务导向架构

所有来自各大制造商的经典企业服务总线产品都提供类似的功能范围。图5显示了企业服务总线产品通常提供的组件的基本结构设计。在本节中，我们将简要地介绍这些单个组件，特别是对于系统管理。

图5 经典企业服务总线平台的组件（来源：基于 Liebhart, 2007，和 Winkeler 等人，2000）

系统管理组件支持企业服务总线系统的管理。这些组件监视平台可以在早期阶段识别性能瓶颈和潜在改进点。系统管理包括以下三个组件：

负载均衡用于基于消息交换量的系统负载分配。在消息量大的情况下，负载均衡允许分配额外的运行时节点。
安全问题不仅涉及专用用户管理的选项，包括授权管理和访问控制，还包括加密和解密的机制。
监控和日志记录使得在运行时及其后能够监视消息交换。消息日志记录允许在数据库中永久或临时存储消息。除了对消息交换的纯粹监控和跟踪外，监控也涉及到应用本身状态的控制，例如，关于资源利用的情况。

集成管理的组件支持在数据层面的集成，并规定通信的方式。集成管理具有以下五个组件：

适配器确保实际应用程序和企业服务总线产品之间的连接。预制的标准适配器减少了建立两个应用程序之间通信所需的努力。
消息路由到一个或多个目标应用程序，基于定义的规则。
消息转换指的是提供数据的转换，以便目标系统可以解释。
消息调度描述了如何在系统之间传输单个消息。我们可以区分同步和异步消息模式，例如请求/回复，发布/订阅和消息队列。
事务处理监控单个调用的时间，它们的顺序，以及它们的正确性或完整性。

除了应用服务外，流程管理的组件构成了动态企业服务总线平台的核心构建模块之一。此区域包含允许建模业务流程的组件，并定义哪些应用程序参与交易以及要执行哪些子流程步骤的规则：

流程建模关注业务流程的建模和技术自动化（可执行性）。它也被称为工作流。
业务规则允许基于中央决策表的定义，根据这些决策表在消息交付运行时遍历流程及其子路径。

与中心辐射型拓扑一样，企业服务总线允许通过将集成逻辑与应用逻辑解耦来在IT环境中无缝集成应用程序。这种独立性使得连接额外的应用程序变得简单和灵活。然而，企业服务总线的使用比中心辐射型拓扑更适合于跨公司或国家边界的高度分布式应用。联邦企业服务总线架构由公司的各个组织单位的分布式集成平台组成，它们在消息总线系统中汇集在一起，如图6所示。

图6 联邦企业服务总线的结构

在这个例子中，公司由三个全球分布的组织单位组成。单位A在AMER区域（北美和南美）运营，单位B在EMEA区域（欧洲/中东/非洲）运营，单位C在APAC区域（亚洲和太平洋）运营。尽管每个组织单位本身现在都有一个自治管理的企业服务总线来独立行动，但所有组织单位仍然可以访问共享资源并重用数据流和转换。根据扩展级别，企业服务总线因此构成了跨越业务伙伴、业务单位和部门的通信网络的核心。

这种企业服务总线架构的优点主要是保留了各个连接的组织单位的自主性。目标是让所有参与的业务单位和部门保留对自己的本地IT资源的控制。这个目标不仅适用于本地企业服务总线的维护和配置，也适用于新应用的集成。然而，在集成内容的可重用性方面也存在潜力。在本地组织单位中使用的适配器或转换也可以助力于在另一个组织单位中集成新的应用。

尽管企业服务总线提供了许多自由，但这种类型的架构也带来了高度的复杂性。建立一个高度分布式的企业服务总线不仅产生高初步的基础设施成本，而且在维护多个企业服务总线实例时也有更高的管理开销。单个企业服务总线实例的本地控制也导致全局景观控制的最小化。只能在有限的程度上进行集中管理。

结论：企业服务总线主要设计用于高度分布式系统的集成。由于其在企业结构方面的可伸缩性以及对所有企业应用的全面集成（无论技术平台和物理位置如何），它提供了一个灵活且全面的集成架构。企业服务总线允许不同的集成方法：从在本地公司内部实现企业服务总线，到带有分布式企业服务总线的联邦架构，每个公司还额外运营自己的本地平台。典型的企业服务总线产品的例子有SAP PI/PO，TIBCO和IBM WebSphere。

面向服务的架构

面向服务的架构（SOA）是一个用于分布式系统的灵活且可适应的架构模式。在其核心，面向服务的架构是一个追求将IT组件（如数据库、服务器和网站）封装为可以集成到不同业务流程中的服务的范例。这种架构的主要任务是将多个单独的技术任务编排和组合成一个可以作为IT服务提供给其他组织单位或合作伙伴的高级服务。面向服务的架构意味着你可以隐藏单一应用的复杂性在一个标准化的接口后面，从而为集成提供一个服务的结构化形式。

面向服务的架构的主要目标包括降低软件开发和集成成本，以及通过在业务流程中重用现有服务来创造更大的灵活性。

市场研究机构Gartner在1996年首次使用了面向服务的架构这个词，因此被认为是这种架构模式的发明者。到目前为止，还没有一个被普遍接受的定义，但是来自组织信息标准推进组织（OASIS）的以下定义在文献中经常被引用：面向服务的架构是一个用于组织和利用可能受到不同所有权域控制的分布式能力的范例（Service oriented architecture is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains）。

面向服务的架构有几个重要的特征和属性，我们将在这一节中讨论。没有统一的面向服务的架构定义，从一般角度描述的最重要的特征包括以下几点：

可重用性：可重用性的基本思想是在不改变接口或核心应用的情况下多次使用组件和服务。
松散耦合：你应该能将松耦合的服务组合形成一个流程。这种能力可以通过对其他组件和服务的低依赖性来确保。目标是使得能够对服务进行功能改变而不影响所提供的性能。
自主性/自给自足：如果一个服务独立于其他服务和功能，它就被认为是自给自足的。这种自主性要求逻辑、资源等独立管理。
抽象和封装：抽象与服务的松散耦合和重用密切相关，它是关于从具体的功能和实现中抽象出服务的外部。
可发现性：类似于目录服务或黄页，服务应该是可以找到的。服务必须由消费者和提供者进行寻址。通常，这个特性通过服务注册表来保证。在服务注册表中，服务通过接口和实现进行描述。
进程导向和编排：编排用于将单个服务集成到不同的业务流程中。面向服务的架构追求的目标是用一个或多个服务提供业务流程。因此，进程导向是面向服务架构的一个基本特性。

实施面向服务的架构基于三种不同的角色 - 服务消费者、服务提供者和服务注册表。让我们简单看一下这些角色：

服务消费者：在面向服务的架构中，服务消费者角色在服务注册表中寻找特定的服务，并获得关于哪个服务提供者提供这项服务的引用。随后，服务消费者和服务提供者进行绑定，然后可以调用服务。
服务提供者：服务提供者提供一个或多个可以被不同消费者使用的服务。为了确保服务可以被相应的服务消费者找到，服务提供者在服务注册表中集中发布他们的服务。
服务注册表：服务注册表发布服务提供者宣布的服务。此外，服务注册表通过将他们引向相应的服务提供者来回答服务消费者关于服务的查询。

这些角色之间的交互可以通过图7中显示的三角形来表示。

图7 面向服务架构中的角色

如图7所示，交互的步骤为：

服务由服务提供者在中央服务注册表中发布。
服务消费者在服务注册表中搜索一个能满足功能的合适服务。通过服务注册表，获得对服务提供者实体的相应引用。
服务消费者首先与服务提供者进行绑定，然后可以调用服务。

在面向服务架构中，可以使用各种协议进行通信，如远程函数调用（RFC）或基于HTTP的服务，如Web服务。会在后文详细介绍这些协议。根据经验，面向服务架构中单个服务的集成是通过企业服务总线实现的，它在角色之间充当中间件（上节）。为了实现面向服务的架构，推荐引入面向服务的架构治理。在面向服务的架构治理中，制定规则，相应地进行监控，并在中央提供。通常，面向服务的架构治理是由一个单独的团队建立的。

通过实施面向服务的架构，你可以通过复用服务实现长期的成本降低，因为核心功能只需要创建一次。通过松散耦合和封装核心服务，你可以在不改变服务的情况下进行系统更改。此外，由于所有参与者都在同一流程中工作并使用同一种语言，因此促进了协作。在技术上，面向服务的架构提供了平台独立性，从而提供了更多的灵活性。

然而，由于服务的解耦，面向服务的架构在实施中需要更多的努力，并且比经典的实现更为复杂。在适应现有服务的版本和兼容性上也增加了复杂性。

此外，在大多数情况下，服务都基于XML标记语言，由于数据量大，传输、转换和处理需要大量的计算能力和时间。所有这些点最初都会在公司的分析、实施和运营中造成较高的成本。

结论：面向服务的架构面向公司的业务流程，并促进接口的重复利用。不幸的是，现实表明，纯面向服务架构的初期费用对许多公司来说往往过高，而且它的好处可能只能在很长一段时间后才能显示出来。许多大型面向服务架构的倡议由于政治和组织问题，除了纯技术挑战外，已经失败了。例如，责任可能不够明确，或者历史上已经生长出了单体的结构。尽管存在这些潜在的问题，面向服务的架构目前依然是选项之一，包括在微服务的背景下。

微服务

在这个部分，我们将介绍微服务（microservice）的概念。像面向服务的架构（SOA）一样，微服务是计算机科学中的一个架构模式，并遵循模块化软件的方法。微服务使用独立的程序作为模块，这些模块又作为独立的进程运行。因此，程序或服务在很大程度上是解耦的，在最好的情况下，只执行一个小任务。总的来说，微服务是小的、独立的服务，它们协作提供企业应用的业务功能。

微服务架构的主要目标是可扩展性以及减少开发时间，尽快将创新和新功能引入市场。

微服务基于UNIX哲学的基本思想。在他2018年由d.punkt Verlag出版的书《微服务：灵活软件架构的基础》中，微服务专家Eberhard Wolff用以下三个方面描述了这种方法：

一个程序应该只做一件事，并且应该做好。
程序应该能够一起工作。
程序应该使用通用接口。

和面向服务的架构一样，微服务这个术语并没有被普遍接受的定义。在文献中，微服务通常用以下属性来描述：

技术独立性：在由多个独立服务组成的系统中，可以使用不同的技术。可以为每个任务使用适当的技术和工具。没有关于特定语言或平台的限制。
独立性和部署：微服务一定彼此独立，并且在技术上彼此隔离。此外，当进行更改时，服务可以独立于其他服务投入生产，但这需要服务本身具有高度的稳定性。
可扩展性：在单一系统中，只能对整个系统进行扩展。相比之下，对于微服务架构，每个服务或任务的性能都可以进行扩展。这种能力的优点之一是你将节省运营成本，因为每个服务使用的资源只会根据需求进行扩展。
模块结构：微服务架构是一种模块化软件的方法。其思想是服务的功能可以用于不同的任务。因此，每个服务都被设计用于一系列功能来解决问题。如果对服务的需求增加，需求可以被细分为更小的服务。
可替换性：可替换性意味着小的、独立的服务可以用较小的努力进行替换。这个特性确保一个微服务只在需要时提供，并且技术是最新的。这样，可以避免为旧系统的持续运营产生不必要的成本。
组织：一个微服务只由一个团队开发。然而，一个团队可以负责多个服务。这样，可以确保通过适当的组织保护系统架构。

总结来说，可以独立地开发、部署、操作和扩展微服务架构中的服务。然而，微服务架构的所有特性的关键在于各个服务之间通过明确定义的应用程序接口（APIs）进行通信。

为了再次可视化微服务的架构，图8展示了单体架构模式（Monolith）和微服务架构模式的比较。在单体架构中，所有的进程和业务逻辑都在一个服务中执行。相比之下，在微服务架构中，应用的核心功能被分割为多个服务，并独立执行。这种方法最好用在线商店的例子来描述，商店可能提供各种服务（例如，产品搜索，产品推荐，购物车等）。在线商店中的所有这些核心功能都可以是专门的微服务。每个微服务都可以用不同的技术和任何编程语言来开发。更重要的是服务之间的集成和通信。图9展示了一个示例架构，以显示用于实现在线商店的典型微服务架构。

图8 将单体划分为微服务架构

图9 构建微服务应用的示例架构

注意到各个服务是如何通过API网关解决方案提供的，并且在外部合并，作为各种客户端的中心入口点。客户端和API网关之间的通信通常基于HTTP和RESTful服务。各个微服务之间的通信是异步的和基于事件的。各个服务独立地进行通信和协作。此外，通常使用事件驱动的总线和消息代理。

微服务和面向服务的架构都基于服务，并根据这些服务构建应用。这两种方法都展示了相似的范例和特性，如松散耦合和定义的独立性。然而，在它们的实现和集成中存在微妙的差异，例如，如图10所示。

图10 两种架构模式之间的差异

在面向服务的架构中，服务通过集成解决方案进行编排，因此被映射为一个整体的业务流程。相比之下，在微服务架构中，每个独立的微服务负责与其他服务进行通信。因此，在微服务架构中，也减少了对单一企业服务总线的依赖，并且在变更或调整时可以享受更大的灵活性。

然而，这两种架构模式之间的最大区别在于企业架构层次的结构。虽然面向服务的架构关注并整合整个企业架构或公司的IT架构，但微服务架构更多地关注公司中的单一应用或单一产品。因此，服务的结构在面向服务的架构和微服务之间通常也是不同的。在面向服务的架构中，服务描述了整个应用的功能，而单一微服务描述了应用的单一功能。因此，例如，这两种架构方法的部署单位和粒度也是不同的。总的来说，表1展示了最重要的区别。

方面	微服务	面向服务的架构
粒度	执行任务的小服务	经常覆盖整个系统的大服务
数据存储	每个服务可以有自己的数据存储	数据存储由几个服务使用
焦点	参考单一应用	公司范围内和焦点集成
集成	通过API层进行通信	通过企业服务总线进行通信
表1 微服务架构与面向服务架构的比较

微服务架构有可能导致服务间的拓扑关系变得复杂，需要对这种复杂性进行适当的管理。可以使用服务网格、API网关、分布式追踪等方式管理服务间的通信、监控和故障排除。

微服务目前是最现代的架构模式之一，拥有极高的流行度。例如Netflix和Google等数字化公司已根据微服务架构实现了它们的IT景观。微服务的一个主要优点是，由于其强大的模块化，服务可以轻松替换。因此，可以快速独立地实施并投入生产对服务的更改或新的功能需求。你可以大幅缩短新功能的上市时间。这种架构的另一个决定性优点是服务的粒度缩放。微服务可以根据需要进行水平扩展，并配备额外的资源。这样，你可以随时调整基础设施需求，测量成本，并确保始终可用。除了技术优势外，微服务还可以扩展敏捷开发过程，并分布独立开发团队的工作。

然而，应在实施过程中考虑微服务架构带来的一些挑战。分布式架构在服务间的通信中产生了复杂性，这可能意味着高网络延迟。由于大量的独立服务，端到端测试、日志记录和版本控制变得更加复杂。为了应对这种复杂性，通常需要部署额外的解决方案，例如集中式日志记录。经验表明，公司通常因为组织和文化变革而失败。每个团队都有自己的开发流程和责任，这通常与公司的核心业务流程解决方案相矛盾。（团队的利益和公司的利益可能不完全相同）

结论：使用微服务架构前必须经过深思熟虑。对于每个场景，都需要重新评估哪些原因支持引入微服务架构，哪些原因反对它，以及你希望获得哪些利益。通过SAP Business Technology Platform (SAP BTP) 及其相关服务，SAP提供了许多选项，以便按照这些原则来开发应用程序。