本文主要介绍了几种主要的软件架构模式。

概述

架构模式是对给定上下文的软件架构中常见问题的一种通用的可复用的解决方案。一种模式就是特定上下文的问题的一种解决方案。然而，很多开发者至今还对各种软件架构模式之间的差别搞不清，甚至对其所知甚少。大体上，主要有下面这几种架构模式：

• 分层架构
• 管道 – 过滤器架构
• 客户端 – 服务器架构
• 模型 – 视图 – 控制器架构
• 事件驱动架构
• 微服务架构

分层架构模式

最常见的架构模式就是分层架构或者称为 n 层架构。大部分软件架构师、设计师和开发者都对这个架构模式非常熟悉。尽管对于层的数量和类型没有具体限制，但大部分分层架构主要由四层组成：展现层、业务层、持久层和数据库层，如下图所示。

封闭层和请求访问

弱点

分层会导致性能下降。这种模式不适合高性能应用程序，因为经过架构中的多层来实现一个业务请求的效率是不高的。分层还会增加系统的前期成本和复杂性。

用途

我们应该将这种方式应用于小型简单的应用程序或网站。对于预算和时间非常紧张的场景，这是一个不错的选择。

多层模式

方案

管道过滤器模式

上下文

许多系统需要转换从输入到输出的离散数据流。许多类型转换在实践中重复出现，因此将其创建成独立的可复用的部分，这是比较理想的。

问题

这些系统需要被分割成可复用的松耦合的组件，组件之间拥有简单通用的交互机制。这样它们就可以灵活地相互结合。这些通用松耦合的组件就很容易复用。那些独立的组件可以并行执行。

方案

这种架构中的管道构成了过滤器之间的通信通道。第一个概念是，由于性能原因，每个管道都是非定向的和点对点的，接受来自一个源的输入并经常直接输出到另外一个源。在这种模式中，有如下四种过滤器。

• producer（source）：一个过程的起点。
• transformer (map)：对一些或所有数据进行转换。
• tester (reduce)：测试一个或多个条件。
• consumer (sink)：终点。

弱点

不太适合交互性的系统，因为它们的转换特性。过多的解析和反解析会导致性能损失，也会增加编写过滤器本身的复杂性。

用途

管道 – 过滤器架构用于各种应用程序，特别是简化单项处理的任务，例如 EDI、ETL 工具。
编译器：连续的过滤器执行词法分析、语法分析、语义分析和代码生成。

客户端 – 服务器架构

上下文

用户界面通常是一个交互性应用程序的最频繁被修改的部分。用户通常希望从不同的视角查看数据，例如柱状图或者饼图。这些表示形式都应该反映数据当前的状态。

问题

用户界面功能如何独立于应用程序功能，同时还还对用户输入或底层应用程序数据的更改做出响应br> 当底层应用程序数据更改时，如何创建、维护和协调用户界面的多个视图/p>

方案

模型 – 视图 – 控制器（model-view-controller，即 MVC）模式将应用程序功能分为以下三种类型的组件：

• 模型，包含应用程序的数据。
• 视图，显示部分底层数据并与用户交互。
• 控制器，在模型和视图之间进行中介并管理状态更改的通知。

弱点

对于简单的用户界面，其复杂性并不值得这么做。
模型、视图和控制器抽象可能不适用于某些用户界面工具包。

用途

MVC 是网站或移动应用程序开发用户界面常用的一种架构模式。

事件驱动架构

上下文

需要提供计算和信息资源来处理传入的应用程序生成的独立异步事件，这种方式可以随着需求的增加而扩展。

问题

构建分布式系统，这个系统可以服务异步到达的事件相关信息，并且能从简单小型扩展到复杂大型。

方案

将应用程序构建成服务套件。每个服务都是独立部署和可扩展的，拥有自己的 API 边界。不同的服务可以用不同的编程语言编写，管理它们自己的数据库，由不同的团队开发。

弱点

系统设计必须能容忍服务失败，需要更多的系统监控。服务编排和事件协作开销比较大。
当然，我们还需要更多钱。

用途

许多使用场景都可以应用微服务架构，特别是那些涉及大量数据管道的场景。例如，一个微服务系统对关于一个公司的零售店销售的报表系统会比较理想。数据展现过程的每一步都会被一个微服务处理：数据收集、清理、规范化、浓缩、聚合、报告等。

参考资料

• 程序员必知的几种软件架构模式

来源：阿兵-AI医疗