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