快速总结：- 软件架构模式在其随着时间的推移扩展和满足用户需求的能力中起着至关重要的作用。本文涵盖了不同类型的软件架构模式、它们的重要性和比较分析，以帮助您选择最佳模式。
# 你必须知道的 10 种最佳软件架构模式
# 快速链接
- 介绍
- 什么是架构模式？
- 软件架构模式的重要性
- 软件架构模式与设计模式
- 不同类型的软件架构模式
- 1. 分层架构模式
- 2. 事件驱动架构
- 3. 微内核架构
- 4. 微服务架构
- 5. 基于空间的架构
- 6. 客户端 - 服务器架构
- 7. 主从架构
- 8. 管道过滤器架构
- 9. 经纪人架构
- 10. 点对点架构
- 不同软件架构模式对比分析
任何软件中的缺陷都会对组织的业务产生重大影响。任何软件失败的主要原因都可能是选择了错误的软件架构模式。但是有了先验知识，您将能够指导设计人员和开发人员设计组件及其反应方式。
经常看到公司在没有正式架构的情况下开始应用程序开发过程。然而，他们往往会忽略架构模式的缺失会迫使开发团队采用没有指导方针的传统模式。最终，他们的代码缺乏明确的角色、责任和彼此之间的关系。
例如，在线银行应用程序不需要像微服务模式这样的复杂架构。它可以简单地使用客户端 - 服务器架构来获取请求。但是，如果没有这种规划，应用程序可能会变得复杂，无法返回或失去重组过程中的巨额投资。规划架构模式有助于事先分析风险并避免对业务产生任何不利影响。
为了有一个清晰的理解，让我们探索一下什么是软件架构模式以及对其中一些类型的完整解释。
# 什么是架构模式？
架构模式可以称为大纲，它允许您表达和定义各种软件系统的结构模式。它是一个可重用的解决方案，提供了一组预定义的子系统、角色和职责，包括用于定义它们之间关系的规则和路线图。它可以帮助您解决各种软件工程问题，例如性能限制、高可用性、最小化业务风险等。
即使架构模式是系统的粗略图像或蓝图，它也不是实际的架构。相反，它是一个帮助您理解软件架构元素的概念。可以有无数的架构实现相同的模式。这就是为什么模式被称为 “严格描述和常用” 的原因。系统的成功取决于软件架构的选择。
架构模式的著名示例是微服务、消息总线、服务请求者 / 消费者、MVC 模式、MVVM、微内核、n 层、领域驱动的设计组件和表示抽象控制。
# 软件架构模式的重要性是什么？
软件架构模式具有重要意义，因为它可以解决不同领域内的各种问题。例如，复杂的用户请求可以轻松地分割成更小的块并分布在多个服务器上，而不是依赖于单个服务器。在另一个示例中，可以通过划分软件的各个部分而不是一次测试整个事物来简化测试协议。
以下是为什么软件架构模式对任何软件应用程序都至关重要的更多原因：
# 定义应用程序的基本特征：
了解每种架构的特征、优势和劣势对于选择合适的架构来满足您的业务目标非常重要。据观察，架构模式有助于定义应用程序的基本特征和行为。例如，一些架构模式可以自然地用于高度可扩展的应用程序，而其他架构模式可以用于敏捷应用程序。
# 保持质量和效率：
您构建的任何应用程序都极有可能面临质量问题。根据您的软件开发质量属性，选择架构模式可以帮助最大限度地减少质量问题，同时保持效率。
# 提供敏捷性：
软件应用程序在软件开发期间甚至在生产之后经历大量修改和迭代是很自然的。因此，预先规划核心软件架构可为应用程序提供敏捷性，并使未来的审核毫不费力。
# 问题解决：
对软件架构的事先规划和知识可以清楚地了解应用程序及其组件将如何运行。有了适当的架构，开发团队可以采用最佳实践来解决复杂的流程并解决未来的任何错误。
# 提高生产力：
不管一个人拥有关于编程语言、框架或应用程序的技能和知识，都必须有一定的标准化原则。有了合适的应用模式，公司可以快速掌握项目的状态。此外，当架构模式到位以明确项目范围时，生产率会提高。
# 软件架构模式与设计模式
架构模式和设计模式之间只有一线之隔，大多数人会混淆这两者。对于基础知识，让我们假设您的团队有一项任务是建造一所房子并住在里面。
首先，他们必须先计划好，然后再将砖块和水泥放在空地上。此外，即使在规划好房子之后，还有更多的东西要让它值得居住 —— 他们需要基本的便利设施，比如厨房用具、床上用品、洗浴用品等等。在这个类比中，房子应该看起来如何代表建筑模式，而房子的室内设计代表设计模式。
在软件系统中，当您必须创建业务逻辑、数据库逻辑、UI 等时考虑架构，而在实现业务逻辑或数据库逻辑时使用软件设计模式。
# 不同类型的软件架构模式
让我们讨论一些帮助许多软件企业扩展业务的流行架构模式：
# 1. 分层架构模式
您可能听说过多层，也称为分层架构或 n 层架构。这种架构在设计师和软件架构师中广受欢迎，因为它与许多初创公司和成熟企业中的传统 IT 通信安排有共同点。通常，分层架构分为四个不同的层：表示层、业务层、持久性层和数据库层；但是，该模式并不局限于指定的层，可以有应用层或服务层或数据访问层。Java EE 等流行框架使用了这种架构模式。
假设一个软件工程师正在构建一个大型应用程序，您发现自己在架构模式中使用了所有四个层。另一方面，小型企业可以将业务层和持久层组合成一个单元，主要是当后者作为业务逻辑层组件的一个组成部分使用时。
这种模式很突出，因为每一层在应用程序中都扮演着不同的角色，并被标记为关闭。这意味着请求必须通过其正下方的层才能到达下一层。它的另一个概念 —— 隔离层 —— 使您能够在一个层内修改组件而不影响其他层。
为了简化这个过程，让我们举一个电子商务 Web 应用程序的例子。处理购物车活动（例如计算购物车）所需的业务逻辑直接从应用程序层获取到表示层。在这里，应用层充当集成层，在数据层和表示层之间建立无缝通信。此外，最后一层是数据层，用于独立维护数据，无需应用服务器和业务逻辑的干预。
用法：
- 需要快速构建的应用程序。
- 需要传统 IT 部门和流程的企业应用程序。
- 适用于开发人员经验不足且架构模式知识有限的团队。
- 需要严格的可维护性和可测试性标准的应用程序。
缺点：
- 没有明确角色的杂乱无章的源代码和模块可能会成为应用程序的问题。
- 跳过前面的层来创建紧密耦合可能会导致充满复杂相互依赖关系的逻辑混乱。
- 基本修改可能需要完全重新部署应用程序。
图表：
# 2. 事件驱动架构模式
如果您正在寻找一种敏捷且高性能的架构模式，那么您应该选择事件驱动的架构模式。它由异步接收和处理事件的分离的、单一用途的事件处理组件组成。这种模式协调所有事件的产生、检测和消费行为，以及它们引起的响应。
事件驱动的架构风格由两种拓扑结构组成 —— 中介者和代理者。当需要通过中央调解器在事件总线中编排多个步骤时，使用调解器。另一方面，代理用于在不使用中央调解器的情况下将事件链接在一起。
使用事件驱动架构的一个很好的例子是电子商务网站。事件驱动的架构使电子商务网站能够在高需求时对各种来源做出反应。同时，它避免了应用程序的任何崩溃或任何资源的过度配置。
用法：
- 对于单个数据块仅与几个模块交互的应用程序。
- 帮助用户界面。
缺点：
- 只有在独立的情况下才能测试单个模块，否则需要在功能齐全的系统中进行测试。
- 当多个模块处理相同的事件时，错误处理对结构化变得具有挑战性。
- 如果事件有不同的需求，则为事件开发系统范围的数据结构可能会变得很困难。
- 对于解耦和独立的模块，维护基于事务的一致性机制可能会变得复杂。
图表：
# 3. 微内核架构模式
这种架构模式由两种类型的组件组成 —— 一个核心系统和几个插件模块。虽然核心系统以最小的功能工作以保持系统运行，但插件模块是具有专门处理的独立组件。
如果我们从业务应用程序的角度来看，核心系统可以定义为通用业务逻辑，没有针对特殊情况、特殊规则或复杂条件流程的自定义代码。另一方面，插件模块旨在增强核心系统以产生额外的业务能力。
以任务调度器应用为例，微内核包含调度和触发任务的所有逻辑，而插件包含特定的任务。只要插件遵循预定义的 API，微内核就可以触发它们，而无需了解实现细节。
用法：
- 在基本例程和高阶规则之间有明确划分的应用程序。
- 具有一组固定的核心例程和一组需要频繁更新的动态规则的应用程序。
缺点：
- 插件必须具有良好的握手代码，以便微内核知道插件安装并准备好工作。
- 如果有多个插件依赖于微内核，那么更改微内核几乎是不可能的。
- 提前为核函数选择合适的粒度是很困难的，后期会更加复杂。
图表：
# 4. 微服务架构模式
微服务架构模式被视为单体应用程序和面向服务架构的可行替代方案。这些组件通过有效、简化的交付管道作为单独的单元进行部署。该模式的好处是增强了可伸缩性和应用程序内的高度解耦。
由于其解耦和独立的特性，组件通过远程访问协议进行访问。此外，相同的组件可以单独开发、部署和测试，而无需与任何其他服务组件相互依赖。
Netflix 是微服务架构模式的早期采用者之一。该架构允许工程团队在小团队中工作，负责数百个微服务的端到端开发。这些微服务协同工作，每天为数百万 Netflix 客户流式传输数字娱乐。
用法：
- 需要快速开发的业务和 Web 应用程序。
- 具有小型组件的网站、具有明确边界的数据中心以及全球远程团队。
缺点：
- 为服务组件设计正确的粒度级别始终是一项挑战。
- 所有应用程序都不包括可以拆分为独立单元的任务。
- 由于任务分布在不同的微服务中，性能可能会受到影响。
图表：
# 5. 基于空间的架构模式
元组空间的概念 —— 分布式共享内存的概念是该架构名称的基础。基于空间的模式包括两个主要组件 —— 一个处理单元和一个虚拟化中间件。
处理单元包含部分应用程序组件，包括基于 Web 的组件和后端业务逻辑。虽然较小的 Web 应用程序可以部署在单个处理单元中，但较大的应用程序可以将应用程序功能拆分为多个处理单元以避免功能崩溃。此外，虚拟化中间件组件包含控制数据同步和请求处理的各个方面的元素。它们可以定制编写，也可以作为第三方产品购买。
投标拍卖网站可以被认为是这种架构模式的合适示例。它的功能是网站通过浏览器请求接收来自互联网用户的出价。收到请求后，网站会记录带有时间戳的出价，更新最新出价的信息，并将数据发送回浏览器。
用法：
- 具有庞大用户群和持续请求负载的应用程序和软件系统。
- 应该解决可伸缩性和并发性问题的应用程序。
缺点：
- 在不干扰多个副本的情况下缓存数据以提高速度是一项复杂的任务。
图表：
# 6. 客户端 - 服务器架构模式
客户端 - 服务器架构模式被描述为具有两个主要组件的分布式应用程序结构 —— 客户端和服务器。这种架构促进了客户端和服务器之间的通信，它们可能在也可能不在同一网络下。客户端请求从服务器获取特定资源，其形式可能是数据、内容、服务、文件等。服务器识别发出的请求并通过发送请求的资源适当地响应客户端。
客户端和服务器的功能特性是在应用程序中相互交互的程序示例。这种架构的功能非常灵活，因为单个服务器可以服务多个客户端，或者单个客户端可以使用多个服务器。服务器可以根据它们提供的服务或资源进行分类，而不管它们如何执行。
电子邮件是使用客户端 - 服务器模式构建的模型的一个突出示例。当用户 / 客户端搜索特定电子邮件时，服务器会查看资源池并将请求的电子邮件资源发送回用户 / 客户端。这也有助于您改善用户体验。
用法：
- 电子邮件、网上银行服务、万维网、网络打印、文件共享应用程序、游戏应用程序等应用程序。
- 专注于实时服务的应用程序（如电信应用程序）是使用分布式应用程序结构构建的。
- 需要受控访问并为大量分布式客户端提供多种服务的应用程序。
- 具有集中式资源和服务的应用程序，必须分布在多个服务器上。
缺点：
- 不兼容的服务器容量可能会变慢，从而导致性能瓶颈。
- 服务器通常容易出现单点故障。
- 改变模式是一个复杂而昂贵的过程。
- 服务器维护可能是一项艰巨且昂贵的任务。
图表：
# 7. 主从架构模式
想象一个数据库同时接收多个类似请求。自然地，同时处理每个请求会使应用程序过程复杂化并减慢速度。这个问题的解决方案是主从架构模式，主数据库启动多个从组件以快速处理这些请求。
正如标题所暗示的，主从架构模式可以被描绘成一个主将任务分配给它的从属。一旦从属组件完成它们的任务，分布式任务将由主组件编译并显示为结果。
必须注意，主机对从属组件具有绝对控制权和权力，可以确定它们的通信和功能优先级。这种模式的独特之处在于每个从站将同时处理请求，同时提供结果。这也意味着在每个从站都将结果返回给主站之前，从站操作不会被视为完成。
这种模式非常适合可以分成更小的部分来执行类似请求的应用程序。一个合适的例子是需要大量多任务处理作为其重要组成部分的数据库应用程序。
用法：
- 开发可能需要多处理器兼容架构的操作系统。
- 必须将较大的服务分解为较小的组件的高级应用程序。
- 通过分布式网络处理存储在不同服务器中的原始数据的应用程序。
- 遵循多线程以提高其响应能力的 Web 浏览器。
缺点：
- 主组件的故障可能导致数据丢失，而从组件上没有备份。
- 系统内的依赖性可能导致从属组件的故障。
- 由于从属组件的隔离性质，间接成本可能会增加。
图表：
# 8. 管道过滤器架构模式
管道过滤器架构模式处理单向流中的数据流，其中组件称为过滤器，管道是连接这些过滤器的那些。处理数据链发生在管道将数据传输到过滤器的地方，一个过滤器的结果成为下一个过滤器的输入。该架构的功能是将重要的组件 / 流程分解为可以同时处理的独立和多个组件。
管道过滤器模式最适合使用 Web 服务处理流中数据的应用程序，并且可以将简单的序列创建为复杂的结构。编译器可以被认为是具有这种架构模式的合适示例，因为每个过滤器都执行词法分析、解析、语义分析和代码生成。
用法：
- 它可用于促进简单的单向数据处理和转换的应用程序。
- 使用电子数据交换和外部动态列表等工具的应用程序。
- 开发用于错误检查和语法分析的数据编译器。
- 在 UNIX 等操作系统中执行高级操作，其中程序的输出和输入按顺序连接。
缺点：
- 如果基础架构设计不可靠，则过滤器之间可能会丢失数据。
- 最慢的过滤器限制了整个架构的性能和效率。
- 在过滤器之间传输期间，数据转换开销可能会增加。
- 该架构的持续转型特性使其对交互系统的用户友好性降低。
图表：
# 9. 代理架构模式
代理模式用于构建具有解耦组件的分布式系统。通过调用远程服务，组件可以在代理架构模式中与其他组件交互。此外，代理负责组件之间的所有协调和通信。
客户端、服务器和代理是代理模式的三个主要组成部分。通常，代理将有权访问与特定服务器相关的所有服务和特征。当客户端向代理请求服务时，代理会将它们重定向到合适的服务类别以进行进一步处理。
这种架构模式的主要好处之一是它如何以动态方式管理与对象相关的操作，例如更改、添加、删除或重定位。最后，这种架构模式将所有与通信相关的代码从应用程序中分离出来，允许应用程序在分布式或单台计算机上运行。由于这些优势，代理架构已经流行起来。
用法：
- 用于消息代理软件，如 Apache ActiveMQ、Apache Kafka、RabbitMQ 和 JBoss Messaging。
- 用于构建具有解耦组件的分布式系统。
缺点：
- 容错能力浅。
- 要求服务描述标准化。
- 隐藏层可能会降低软件性能。
- 更高的延迟并且需要更多的部署努力。
图表：
# 10. 点对点架构模式
在对等架构模式中，单个组件称为对等。对等点可以充当客户端、服务器或两者兼而有之，并随着时间的推移动态地改变其角色。作为客户端，对等点可以向其他对等点请求服务，作为服务器，对等点可以向其他对等点提供服务。对等和客户端 - 服务器架构之间的显着区别在于网络上的每台计算机都具有相当大的权限，并且没有集中式服务器。随着越来越多的计算机加入网络，它的容量也会增加。
对等架构模式的一个很好的例子是文件共享网络，如 Skype、BitTorrent 和 Napster。在 BitTorrent 中，点对点架构用于以分散的方式在互联网上分发数据和文件。通过使用此协议，可以轻松传输大型视频和音频文件。在 Skype 中，您可以使用 VoIP P2P 架构模式进行语音呼叫并向其他用户发送文本消息。通过这种方式，您可以使用对等架构进行文件共享、消息传递、协作等。
用法：
- Gnutella 和 G2 等文件共享网络。
- 基于加密货币的产品，例如比特币和区块链。
- P2PTV、PDTP 等多媒体产品。
缺点：
- 无法保证高质量的服务。
- 实现强大的安全性具有挑战性。
- 性能取决于连接到网络的节点数量。
- 无法备份文件或文件夹。
- 可能需要特定的接口来读取文件。
图表：
# 不同软件架构模式对比分析
到目前为止，我们已经了解了不同类型的架构模式。现在，您会为您的软件类型选择哪种架构？你需要做出正确的选择。
让我们看一下下表。
