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

黑板

概念

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

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

组成结构

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

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

工作机制（流程）

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

优缺点

优点

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

缺点

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

典型应用场景

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

管道-过滤器

概念

元素	描述
过滤器（Filter）	自包含的处理单元，接收输入、处理后输出结果，不依赖上下文。
管道（Pipe）	连接过滤器的数据传输通道，负责传递数据流。

架构特点

优点：

高内聚低耦合：每个过滤器职责单一，易于重用和维护。
易扩展：可通过添加或替换过滤器轻松扩展功能。
支持并行处理：过滤器可以并行运行，提升系统性能。
可复用性强：过滤器模块可以在不同系统中重复使用。

缺点：

数据格式统一要求高：管道中传递的数据格式必须兼容。
处理时延可能大：数据需依次通过多个过滤器，可能带来延迟。
状态管理困难：不适合需要复杂状态共享的处理逻辑。

应用场景

编译器（词法分析 → 语法分析 → 语义分析 → 代码生成）
图像处理（读入 → 灰度化 → 边缘检测 → 渲染）
多媒体流处理（如 FFmpeg）
日志处理与数据清洗
数据管道（ETL：Extract → Transform → Load）

示意图

bash 复制代码

数据源 → [过滤器1] → [过滤器2] → [过滤器3] → 输出
           ↓           ↓           ↓
         Pipe1       Pipe2       Pipe3

设计要点

过滤器接口标准化：统一输入/输出格式，定义处理协议。
解耦设计：过滤器不应感知管道或其他过滤器的存在。
错误处理：提供统一的异常传递或中断机制。
可组合性：过滤器应支持任意组合使用。

客户端-服务器

概念

客户端-服务器架构 是一种分布式应用模型，系统被划分为两部分：

客户端（Client）：发起请求，处理用户交互。
服务器（Server）：接收请求，提供服务与资源。

客户端与服务器通过网络通信，通常使用 HTTP、TCP/IP 等协议。

结构图

plaintext 复制代码

[客户端1]       [客户端2]       [客户端N]
     |               |               |
     +---------------+---------------+
                     ↓
              [服务器 / 服务端]

特点

特点	描述
分离关注点	客户端负责表示和交互，服务器负责数据和逻辑处理。
集中管理	服务器统一管理资源、用户、权限等，便于维护。
可扩展性	客户端可随时接入多个，服务器可扩容或负载均衡。
可维护性强	服务器逻辑更新无需更改客户端。

优缺点

优点

结构清晰、职责分离。
资源集中，便于管理和备份。
支持多客户端接入。
安全性好，权限统一控制。

缺点

单点瓶颈：服务器若出故障，所有客户端都受影响。
维护成本高：服务器需高可用、并发处理能力强。
网络依赖：客户端对网络连接有一定要求。

应用场景

Web 应用（浏览器 ⇄ Web 服务器）
移动 App（App ⇄ 后端 API）
网络游戏（玩家 ⇄ 游戏服务器）
数据库系统（客户端 ⇄ 数据库服务器）
邮件系统、FTP 等

设计要点

接口设计：统一请求格式（如 REST、gRPC）。
权限认证：如 OAuth、Token、Session。
并发处理：服务器需支持高并发访问（线程池、协程等）。
负载均衡与扩展性：使用反向代理、集群。
故障恢复：部署容错机制与备份服务器。

发布-订阅

概念

发布-订阅架构 （Pub/Sub ）是一种消息驱动的通信模式 ，通信双方通过事件（消息）中介进行交互：

发布者（Publisher）：产生消息，不直接指定接收者。
订阅者（Subscriber）：注册感兴趣的消息类型。
消息代理（Broker）：中间件，负责路由消息给所有符合条件的订阅者。

结构图

bash 复制代码

[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系统
发布-订阅	解耦事件通知机制	实时系统、消息中间件