架构师之路 — 软件架构 — 软件架构设计模式（Software Architecture Patterns）

目录

分层架构

它是单体应用最常见的架构。该模式的基本思想是将应用程序的逻辑划分为若干层，每层都封装了特定的角色。分层模式将软件分割成各个单元（称为 “层”）。每一层都是一组模块，提供了一组高内聚的服务。

尽管对于层的数量和类型没有具体限制，但大部分分层架构主要由 4 层组成：

1. 展现层
2. 业务层
3. 持久层
4. 数据库层

层将一组软件作为一个完整的分区，每个分区暴露一个公开接口。

1. 每层都有特定的角色和职责。例如，展现层负责处理所有的用户界面。分层架构的这种关注点分离，让构建高效的角色和职责非常简单。
2. 分层架构模式是一个技术性的分区架构，而非一个领域性的分区架构。它们是由组件组成的，而不是领域。
3. 分层架构中的每一层都被标记为封闭或者开放。封闭层意味着请求从一层移到另一层，它必须通过它正下面的这一层才能达到下面这一层的再下一层。请求不能跳过任何层。

不足：

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

分层架构通常应用于小型简单的应用程序或网站。对于预算和时间非常紧张的场景，这是一个不错的选择。

管道/过滤器（Pipe/Filter）架构

许多系统需要转换从 Input 到 Output 的离散数据流。

一方面，为了可复用各种 “转换” 的逻辑，可以将它们封装为一个个 Filters。另一方面，为了可以松耦合的组织不同的 Filters 之间的过滤顺序，可以将它们交由一个个 Pipeline 来处理，组件之间拥有简单通用的交互机制。

这样它们就可以灵活地相互结合，这些通用松耦合的组件就很容易复用，独立的组件也可以并行执行。这种架构中的 Pipe 就构成了 Filters 之间的通信通道。

通常的，在该架构中，有如下 4 种过滤器。

1. Producer（source）：一个过程的起点。
2. Transformer (map)：对一些或所有数据进行转换。
3. Tester (reduce)：测试一个或多个条件。
4. Consumer (sink)：终点。

不足：

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

管道/过滤器架构适用于简化的单项处理任务，例如 EDI、ETL、编译器等工具。以编译器为例：连续的过滤器执行词法分析、语法分析、语义分析和代码生成。

事件驱动架构

这种模式背后的思想是将应用逻辑解耦为单一用途的事件处理组件，以异步方式接收和处理事件。这是一种广受欢迎的分布式异步架构模型，它以高可扩展性和适应性而闻名。

微内核架构（插件架构）

这种设计模式包含两大部分：核心系统和插件模块（或扩展）。

Web 浏览器就是一个很好的例子，它相当于核心系统，可以让你无限地安装扩展（或者插件）。

微服务架构

微服务架构由单独部署的服务组成，每个服务最好都有一个单一的责任。这些服务彼此之间是相互独立的，当其中一个服务出现故障时，其他服务不会因此中断。

基于空间的架构（云架构模式）

基于空间的模式背后的主要思想是分布式共享内存，以缓解经常发生在数据库层面的问题。它的假设是，通过使用内存数据处理大部分操作，这样我们就可以避免在数据库中进行额外的操作，从而避免未来可能由此产生的任何问题，例如：如果你的用户活动数据实体发生了变化，你不需要改变一堆代码来持久化和从数据库中检索这些数据。

基本的方法是将应用程序分离成处理单元（可以根据需求自动扩大和缩小），数据将在这些单元之间进行复制和处理，无需持久化到中央数据库（虽然当系统发生故障时，也会有本地存储）。

分布式架构