系统架构设计（四）：架构风格总结
黑板
概念
黑板体系架构是一种用于求解复杂问题的软件架构风格，尤其适合知识密集型、推理驱动、数据不确定性大的场景。
它模拟了人类专家协同解决问题的方式，通过一个共享的“黑板”协同多个模块（专家）逐步构建解决方案。
组成结构
黑板架构通常包含三个主要部分：
- 黑板（Blackboard）
- 一个全局共享的内存数据结构，存放系统当前的状态、假设、中间结果等。
- 所有模块都可以读取和写入，但通常通过控制组件协调。
- 知识源/专家模块（Knowledge Sources，KS）
- 一组独立的、专注于特定任务的功能模块。
- 被动响应型：监听黑板变化，当发现适合自身处理的状态时激活，执行操作并更新黑板。
- 控制组件（Control Component）
- 负责管理各个知识源的执行顺序，选择最合适的模块在当前状态下执行。
- 可实现调度策略，如优先级驱动、数据依赖驱动等。
工作机制（流程）
- 初始化黑板，写入初始数据；
- 控制组件调度合适的知识源；
- 被调度的知识源处理黑板中的数据并写回结果；
- 黑板变化后再次触发新的知识源；
- 如此循环，直到满足终止条件或达到目标状态。
优缺点
优点
- 模块高度解耦，方便扩展与维护
- 易于处理复杂、开放性问题
- 支持多专家协作解决方案，适合并行处理
- 灵活应对动态变化的问题环境
缺点
- 控制策略复杂，实现难度高
- 系统调试和性能优化不易
- 不适用于结构简单或问题流程确定性强的系统
典型应用场景
- 语音识别系统
- 图像处理与目标识别
- 智能决策支持系统
- 自动推理系统（如专家系统）
管道-过滤器
概念
| 元素 | 描述 |
|---|---|
| 过滤器（Filter） | 自包含的处理单元，接收输入、处理后输出结果，不依赖上下文。 |
| 管道（Pipe） | 连接过滤器的数据传输通道，负责传递数据流。 |
架构特点
优点：
- 高内聚低耦合：每个过滤器职责单一，易于重用和维护。
- 易扩展：可通过添加或替换过滤器轻松扩展功能。
- 支持并行处理：过滤器可以并行运行，提升系统性能。
- 可复用性强：过滤器模块可以在不同系统中重复使用。
缺点：
- 数据格式统一要求高：管道中传递的数据格式必须兼容。
- 处理时延可能大：数据需依次通过多个过滤器，可能带来延迟。
- 状态管理困难：不适合需要复杂状态共享的处理逻辑。
应用场景
- 编译器（词法分析 → 语法分析 → 语义分析 → 代码生成）
- 图像处理（读入 → 灰度化 → 边缘检测 → 渲染）
- 多媒体流处理（如 FFmpeg）
- 日志处理与数据清洗
- 数据管道（ETL：Extract → Transform → Load）
示意图
数据源 → [过滤器1] → [过滤器2] → [过滤器3] → 输出↓ ↓ ↓Pipe1 Pipe2 Pipe3
设计要点
- 过滤器接口标准化：统一输入/输出格式，定义处理协议。
- 解耦设计：过滤器不应感知管道或其他过滤器的存在。
- 错误处理：提供统一的异常传递或中断机制。
- 可组合性：过滤器应支持任意组合使用。
客户端-服务器
概念
客户端-服务器架构 是一种分布式应用模型，系统被划分为两部分：
- 客户端（Client）：发起请求，处理用户交互。
- 服务器（Server）：接收请求，提供服务与资源。
客户端与服务器通过网络通信，通常使用 HTTP、TCP/IP 等协议。
结构图
[客户端1] [客户端2] [客户端N]| | |+---------------+---------------+↓[服务器 / 服务端]
特点
| 特点 | 描述 |
|---|---|
| 分离关注点 | 客户端负责表示和交互，服务器负责数据和逻辑处理。 |
| 集中管理 | 服务器统一管理资源、用户、权限等，便于维护。 |
| 可扩展性 | 客户端可随时接入多个，服务器可扩容或负载均衡。 |
| 可维护性强 | 服务器逻辑更新无需更改客户端。 |
优缺点
优点
- 结构清晰、职责分离。
- 资源集中，便于管理和备份。
- 支持多客户端接入。
- 安全性好，权限统一控制。
缺点
- 单点瓶颈：服务器若出故障，所有客户端都受影响。
- 维护成本高：服务器需高可用、并发处理能力强。
- 网络依赖：客户端对网络连接有一定要求。
应用场景
- Web 应用（浏览器 ⇄ Web 服务器）
- 移动 App（App ⇄ 后端 API）
- 网络游戏（玩家 ⇄ 游戏服务器）
- 数据库系统（客户端 ⇄ 数据库服务器）
- 邮件系统、FTP 等
设计要点
- 接口设计：统一请求格式（如 REST、gRPC）。
- 权限认证：如 OAuth、Token、Session。
- 并发处理：服务器需支持高并发访问（线程池、协程等）。
- 负载均衡与扩展性：使用反向代理、集群。
- 故障恢复：部署容错机制与备份服务器。
发布-订阅
概念
发布-订阅架构（Pub/Sub）是一种消息驱动的通信模式，通信双方通过事件（消息）中介进行交互：
- 发布者（Publisher）：产生消息，不直接指定接收者。
- 订阅者（Subscriber）：注册感兴趣的消息类型。
- 消息代理（Broker）：中间件，负责路由消息给所有符合条件的订阅者。
结构图
[Publisher1] [Publisher2]| |+--------+-----------+↓[消息代理 / Broker]↓+--------+--------+| |
[Subscriber1] [Subscriber2]
特点
| 特点 | 描述 |
|---|---|
| 解耦合 | 发布者和订阅者互不感知，只依赖消息代理。 |
| 异步通信 | 发布后立即返回，不等待响应。 |
| 多对多通信 | 一条消息可被多个订阅者接收。 |
| 事件驱动 | 系统围绕事件（消息）流动进行运作。 |
优缺点
优点
- 高解耦：系统模块间零耦合，便于扩展和替换。
- 可扩展性强：容易水平扩展发布者/订阅者。
- 灵活性高：支持动态订阅、动态扩展功能。
缺点
- 调试困难：消息异步、分布式，难定位问题。
- 消息可靠性需保障：需要处理丢失、重复、顺序等问题。
- 依赖中间件：系统强依赖消息代理的稳定性和吞吐能力。
应用场景
- 日志收集系统（如 ELK、Fluentd）
- 事件驱动系统（如用户注册事件 → 发邮件、统计日志）
- 微服务通信（如 Kafka、RabbitMQ、Redis Pub/Sub）
- IoT 设备数据推送
- 聊天系统 / 通知系统
关键设计要点
- 主题（Topic）/频道（Channel）机制：消息分类基础。
- 消息传递语义：
- 至少一次（At least once）
- 至多一次（At most once）
- 精确一次（Exactly once）
- 持久化与重放：是否保存历史消息、支持离线订阅者。
- 顺序保证：是否要求消息有序。
- 容错与高可用性：中间件的高可用部署（集群、主从、分片）。
常见实现
| 中间件 | 特点 |
|---|---|
| Kafka | 高吞吐、可持久化、支持消息重放和分区顺序 |
| RabbitMQ | 高灵活性、路由机制丰富、支持事务 |
| Redis Pub/Sub | 轻量级，适用于内网通知，不支持持久化 |
| MQTT | 面向 IoT，轻量协议，支持断线续传 |
| NATS | 高性能、云原生友好 |
总结
| 架构风格 | 特点 | 适用场景 |
|---|---|---|
| 黑板架构 | 多模块协作、共享数据驱动、控制策略灵活 | 不确定性问题求解 |
| 管道-过滤器 | 数据流动线性，模块串联 | 数据处理流水线 |
| 客户端-服务器 | 明确的请求/响应模式 | 网络服务、Web系统 |
| 发布-订阅 | 解耦事件通知机制 | 实时系统、消息中间件 |