架构师必须了解的 5 种最佳软件架构模式
本文最初发布于 Terasol Technologies。
世界变得越来越依赖软件，软件系统已经渗透到了人类生活的方方面面，并带来了很多便利。从移动应用（用于和人联系），到医疗应用和深度学习模型，到金融技术系统，再到智能建筑（利用技术来自动化许多功能）。
为了提供所需的解决方案并获得最佳效果，必须使用恰当的架构来开发这些软件系统。
模式是特定于问题上下文的解决方案。
架构模式是针对特定环境中常见软件架构问题的通用且可重用的解决方案。
软件缺陷对组织业务有很大的影响。所有软件失败的主要原因都是选择了不恰当的软件架构模式，企业经常在没有正式架构的情况下启动应用程序开发。
然而，经常被忽视的一个事实是：缺少架构设计会迫使开发团队选择一个没有指导原则的典型模式。最终的方案将缺乏明确的角色、职责以及相互之间的依赖关系。
让我们看个简单的例子。
网上银行应用不需要像微服务范式那样复杂的设计。对于检索请求，创建一个客户端 - 服务器架构就够了。然而，如果没有这样的规划，应用程序就可能会变得复杂，而且没有办法回头，或者有可能在重构过程中损失大量的投资。
在本文中，我们将看看什么是软件架构模式，并对其中一些模式进行详细介绍。请记住，可以在单个系统中使用许多模式，用最好的设计来优化每一部分代码。
尽管我们称之为计算机科学，但它时常是一门艺术。
让我们来看看到底什么是软件架构模式。
考虑一个涉及营销 App 开发的软件项目。
要创建这个应用，必须首先确定其设计与架构，因为这是核心，应用的其余部分将以此为基础进行创建。例如，服务间将如何通信或支付集成将如何运转？如何用一个算法来推荐供应商的服务？诸如此类，不胜枚举。
几十年前，可以应对这些挑战的模式还很有限。然而，软件开发发展到现在，我们已经拥有了大量的架构模式，可以为不同类型的应用提供特定的好处。
软件架构模式是一般软件工程问题的重复性解决方案。在之前介绍的杂货店应用设想中，我们可以重用已经指定的产品建议算法，并对它们进行修改，以满足应用的需要。
用来实现推荐模块的软件架构只是整个架构模式的一部分。
现在，我们已经知道了什么是软件架构模式，让我们再看看为什么要使用它们。
以下是软件开发公司在创建应用程序或软件时必须应用软件架构设计模式的三大原因：
构建更优的系统
使用架构模式，我们可以创建具有可转移性的模型。这些模型可以重复使用，这有利于形成一个可伸缩、可扩展的最优结构。
简化设计修改
取决于所使用的模式，大多数架构模式能够在开发的早期阶段进行修改，从而形成一个灵活、鲁棒、无错误的核心架构模式。
便于利益相关者沟通
软件架构模式是系统的基本抽象，利益相关者可以基于它进行沟通、协商，从而相互理解并达成共识。
现在，软件架构模式的意义已经明确，让我们来看 5 种流行的软件架构设计模式，以及可能应用在开发的什么地方。
让我们看几种流行的软件架构模式，许多软件公司用它们开发应用和软件。
顾名思义，这种设计中的组件（代码）被划分为子任务层，多个层叠加在一起。这可能是最常见的策略。因为它通常是围绕数据库构建的，所以许多商业应用程序自然都将信息存储在表中。
这几乎是一个自我应验的预言。许多最流行、最好的软件框架，如 Java EE、Drupal 和 Express，在设计时都考虑到了这种结构。因此，用这些框架构建的许多应用程序自然具有了分层结构。
有时候，这被称为“N 层架构”。下面的设计总共包含 4 层。
展现层：这是用户界面层，我们可以在这里查看以及向应用程序输入数据。
业务层：这一层按照服务器请求执行业务逻辑。
应用层：这一层是作为“展现层”和“数据层”之间桥梁。
数据层：这一层使用数据库来管理数据集。
什么时候应该使用分层软件架构模式？
分层架构流行的原因有很多。我们可以从以下场景 / 需求来考虑：
当开发人员较少而又要快速创建一个应用程序时。
以可维护性和关注点分离作为架构基石的应用程序。
必须遵守传统 IT 结构和流程的企业级应用程序。
分层架构模式适用于：
亚马逊式的电商 Web 应用开发。
一般桌面应用程序。
微内核软件架构模式的另一个名称是插件式软件架构模式。通常，软件团队会在开发具有可替换组件的系统时使用。微内核模式由两个基本组件组成：
核心系统处理应用程序最基本、最简单的操作。
插件模块处理其他的功能以及做专门处理。
假如你已经成功开发了一个聊天应用程序。该应用程序的核心功能是，你可以与世界各地的人互发文本，而且不需要连接到互联网。一段时间后，你想在应用程序中添加语音信息功能，并实现了预期的功能。因为微内核模式允许以插件的形式添加功能，所以你才能够将这个功能添加到一个已经投入使用的程序中。
什么时候应该使用微内核架构模式？
应用程序的基本例程和高阶规则之间有明确的边界。
应用程序有一套固定的核心例程和一个必须定期更新的动态规则集。
它非常适合分布式开发团队。
微内核架构模式适用于：
基于产品的应用及调度应用。
企业级应用，因为其所追求的适应性、可扩展性和可移植性。
事件驱动架构是一种很灵活的方法。在这种架构中，软件服务或操作是由事件触发的。
那么，究竟什么是事件？
当用户在采用 EDA 构建的应用程序中执行一个动作时，会发生状态变化并产生一个反应，这个动作被称为事件。
在分层模式中，数据按照预定的顺序从一层传递到下一层。相比之下，事件驱动架构模式使应用程序模块能够在特定事件发生时做出反应。事件驱动模式分为两种类型：调停者拓扑（mediator topology）和代理者拓扑。
什么时候应该使用事件驱动架构模式？
事件驱动模式最适合应用程序中的异步数据流系统。
事件驱动模式可伸缩又可扩展。我们可以在不改变现有系统的情况下增加新的模块。
开发人员可以使用此模式创建需要完美数据流的复杂应用程序或将逐渐增大的应用程序。
事件驱动架构模式适用于：
构建 JavaScript 网站和电子商务网站。
微服务软件架构模式构建相互独立但可以彼此通信的小型程序，以实现整个系统（应用程序）的正常运行。每个微服务都有自己特定的职责，每个团队可以独立地处理自己的微服务。
它们唯一的共同点就是通信。由于微服务相互通信，所以必须确保它们之间传递的消息向后兼容。
当应用程序采用微服务风格创建时，添加新特性和更新当前微服务，都不会影响其他微服务。使用微服务模式创建的模块是松耦合的。因此，它们易于理解、修改和扩展。
什么时候应该使用微服务架构模式？
毫无疑问，微服务最适合那些希望以一种更可持续的方式重写其单体系统的团队。
微服务最适合数据系统规模大且快速扩张的应用程序。
开发团队分散在全球各地。
微服务架构模式适用于：
组件数量不多的网站和边界明确的企业数据中心，比如 Netflix。
创建基于空间的软件架构模式主要是为了解决和克服可扩展性和并发性的难题。对于并发用户数不断变化且不可预测的应用程序，它也是一种很好的设计模式。通过消除中央数据库限制，利用复制到内存中的数据网格获得高可扩展性。
基于空间的架构通过将处理和存储分布在多台服务器上，最大限度地减少高负载情况下的功能崩溃。
什么时候应该使用基于空间的架构模式？
用于处理大量并发数据库访问或写入的应用程序和软件系统。
必须处理可扩展性和并发性难题的应用程序。
基于空间的架构模式适用于：
适合开发电子商务或社交网站，如 YouTube。
其他架构模式，如模型 - 视图 - 控制器模式、黑板模式、代理模式和事件 - 总线设计，在软件开发的不同方面也很有用。
对所有人来说，基本理念是一致的：定义应用程序的基本质量指标，改进产品功能，提高应用程序构建过程的速度和生产力。
希望这篇博文能帮助你了解软件架构模式的基础知识，以及它们最适合哪些应用程序，以便你可以选出最符合自己软件需求的应用程序。
原文链接：
https://terasol.medium.com/5-best-software-architectural-patterns-you-must-know-about-20ba9c54c9cd
Chrome 新协议被指限制广告拦截，Firefox 将采取不同方法
架构的灵活性能给业务足够的可扩展空间进行二次开发来满足业务的需求。业务是一直在高速发展的，如果一套架构不具有可扩展性，那么有可能会在某个阶段成为业务进一步发展的卡点。
7 月 15-16 日 ArchSummit 全球架构师峰会将落地深圳，大会设置了「架构稳定性保障」专题，本专题重点关注架构的稳定性、可扩展性和易用性等能力，点击阅读原文了解更多。
现在购买门票可享受 618 特惠活动，购票立减一折，充值还可享 7 折最低折扣，了解更多活动细节请扫码或咨询：18514549229（微信同电话)