软件是必不可少的。 用于创建我们每天都依赖的软件的主要架构模式是什么？

世界几乎每一项人类活动都越来越依赖软件。从我们用来与他人联系的移动应用程序到医疗保健应用程序和深度学习模型，从金融技术系统到利用技术自动化许多活动的智能建筑，软件系统已经渗透并简化了人类生活的许多方面。为了让这些软件系统提供我们想要的解决方案，它们必须建立在正确的架构上以产生最佳结果。

什么是架构模式？

就像建筑物的架构一样，软件架构描述了将组件设计和收集到构成软件构建块的系统中。软件架构解释了软件程序的结构组成和元素之间的交互。为这些软件系统定义软件组织模式的原则称为架构模式。

架构模式捕获各种系统和软件元素的设计结构，以便它们可以被重用。在编写软件代码的过程中，开发人员在一个项目中、公司内部以及他们的职业生涯中多次遇到类似的问题。解决这个问题的一种方法是创建设计模式，为工程师提供解决这些问题的可重用方法，允许软件工程师在结构上为给定项目实现相同的输出。

从工程师的角度来看，软件架构模式很重要，因为它们提高了效率和生产力。由于开发人员已经了解项目中使用的架构模式，因此开发人员可以在任何时候加入有限的入职培训项目。新功能也可以毫无困难地添加到项目中，并且可以轻松解决常见的应用程序问题。

从客户的角度来看，架构模式优化了开发成本，加快了项目的时间线，并允许工程师交付高质量的产品。成本估算是基于对架构系统的理解，因此产品经理拥有更准确的项目成本，从而可以进行早期规划和预算。此外，明确定义的架构意味着系统已经过验证和范围。这有助于工程师专注于产品的基本要素，并允许管理人员为项目完成做好充分的计划。

有不同类型的软件架构模式，但在本文中，我们将探讨其中的五种以及它们如何成为软件开发的组成部分。

模型-视图-控制器模式

模型-视图-控制器 (MVC) 模式将应用程序分为三个组件：模型、视图和控制器。

模型是模式的核心组件，包含应用程序数据和核心功能。它是软件应用程序的动态数据结构，它控制着应用程序的数据和逻辑。但是，它不包含描述数据如何呈现给用户的逻辑。

视图显示应用程序数据并与用户交互。它可以访问模型中的数据，但无法理解数据，也无法理解如何操作数据。

控制器处理来自用户的输入并在模型和视图之间进行调解。它监听来自视图或用户的外部输入并创建适当的输出。控制器通过调用模型上的方法来与模型交互以生成适当的响应。

这三个组件通过某种形式的通知进行交互，例如事件或回调。这些通知包含状态信息，例如状态更改，它们被传达以更新这些组件。例如，可以将来自用户的外部事件传输到控制器以更新视图。因此，MVC 模式将软件组件解耦并允许轻松重用代码。

JavaScript、Python、Java 和 Swift 等主要编程语言都有 MVC 框架来开发 Web 和移动应用程序。 Web 应用程序框架，例如 Ruby on Rails 和 Django（用于 Python）都是基于这种架构。

MVC 模式的一个优点是多个工程师可以同时处理所有三个组件而不会发生冲突。此外，MVC 允许对相关输出进行逻辑分组，以从模型中生成大量视图。然而，一个缺点是导航框架可能很复杂，因为它引入了几个抽象层。

有用的参考资料：

• 通过编码恐怖理解模型-视图-控制器（2008）
• 来自原始 XEROX PARC 的 MVC 定义 (1978-79)
• Codecademy 对 MVC 的介绍

微服务模式

微服务模式涉及创建多个可以相互依赖地工作的应用程序或微服务。尽管每个微服务都可以独立开发和部署，但其功能与其他微服务交织在一起。

微服务模式中的一个关键概念是单元的单独部署。这创建了一个简化的交付管道，允许轻松部署微服务并提高应用程序的可扩展性。该模式的另一个关键特性是它是一种分布式架构，这意味着该结构的组件可以完全解耦，并可以通过 REST、SOAP 或 GraphQL 等远程访问协议进行访问。该模式的这种分布式特性使其具有高可扩展性。

微服务架构使用了几种设计模式：聚合器模式、API 网关设计模式、责任链模式、分支模式和异步消息传递设计模式。每种方法都提供了一种操作数据以产生服务的方法。

微服务架构的一个主要优势是每个微服务的独立部署。工程师可以独立于其他微服务编写和维护每个微服务，从而潜在地增加其功能和可扩展性。此外，由于每个微服务都很小，因此更容易重写和更新。微服务架构最适合具有小型组件的 Web 应用程序和网站。它对于边界明确的企业数据中心也很有用。微服务面临的一些挑战来自复杂性，尤其是在网络层。此外，将服务解耦以完全独立工作需要大量的架构专业知识。

有用的参考资料：

• Martin Fowler (2014) 的微服务定义
• 微服务架构中的分布式事务模式 (2018)
• 微服务教程，包括 Kubernetes 实践

客户端-服务器模式

在客户端-服务器架构模式中，有两个主要组件：客户端，即服务请求者，以及服务器，即服务提供者。尽管客户端和服务器可能位于同一系统中，但它们通常通过网络在不同硬件上进行通信。

客户端组件启动与服务器的某些交互以生成所需的服务。客户端组件具有描述所需服务的端口，而服务器具有描述它们提供的服务的端口。这两个组件都由请求/回复连接器链接。这种架构模式的一个典型例子是万维网。客户端-服务器模式也用于在线应用程序，例如文件共享和电子邮件。

一个简单的例子是网上银行服务。当银行客户使用网络浏览器访问网上银行服务时，客户端会向银行的网络服务器发起请求。在这种情况下，Web 浏览器是客户端，使用客户的登录详细信息访问银行的 Web 服务器以获取数据。应用程序服务器使用银行的业务逻辑解释这些数据，然后将适当的输出提供给 Web 服务器。

这种架构模式的一个主要优势是数据的中央计算；所有文件都存储在该网络的中心位置。因此，数据以及网络外围设备都是集中控制的。然而，一个缺点是服务器的购买和管理成本很高。

客户端-服务器模型与点对点架构模式相关，通常被描述为该模式的一个子类别。后者使用分散系统，其中对等方直接相互通信。

有用的链接：

• 什么是客户端-服务器架构？
• Red Hat 对 REST 架构的介绍

控制器-响应者模式

这通常被称为主/从架构模式，但由于它不是一个有用的比喻，一些工程师和软件公司采用了替代术语，如主/从、主/副本、父/助手、主/副本或控制器/响应者模式。最值得注意的是，IEEE 已将此作为网络技术的更好术语。

与客户端-服务器架构模式一样，此模式由两个组件组成：控制器和响应器。控制器组件在相同的响应器组件之间分配输入或工作，并从每个响应器生成的结果中生成复合结果。

简单来说，控制器是实际的数据保管者，而响应者复制存储在控制器数据库中的数据。写入数据仅在控制器数据库中完成，由响应者数据库读取。控制器确定响应者的通信优先级并对其进行控制。这与点对点架构模式不同，其中计算机平等通信并分担责任。

控制器-响应者模型的一个示例包括使用盒式磁带或光盘记录器完成的复制。

这种模式的一个关键优势是可以从响应程序组件中读取分析应用程序，而无需更改控制器组件的数据内容。此外，响应者可以离线并同步回来，而不会浪费任何时间。但是，当控制器发生故障时，所有数据都可能丢失，并且可能必须重新启动应用程序。在这些情况下，响应者可能会被提升为控制者，但并非没有一些数据和技术缺陷。

有用的链接：

• 来自 IEEE (2006) 的分布式进化计算的主从架构分析
• Packt 的主从架构

分层图案

分层架构模式在开发人员中最为常见。它对于包含多组子任务的程序很有用，每组子任务都处于不同的抽象级别。这些子任务中的每一个都由软件中的一个层表示——一个产生一组内聚服务的模块单元——并且每一层以单向模式向下一个更高层提供服务。

每一层在应用程序中都有一个特定的角色，该角色与其他层的角色相关联。例如，表示层（也称为 UL 层）将处理所有 UI 和浏览器通信逻辑，而业务逻辑层将执行某些业务请求。

其他类型的层包括应用程序层和数据访问或持久层，然后访问数据库层。这允许分离数据库层，并使您能够从 Oracle 服务器切换到 SQL 服务器，而不会影响其他层——它可以降低转换成本。

这些层以单向模式交互，因此当用户发起输入（例如单击按钮）时，表示层将消息发送到较低层，即应用层，后者又调用业务层，然后是数据访问数据库的访问层。因此，呼叫以分层模式向下流动，从较高层流向较低层。

分层架构模式存在于许多电子商务 Web 应用程序和桌面应用程序中。它对于需要快速构建的应用程序和需要采用传统 IT 流程的企业应用程序也很有用。此外，分层模式非常适合需要严格的可测试性标准的应用程序。

这种模式的一个关键优势是它允许以一种简单的方式来编写一个组织良好的应用程序。由于它是一种流行的架构模式，因此开发人员已经了解它的使用方式。但是，它确实有两个主要缺点：复杂性和添加更多层的成本。这些层最终可能难以拆分。

有用的参考资料：

• Mark Richards 的软件架构模式中的分层架构
• 软件架构模式 — Priyal Walpita 的分层架构

底线

其他几种架构模式，包括管道过滤器模式、黑板模式、代理模式和事件总线模式，在软件开发的不同方面也很有用。这个概念对所有人都是一样的：定义应用程序的基本特征，增强产品的功能，提高应用程序构建过程的效率和生产力。

但是，使用错误的架构模式可能会延迟您的项目，甚至可能导致软件故障。因此，关键是要充分了解架构模式以及它们最适合哪些应用程序，以便您可以选择适合您的软件需求的应用程序。

原文：https://www.redhat.com/architect/5-essential-patterns-software-architec…

本文：https://jiagoushi.pro/node/1930