程序员，怎能不知的7种架构模式

时至今日，不少开发者还不是很清楚各种软件架构模式之间的差别，了解的程度有限。架构模式是一个通用的、可重用的解决方案，用于在给定上下文中的软件体系结构中经常出现的问题。架构模式与软件设计模式类似，但具有更广泛的范围。

下面就听纬小创跟大家详细说说吧！

7种架构模式分别是

1. 分层架构
2. 多层架构
3. 管道 – 过滤器架构
4. 客户端 – 服务器架构
5. 模型 – 视图 – 控制器架构
6. 事件驱动架构
7. 微服务架构

第一种：分层架构，最常见，也被称为 n 层架构。大部分软件架构师、设计师和开发者都很熟悉这种架构模式，大部分分层架构主要由四层组成：展现层、业务层、持久层和数据库层。

各个模块可以独自开发和衍化，各自部分之间的交互非常少，支持可移植性、可修改性和复用性。不过分层会导致性能下降，增加系统的前期成本和复杂性。这种模式不适合高性能应用程序，所以将这种方式应用于小型简单的应用程序或 站。预算比较紧张，是个比较理想的选择。

第二种：多层模式，系统的执行结构被组织成一系列逻辑组件分组。每个分组被称为一个层。

第三种：管道-过滤器架构

可用于构造生成和处理数据流的系统。每个处理步骤都封装在一个过滤器组件内。要处理的数据是通过管道传递的。这些管道可以用于缓冲或用于同步。

使用场景：

在这种模式中，有如下四种过滤器。

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

第四种：客户端-过滤器架构

这种架构的优点是能很好地建立一组服务，用户可以请求他们的服务。

但也有不足，请求通常在服务器上的单独线程中处理。由于不同的客户端具有不同的表示，进程间通信会导致额外开销。

第五种：模型-视图-控制器架构（MVC）

将应用程序功能分为以下三种类型的组件：

MVC 用于 站或移动应用程序开发用户界面。优点是可以轻松地拥有同一个模型的多个视图，这些视图可以在运行时连接和断开。

不过也增加了复杂性。可能导致许多不必要的用户操作更新。

第六种：事件驱动架构

和事件驱动对立的架构是基于请求-响应的架构。

事件驱动的两种模型： 1）pub/sub模型，和消息中间件类似； 2）Event Streaming 模型，event的生产者将事件写入日志文件，消费者可以选择性的读取日志文件并做相应的处理。

Reactor模式

Reactor的工作流程如下：

1. 应用在Dispatcher上注册Event Handler，这样Dispatcher就能够知道在什么事件发生的时候调用什么Handler. 每个EventHandler都有关联的底层handle。
2. Dispatcher会把所有的关联的handles都交给事件分离器来进行监听。
3. 当有事件发生时，事件分离器会把事件通知给Dispatcher，后者调用回调处理器进行处理。

第七种：微服务架构

许多使用场景都可以应用微服务架构，特别是那些涉及大量数据管道的场景。

微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构。