6.3 架构模式 (Architectural patterns)
架构模式概述 (Introduction to Architectural Patterns)
架构模式 (Architectural patterns)（也常被称为架构风格 / Architectural styles）是对在不同软件系统和环境中经过尝试与测试的良好实践（good practice）的风格化、抽象化描述。 一个架构模式不仅描述了系统的组织结构，还会详细说明在什么情况下适合或不适合使用该模式，并指出其优缺点（strengths and weaknesses）。
第 6.3 节详细介绍了五种最常用的架构模式：
1. 模型-视图-控制器模式 (Model-View-Controller, MVC)
- 结构与形式 (Description/Structure)： 系统被构造为三个相互交互的逻辑组件，将系统数据与表现形式（presentation）及用户交互（interaction）分离。
- 模型 (Model)：管理系统数据及相关的数据操作，封装了应用程序的状态（application state）。
- 视图 (View)：定义并管理数据如何呈现（renders model）给用户。
- 控制器 (Controller)：管理用户交互（如按键、鼠标点击），并将这些交互事件（user events）映射并传递给视图和模型。
- 适用场景 (When used)： 当存在多种查看和交互数据的方式时；或者当未来对数据展示和交互的需求还不明确时使用。
- 优点 (Advantages)： 允许数据与其表现形式独立变更。支持用不同的方式呈现相同的数据，并且在一个表现形式中做出的更改会同步反映在所有的表现形式中。
- 缺点 (Disadvantages)： 当数据模型和业务交互非常简单时，使用 MVC 可能会产生冗余的代码，反而增加代码的复杂性（code complexity）。
- 示例 (Example)： 许多语言框架支持的基于 Web 的应用系统（Web-based application system）常使用该模式进行交互管理。
2. 分层架构 (Layered Architecture)
- 结构与形式 (Description/Structure)： 将系统组织成多个层 (layers)，每个层关联特定的功能。一个层只为其直接位于其上方的层提供服务（services）。最底层的层通常代表整个系统可能用到的核心服务（core services），如操作系统或数据库支持。
- 适用场景 (When used)： 需要在现有系统之上构建新设施时；开发工作由多个团队分散进行，且每个团队负责一层功能时；或者系统有多级安全需求（multilevel security）时。
- 优点 (Advantages)： 支持系统的增量开发。只要维持好接口不变，整个层可以被独立替换。它将机器依赖性（machine dependencies）局部化，使系统更容易移植。可以在每一层提供冗余的设施（如认证 authentication）来提高系统的可靠性。
- 缺点 (Disadvantages)： 在实践中，很难在层与层之间提供绝对干净的分离，高层往往需要越过其直接下层，直接与更低层交互。此外，由于服务请求在每一层都需要被解释和处理，多层传递可能会导致性能问题（performance problems）。
- 示例 (Example)： 用于支持学校全学科学习的数字学习系统（如 iLearn system），以及精神健康护理系统（Mentcare system）。
3. 仓库架构 / 存储库架构 (Repository Architecture)
- 结构与形式 (Description/Structure)： 系统中的所有数据都在一个中央仓库（central repository）或共享数据库（shared database）中管理，所有系统组件都可以访问它。组件之间不直接交互，只能通过仓库进行通信。
- 适用场景 (When used)： 当系统产生并需要长期存储大量信息（large volumes of information）时；或者适用于数据驱动系统（data-driven systems），即仓库中包含新数据时会触发组件执行特定动作。
- 优点 (Advantages)： 组件之间保持独立（independent），它们不需要知道其他组件的存在。一个组件所做的数据更改会立刻对所有组件可见。因为所有数据都在一个地方，所以数据的管理（如一致性备份 backups）非常方便统一。
- 缺点 (Disadvantages)： 中央仓库是一个单点故障 (single point of failure)，仓库出现问题会影响整个系统。通过仓库组织所有通信可能会导致效率低下。将仓库分布到多台计算机上通常很困难。
- 示例 (Example)： 集成开发环境 (Integrated Development Environment, IDE)，其中的各种软件工具（如 Java 编辑器、UML 编辑器、代码生成器等）通过一个共享的系统设计信息项目仓库进行协作。还包括指挥控制系统、管理信息系统、CAD系统等。
4. 客户端-服务器架构 (Client-Server Architecture)
- 结构与形式 (Description/Structure)： 展示了分布式系统的运行时组织形式。系统被组织为一组提供服务的服务器 (servers)，以及通过网络访问和使用这些服务的客户端 (clients)。
- 适用场景 (When used)： 当共享数据库中的数据需要从多个不同的位置被访问时；当系统的负载（load）多变且不确定时。
- 优点 (Advantages)： 最大的优势是它是一个分布式架构 (distributed architecture)，能有效利用网络化系统中的多个分布式处理器。添加新服务器或透明地升级服务器非常容易，且不会影响系统的其他部分。
- 缺点 (Disadvantages)： 每一个服务都是一个单点故障。系统容易受到拒绝服务攻击 (denial-of-service attacks) 和服务器故障的影响。系统性能依赖于网络，难以预测。如果服务器由不同的组织所有，可能会出现管理问题。
- 示例 (Example)： 一个在互联网上提供视频、照片和目录服务的电影库系统 (film library)。客户端可以是集成的 Web 浏览器界面，它通过网络访问后端的各种服务器。
5. 管道和过滤器架构 (Pipe and Filter Architecture)
- 结构与形式 (Description/Structure)： 系统的数据处理被组织成多个离散的组件（即过滤器 / filter），每个组件执行一种数据转换。数据像在管道 (pipe) 中一样从一个组件流向另一个组件。这些转换可以串行（sequentially）执行，也可以并行（in parallel）执行。
- 适用场景 (When used)： 常用于数据处理应用（data-processing applications），包括批处理或基于事务的系统，在这些系统中，输入数据经过分阶段处理后生成相关的输出。
- 优点 (Advantages)： 易于理解，并支持转换组件的复用（transformation reuse）。这种工作流风格与许多业务流程的结构相匹配。通过添加新的转换可以很直接地使系统演进（evolution）。可以被实现为顺序系统或并发系统。
- 缺点 (Disadvantages)： 通信的转换组件之间必须事先商定数据传输的格式（data transfer format）。每个过滤器都必须解析（parse）其输入，并反解析（unparse）其输出为商定格式，这增加了系统开销 (system overhead)。对于使用不兼容数据结构的架构组件，无法进行复用。对于基于事件控制的交互式系统（interactive systems），很难以这种顺序流的方式来实现。
- 示例 (Example)：
- Unix / Linux 系统："管道和过滤器"的名字正是来源于早期的 Unix 系统。在 Unix shell 中，可以通过“管道（pipes）”将进程链接起来，把一个进程的文本流（text stream）传递给下一个进程处理。
- 发票批处理系统 (batch sequential model)：读取已开具的发票、识别付款、为已付清的发票开具收据，并向未付款客户发出催款单。