10中最常见的架构模式

https://nix-united.com/blog/10-common-software-architectural-patterns-part-1/

您是打算启动 IT 应用程序的企业家吗？或者，您是负责构建新的企业 IT 应用程序的企业 IT 经理吗？在开始构建系统之前，您需要确定最合适的软件架构。我们在这里解释了 10 大软件架构模式。

在本文中，我们将讨论与软件架构模式最相关的问题：

• [软件架构模式：它是什么？]
• [你怎么知道你的软件架构好不好？]
• [10 种常见的软件架构模式]
• [为您的战略应用程序评估软件架构模式？]

软件架构模式：它是什么？

在深入研究常见的架构模式之前，让我们先了解什么是软件架构。软件架构是传达以下信息的 IT 系统的图形表示：

• 系统的组织；
• 不同的组件相对于它们的功能；
• 组件之间如何交互。

示意图表示是软件架构师使用的设计原则和他们做出的决定的结果。典型的软件架构需要有关安全性、性能、可管理性等方面的决策。

为什么要关注软件架构？

设计原则、体系结构决策及其结果，即软件体系结构共同使软件系统能够交付其业务、操作和技术目标。由于以下原因，您需要获得正确的软件架构：

• 一个软件开发团队，使第一套决策的软件体系结构模式选择过程中。在此阶段之前，只有业务需求可用。第一组决策在任何项目中都至关重要，因为次优决策可能会导致预算和进度超支。
• 您的业务利益相关者需要了解您的进展。软件架构充当视觉交流工具，因此他们可以理解您正在构建的系统。
• 软件架构模型可以很容易地在其他项目中重用它们，因为您现在知道自己所做的决定和各种权衡。

你怎么知道你的软件架构好不好？

以下迹象表明您拥有良好的软件架构：

• 软件易于维护；
• 业务利益相关者可以很容易地理解它；
• 好的软件架构可以长期使用；
• 这种架构模式灵活、适应性强、可扩展；
• 它应该促进可扩展性；
• 团队可以轻松添加功能，而且系统性能不会因此而降低；
• 没有重复的代码；
• 系统可以轻松重构。

10 种常见的软件架构模式

是时候研究 10 种最常见的模式了，所以，我们开始吧：

模式#1：分层架构

我们经常使用“N 层架构”或“多层架构”来表示“分层架构模式”。它是代码分层排列的最常用模式之一。这种模式的主要特征如下：

• 最外层是数据进入系统的地方。数据通过后续层到达最内层，即数据库层。
• 这种模式的简单实现至少有3层，分别是表示层、应用层和数据层。用户使用 GUI 访问表示层，而应用层运行业务逻辑。数据层有一个用于存储和检索数据的数据库。

这种模式有以下优点：

• 由于层是隔离的，因此维护软件很容易。
• 开发团队发现管理软件基础设施很容易，因此，很容易开发大规模的 Web 和云托管应用程序。

Java EE 等流行框架使用这种模式。

也有一些缺点，如下所示：

• 代码可能变得太大。
• 相当一部分代码仅在层之间传递数据，而不执行任何业务逻辑，这会对性能产生不利影响。

模式#2：客户端-服务器

“客户端-服务器软件架构模式”是另一种常用的模式，其中有 2 个实体。它有一组客户端和一个服务器。以下是此模式的主要特征：

• 客户端组件向服务器发送请求，服务器处理这些请求并做出响应。
• 当服务器接受来自客户端的请求时，它会通过特定协议打开与客户端的连接。
• 服务器可以是有状态的或无状态的。有状态服务器可以接收来自客户端的多个请求。它维护来自客户端的请求记录，该记录称为“会话”。

电子邮件应用程序是这种模式的好例子。该模式有几个优点，如下所示：

• 客户端使用授权访问从服务器访问数据，这改进了数据共享。
• 访问服务是通过“用户界面”(UI) 进行的，因此无需运行终端会话或命令提示符。
• 无论平台或技术堆栈如何，都可以构建客户端-服务器应用程序。
• 这是一个分布式模型，每个组件都有特定的职责，这使得维护更容易。

客户端-服务器架构的一些缺点如下：

• 当请求过多时，服务器可能会过载。
• 支持多个客户端的中央服务器代表“单点故障”。

模式#3：主从

当客户端发出同一请求的多个实例时，“主从架构模式”很有用。请求需要同时处理。以下是其主要特征：

• 主机在接收到同时请求时启动从机。
• Slave 并行工作，只有当所有 Slave 完成对各自请求的处理后，操作才算完成。

这种模式的优点如下：

• 应用程序从从站读取，对主站没有任何影响。
• 使从站离线以及稍后与主站同步不需要停机。

任何涉及多线程的应用程序都可以使用这种模式，例如，电能系统中使用的监控应用程序。

这种模式有一些缺点，例如：

• 此模式不支持自动故障转移系统，因为如果原始主服务器发生故障，则需要手动将从服务器提升为主服务器。
• 只能在主机中写入数据。
• Master 的故障通常需要停机和重启，此外，在这种情况下可能会发生数据丢失。

模式 4：管道过滤器

假设您手头有复杂的处理。您可能会将其分解为单独的任务并单独处理它们。这就是“管道过滤器”架构模式的用武之地。以下特点使其与众不同：

• 每个任务的代码都比较少。您将其视为一个独立的“过滤器”。
• 您可以在每个过滤器中部署、维护、扩展和重用代码。
• 每个过滤器处理的数据流通过“管道”。

由于以下优点，编译器经常使用这种模式：

• 有一些重复的步骤，例如阅读源代码、解析、生成代码等。这些可以很容易地组织为单独的过滤器。
• 如果使用管道将数据输入安排为流，则每个过滤器都可以并行执行其处理。
• 这是一个弹性模型，因为管道可以重新安排工作并分配给该过滤器的另一个实例。

注意一些缺点：

• 这种模式很复杂。
• 除非您使用可靠的基础架构，否则过滤器之间的数据可能会在出现故障时丢失。

模式 5：代理

考虑具有组件的分布式系统，这些组件提供彼此独立的不同服务。独立组件可以是不同服务器上的异构系统，但是，客户端仍然需要为他们的请求提供服务。“代理架构模式”就是一个解决方案。

它具有以下广泛的特点：

• 代理组件协调客户端和服务器之间的请求和响应。
• broker拥有服务器的详细信息及其提供的个人服务。
• 代理架构模式的主要组件是client、server和broker。它还具有用于client和server的bridges和proxies。
• 客户端发送请求，broker找到正确的server来路由请求。
• 它还将响应发送回客户端。

IBM MQ 等消息代理软件使用这种模式。该模式有几个明显的优点，例如：

• 由于分布式环境，开发人员没有任何限制，他们只需使用代理。
• 这种模式有助于在分布式环境中使用面向对象的技术。

模式 6：点对点 (P2P)

“点对点 (P2P) 模式”与客户端-服务器模式明显不同，因为网络上的每台计算机都具有相同的权限。P2P 模式的主要特征如下：

• 没有一个中央服务器，每个节点都具有相同的功能。
• 每台计算机都可以充当客户端或服务器。
• 当更多计算机加入网络时，网络的整体容量会增加。

文件共享网络是 P2P 模式的好例子。比特币和其他加密货币网络是其他例子。P2P网络的优点如下：

• P2P 网络是去中心化的，因此更安全。您一定已经听说过很多关于比特币网络安全性的信息。
• 黑客无法通过破坏一台服务器来破坏网络。

在重负载下，P2P 模式具有性能限制，正如围绕比特币交易的问题贯穿始终。

模式#7：事件总线模式

当组件仅在有要处理的数据时才起作用时，有一些应用程序。在其他时候，这些组件是不活动的。“事件总线模式”适用于这些，它具有以下特点：

• 作为事件总线的中央代理接受输入。
• 不同的组件处理不同的功能，因此，事件总线将数据路由到适当的模块。
• 未接收与其功能有关的任何数据的模块将保持不活动状态。

想想一个使用 JavaScript 的网站。用户的鼠标点击和击键是数据输入。事件总线将整理这些输入并将数据发送到适当的模块。这种模式的优点如下：

• 此模式可帮助开发人员处理复杂性。
• 这是一种可扩展的架构模式。
• 这是一个可扩展的架构，新功能只需要一种新类型的事件。

这种软件架构模式也用于 Android 开发。

这种模式的一些缺点如下：

• 相互依赖组件的测试是一个复杂的过程。
• 如果不同的组件处理相同的事件需要复杂的处理来进行错误处理。
• 一定数量的消息传递开销是这种模式的典型特征。

如果事件总线出现故障，开发团队应该提供足够的后备选项。

模式 #8：模型-视图-控制器 (MVC)

“模型-视图-控制器 (MVC) 架构模式”涉及分离应用程序的数据模型、表示层和控制方面。以下是它的特点：

• 这里有三个构建块，即模型、视图和控制器。
• 应用程序数据驻留在模型中。
• 用户通过视图查看应用程序数据，但是，视图不能影响用户将如何处理数据。
• 控制器是模型和视图之间的构建块。视图触发事件，随后控制器对其进行操作。操作通常是对模型的方法调用。响应显示在视图中。

这种模式很受欢迎。许多 Web 框架（如 Spring 和 Rails）都使用它，因此，许多 Web 应用程序都使用这种模式。它的优点如下：

• 使用此模型可加快开发速度。
• 开发团队可以向用户呈现多个视图。
• 对 UI 的更改在 Web 应用程序中很常见，但是，MVC 模式不需要对其进行更改。
• 该模型在呈现给用户之前不会格式化数据，因此，您可以将此模式用于任何界面。

还有一些缺点，例如：

• 使用这种模式，代码具有新的层，使得导航代码变得更加困难。
• 这种模式通常有一个学习曲线，开发人员需要了解多种技术。

模式#9：黑板

从“人工智能”(AI) 开发的世界中脱颖而出，“黑板架构模式”更像是一种权宜之计。其显着特点如下：

• 当您处理 AI 或“机器学习”(ML) 等新兴领域时，您不一定要使用固定的架构模式。你从黑板模式开始，随后，当领域成熟时，你采用不同的架构模式。
• 共有三个组件，即黑板、知识资源集合和控制器。
• 应用系统将相关信息存储在黑板中。
• 知识资源可以是 AI 或 ML 上下文中的算法，用于收集信息和更新黑板。
• 控制器从黑板上读取数据并更新应用程序“资产”，例如机器人。

图像识别、语音识别等使用这种架构模式。它有几个优点，如下所示：

• 该模式有利于实验。
• 您可以重复使用算法等知识资源。

还有一些限制，例如：

• 这是一个中间安排。最终，您将需要找到一个合适的架构模式，但是，您不确定自己会找到正确的答案。
• 系统内的所有通信都通过黑板进行，因此，应用程序无法处理并行处理。
• 测试可能很困难。

模式#10：解释器

特定于某些用例的模式，“解释器模式”处理编程语言的语法。它为该语言提供翻译。它的工作原理如下：

• 您实现了一个接口，该接口有助于在编程语言中解释给定的上下文。
• 该模式使用表达式层次结构。
• 它还使用包含表达式的树结构。
• 模式外部的解析器生成用于评估表达式的树结构。

这种模式的用途是从编程语言中的符号创建“类”。您为语言创建语法，从而使句子的解释成为可能。网络协议语言和 SQL 使用这种模式。