📜  构图模式

📅  最后修改于: 2020-11-24 06:02:03             🧑  作者: Mango


软件组成是构建软件产品的方式。基本上,它处理高级软件体系结构图,其中您的软件的不同模块将针对特定的业务目标进行通信。在本章中,我们将学习组织中广泛使用的不同软件组成模式。在微服务中,我们将每个函数分为一个进程。这些服务中的每一个本质上都是独立且完整的堆栈。

功能分解在构建微服务中起着重要作用。它为您的应用程序提供了敏捷性,灵活性和可扩展性。

聚合模式

聚集器模式是开发微服务时可以实现的最简单的Web模式。在这种组合模式中,一个简单的Web模块将充当负载平衡器,这意味着它将根据需求调用不同的服务。下图描述了一个具有聚合器设计的简单微服务Web应用程序。如下图所示,“聚合器”负责一个一个地调用不同的服务。如果我们需要对服务A,B和C的结果应用任何业务逻辑,则可以在聚合器本身中实现业务逻辑。

聚合模式

聚合器可以再次作为另一项服务提供给外部世界,并在需要时可由其他用户使用。在开发聚合器模式Web服务时,我们需要记住,我们的服务A,B和C都应具有自己的缓存层,并且本质上应该是全栈的。

代理模式

代理微服务模式是聚合器模型的变体。在此模型中,我们将使用代理模块而不是聚合模块。代理服务可以分别调用不同的服务。

代理模式

在代理模式下,我们可以通过提供转储代理层来建立一级额外的安全性。该层的作用类似于接口。

链式

顾名思义,这种类型的构图将遵循链结构。在这里,我们将不在客户端和服务层之间使用任何东西。取而代之的是,我们将允许客户直接与服务进行通信,并且所有服务都将以一种服务的输出将成为下一个服务的输入的方式进行链接。下图显示了典型的链接模式微服务。

链式

这种体系结构的一个主要缺点是,客户端将被阻塞,直到整个过程完成为止。因此,强烈建议保持链条的长度尽可能短。

分支微服务模式

分支微服务是聚合器模式和链模式的扩展版本。在这种设计模式下,客户端可以直接与服务进行通信。同样,一项服务可以一次与多个服务进行通信。以下是分支微服务的示意图。

分支微服务模式

分支微服务模式允许开发人员动态配置服务调用。所有服务调用将以并发方式发生,这意味着服务A可以同时调用服务B和C。

共享资源模式

共享资源模式实际上是前面提到的所有类型的模式的综合体。在这种模式下,客户端或负载平衡器将在必要时直接与每个服务进行通信。这是大多数组织广泛采用的最有效的设计模式。以下是共享资源设计模式的示意图。

共享资源模式