系统架构设计（四）：架构风格总结

黑板

概念

黑板体系架构是一种用于求解复杂问题的软件架构风格，尤其适合知识密集型、推理驱动、数据不确定性大的场景。

它模拟了人类专家协同解决问题的方式，通过一个共享的“黑板”协同多个模块（专家）逐步构建解决方案。

组成结构

黑板架构通常包含三个主要部分：

1. 黑板（Blackboard）
   • 一个全局共享的内存数据结构，存放系统当前的状态、假设、中间结果等。
   • 所有模块都可以读取和写入，但通常通过控制组件协调。
2. 知识源/专家模块（Knowledge Sources，KS）
   • 一组独立的、专注于特定任务的功能模块。
   • 被动响应型：监听黑板变化，当发现适合自身处理的状态时激活，执行操作并更新黑板。
3. 控制组件（Control Component）
   • 负责管理各个知识源的执行顺序，选择最合适的模块在当前状态下执行。
   • 可实现调度策略，如优先级驱动、数据依赖驱动等。

工作机制（流程）

1. 初始化黑板，写入初始数据；
2. 控制组件调度合适的知识源；
3. 被调度的知识源处理黑板中的数据并写回结果；
4. 黑板变化后再次触发新的知识源；
5. 如此循环，直到满足终止条件或达到目标状态。

优缺点

优点

• 模块高度解耦，方便扩展与维护
• 易于处理复杂、开放性问题
• 支持多专家协作解决方案，适合并行处理
• 灵活应对动态变化的问题环境

缺点

• 控制策略复杂，实现难度高
• 系统调试和性能优化不易
• 不适用于结构简单或问题流程确定性强的系统

典型应用场景

• 语音识别系统
• 图像处理与目标识别
• 智能决策支持系统
• 自动推理系统（如专家系统）

管道-过滤器

概念

元素	描述
过滤器（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系统
发布-订阅	解耦事件通知机制	实时系统、消息中间件