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