经常看到公司在没有正式架构的情况下开始应用程序开发过程。然而，他们往往会忽略，缺少架构模式会迫使开发团队采用没有指导方针的传统模式。最终，他们最终得到的代码缺乏明确的角色、责任和彼此之间的关系。
例如，在线银行应用程序不需要像微服务模式这样的复杂架构。它可以简单地使用客户端-服务器架构来开发以获取请求。但是，如果没有这个计划，应用程序可能会变得复杂，无法回头或在重组过程中损失巨额投资。规划架构模式有助于事先分析风险并避免对业务产生任何不利影响。
为了有一个清晰的理解，让我们探索什么是软件架构模式，并对其某些类型进行完整解释。
架构模式可以称为大纲，它允许您为各种软件系统表达和定义结构模式。它是一个可重用的解决方案，提供一组预定义的子系统、角色和职责，包括用于定义它们之间关系的规则和路线图。它可以帮助您解决各种软件工程问题，例如性能限制、高可用性、最小化业务风险等。
尽管架构模式是系统的粗略图像或蓝图，但它并不是实际的架构。相反，它是一个帮助您理解软件架构元素的概念。可以有无数的架构实现相同的模式。这就是为什么模式被称为“严格描述和常用”的原因。系统的成功取决于软件架构的选择。
架构模式的著名示例是微服务、消息总线、服务请求者/消费者、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 中，点对点架构用于以分散的方式在 Internet 上分发数据和文件。通过使用此协议，可以非常轻松地传输大型视频和音频文件。在 Skype 中，您使用 VoIP P2P 架构模式来拨打语音电话并向其他用户发送文本消息。通过这种方式，您可以使用对等架构进行文件共享、消息传递、协作等。
用法：
文件共享网络，例如 Gnutella 和 G2。基于加密货币的产品，例如比特币和区块链。P2PTV、PDTP等多媒体产品。缺点：
无法保证高质量的服务。实现强大的安全性具有挑战性。性能取决于连接到网络的节点数。无法备份文件或文件夹。可能需要一个特定的接口来读取文件。图表：
不同软件架构模式的对比分析
到目前为止，我们已经了解了不同类型的架构模式。现在，您会为您的软件类型选择哪种架构？您需要做出正确的选择。
让我们看一下下表。
是否有必要聘请软件架构师？
在我看来，“架构师”一定是高级程序员。拥有一个不会编程的架构师和少数不了解架构基础知识的程序员是软件公司灾难的根源。现代应用程序需要快速思考和标准化核心，为应用程序建立坚如磐石的基础。软件架构模式为相关应用程序和公司的长期目标设定了基于解决方案的愿景。
原文地址：https://www.simform.com/blog/software-architecture-patterns/
