架构模式是通用的、可重用的解决方案，用于解决给定上下文中软件架构中的常见问题。模式是上下文中问题的解决方案。今天，许多程序员仍然对架构模式之间的差异感到困惑，甚至没有意识到它们。让我向你解释......！分层架构管道和过滤器客户端服务器模型视图控制器事件驱动架构微服务架构分层架构最常见的架构模式是分层架构或称为n层架构。大多数软件架构师、设计师、开发人员都是众所周知的。尽管对于必须存在的层的数量和类型没有特别的限制，但大多数分层架构由四个层组成：表示层、业务层、持久层和数据库层，如下所示。>n层体系结构上下文的一个流行示例所有复杂的系统都需要系统的各个部分独立开发和演化。出于这个原因，系统的开发人员需要一个清晰且记录良好的关注点分离，以便系统的模块可以独立开发和维护。该问题需要对软件进行分段，使得模块可以独立开发和开发，各部分之间的交互很少，能够实现可移植性、可修改性和重用性。解决方案为了实现关注点分离，分层模式将软件划分为称为层的单元。每一层都是一组模块，提供一组内聚的服务。使用必须是单向的。层将一组软件完全划分，每个划分通过一个公共接口暴露出来。第一个概念是每一层都有特定的角色和职责。例如，表示层将负责处理所有UI。因为分层架构中的关注点分离使得建立有效的角色和职责变得容易。在第二个概念上，分层架构模式是技术分区而不是领域分区的架构。它们是组件组，而不是按域。最后一个概念是分层架构中的每一层都被标记为封闭或开放。封闭层意味着当请求从一层移动到另一层时，它必须通过它下面的层才能到达它下面的下一层。该请求不能跳过任何层。>封闭层和请求访问弱层会导致性能下降。该模式无法将自身应用于高性能应用程序，因为遍历架构的多个层以满足业务请求的效率不高。层的添加也增加了系统的前期成本和复杂性。用法对于小型、简单的应用程序或网站，我们应该使用这种风格。对于那些预算有限且时间紧迫的人来说，这是一个不错的选择。多层模式上下文在分布式部署中，通常需要将系统的基础设施分布到不同的子集中。问题我们如何将系统划分为多个计算独立的执行结构：通过某种通信介质连接的软件和硬件组？解决方案>多层示例—消费者网站J2EE许多系统的执行结构被组织成一个逻辑组件组。每个分组称为一个层。缺点大量的前期成本和复杂性。用于分布式系统。管道和过滤器软件架构中反复出现的模式之一是管道过滤器模式。>管道过滤器样式上下文需要许多系统将离散数据项流从输入转换为输出。事实上，许多类型的转换会重复发生，因此需要将它们创建为独立的、可重用的部分。问题此类系统需要分成可重用、松散耦合的组件，并具有简单、通用的交互机制。这样，它们可以灵活地相互组合。通用和松散耦合的组件易于重用。独立组件可以并行执行。此架构中的解决方案管道形成过滤器之间的通信通道。第一个概念是出于性能原因，每个管道都是无向的和对等的，从一个源接受输入并始终将输出定向到另一个。这种风格的过滤器有四种类型，如下所示。生产者（来源）：流程的起点。Transformer(Map)：对部分或全部数据进行转换。tester(reduce)：测试一个或多个条件。消费者（接收者）：端点。弱点由于交互式系统的切换特性，这不是一个好的选择。过多的解析和取消解析会导致性能下降并增加编写过滤器本身的复杂性。Usage流水线过滤器架构用于各种应用程序，特别是促进简单单向处理的任务，例如EDI、ETL工具。编译器：连续的过滤器执行词法分析、语法分析、语义分析和代码生成。客户端-服务器上下文有许多分布式客户端想要访问的共享资源和服务，我们想要控制它们以控制访问或服务质量。问题通过管理一组共享资源和服务，我们可以通过排除公共服务并不得不在单个位置或少数位置修改它们来提高可修改性和重用性。我们希望通过集中控制这些资源和服务，同时将资源本身分布在多个物理服务器上来提高可扩展性和可用性。解决方案在客户端-服务器样式中，组件和连接器具有特定的行为。称为“客户端”的组件向称为“服务器”的组件发送请求并等待回复。服务器组件接收来自客户端的请求并向它们发送回复。弱服务器可能是性能瓶颈和单点故障。一旦构建了系统，关于在何处定位功能（在客户端或服务器中）的决定通常很复杂且更改成本高昂。用法我们可以使用客户端-服务器样式来对系统的一部分进行建模，该系统具有许多组件（客户端），这些组件将请求（客户端）发送到另一个提供服务的组件（服务器）：在线应用程序，例如电子邮件、文档共享和银行业务。模型视图控制器MVC上下文用户界面通常是交互式应用程序中修改最频繁的部分。用户通常希望从不同的角度查看数据，例如条形图或饼图。这些表示中的每一个都应该反映数据的当前状态。问题如何将用户界面功能与应用程序功能分开，以及如何响应用户输入或底层应用程序数据的变化？随着底层应用程序数据的变化，您如何创建、维护和协调用户界面的多个视图？解决方案模型视图控制器(MVC)模式将应用程序功能分为以下三个组件。包含应用程序数据的模型。视图，显示底层数据的某些部分并与用户交互。控制器，它在模型和视图之间进行调解，并管理状态更改的通知。弱点对于简单的用户界面，复杂性可能不值得。模型、视图和控制器的抽象可能不适合某些用户界面工具包。用法MVC是一种架构模式，在开发用户界面时常用于Web移动应用程序。事件驱动的架构上下文需要提供计算和信息资源，以处理由独立异步应用程序生成的传入事件，其方式可以随着需求的增加而扩展。问题构建分布式系统，可以服务于与事件相关的异步到达消息，并且可以从小而简单扩展到大而复杂。该解决方案为事件处理部署了一个单独的事件进程/处理程序。到达事件排队。调度程序从队列中拉取事件，并根据调度策略将它们分派给适当的事件处理程序。性能低下和错误恢复可能是一个问题。用法使用此方法的电子商务应用程序将按如下方式工作：订单服务创建处于挂起状态的订单并发布OrderCreated事件。客户服务收到事件并尝试保留订单信用。然后它会发布“CreditReserved”事件或“CreditLimitExceeded”事件。订单服务接收来自客户服务的事件并将订单状态更改为已批准或已取消微服务架构上下文部署一个基于服务器的企业应用程序，支持多种浏览器和本机移动客户端。该应用程序通过执行业务逻辑、访问数据库、与其他系统交换消息以及返回响应来处理客户端请求。该应用程序可能会公开第三方API。问题整体式应用程序可能变得过于庞大和复杂而无法有效支持，并且部署不允许分布式资源的最佳利用，例如在云环境中。该解决方案将应用程序构建为一套服务。每个服务都可以独立部署和扩展，并且有自己的API边界。不同的服务可以用不同的编程语言编写，管理自己的数据库，由不同的团队开发。弱点系统的设计必须能够承受需要更多系统监控的服务故障。服务编排和事件协作开销。我们还需要更多的内存。用法许多用例适用于微服务架构，尤其是那些涉及大型数据管道的用例。例如，基于微服务的系统非常适合公司零售店销售的报告系统。数据准备过程的每一步都将由微服务处理：数据收集、清洗、规范化、丰富、聚合、报告等。
