2. 信号基础回顾
在把信号驱动系统迁移为服务架构之前，必须先回到最基础的一层：信号机制本身到底是如何工作的。很多迁移失败并不是因为服务拆分不合理，而是因为团队对“信号发出后谁被调用、什么时候被调用、调用顺序如何”缺乏清晰认识。本节将信号、槽、事件循环、观察者模式四个概念串成一条完整的运行链，并给出典型信号驱动系统的组成与运行机制。
一、核心概念：信号、槽与连接
信号（Signal）是对象在特定时刻对外发布的“事件声明”，它本身不包含业务处理逻辑，只负责在状态变化或动作发生时被触发。例如按钮被点击、数据加载完成、连接断开，都可以定义为信号。
槽（Slot）是接收信号并执行具体逻辑的函数或方法。槽可以是普通函数、对象方法、lambda 表达式，甚至另一个信号。信号与槽之间通过连接（Connect）建立关系，形成“发布—订阅”的绑定。
关键点在于：信号不知道谁在监听，槽也不知道自己被谁触发。这种解耦让模块之间可以独立演化，但也带来了调试困难——一旦连接关系混乱，事件会流向意料之外的位置。
# 典型信号连接示意（伪代码）
button.clicked.connect(on_submit) # 槽：提交处理
model.dataChanged.connect(view.refresh) # 槽：刷新视图
timer.timeout.connect(poll_status) # 槽：轮询状态
二、事件循环：信号调度的发动机
信号不会自己“跑”到槽里，真正驱动它们的是事件循环（Event Loop）。事件循环是一个持续运行的调度器，它不断从事件队列中取出事件，分发给对应的信号，再由信号同步或异步调用已连接的槽。
事件循环通常包含四个阶段：
- 等待事件：阻塞或轮询，等待新事件进入队列。
- 取出事件：按优先级或先进先出顺序取出。
- 分发信号：将事件映射为具体信号并触发。
- 执行槽：同步槽立即执行，异步槽投递到线程池或任务队列。
三、观察者模式：信号机制的设计根基
信号槽本质上是观察者模式（Observer Pattern）的一种实现。观察者模式定义了一对多的依赖关系：当主题（Subject）状态改变时，所有观察者（Observer）都会收到通知并自动更新。
在信号驱动系统中，主题就是信号持有者，观察者就是槽的持有者。二者通过连接表维护关系。观察者模式的价值在于：
- 发布者与订阅者解耦，新增订阅者无需修改发布者代码。
- 支持动态连接与断开，运行期可调整行为。
- 天然适合 UI 事件、状态同步、插件扩展等场景。
但它也有代价：连接关系隐式化，调用链难以静态追踪；槽执行异常可能中断整个事件循环；大量细粒度信号会造成性能开销。
四、典型信号驱动系统的组成与运行机制
一个典型的信号驱动系统通常由五部分组成：事件源、事件队列、事件循环、信号分发器、槽执行器。它们之间的数据流与调用关系如下：
从图中可以看到，信号驱动系统是一个闭环反馈结构：槽执行的结果可能再次产生事件，重新进入队列。这种闭环在单机内运行良好，但迁移到服务架构后，闭环会跨越网络边界，必须引入消息中间件、幂等控制和超时重试。
五、常见误区与复盘清单
| 误区 | 表现 | 复盘建议 |
|---|---|---|
| 把信号当业务逻辑 | 在信号定义中写判断和计算 | 信号只声明事件，逻辑放槽中 |
| 槽中执行阻塞操作 | 事件循环卡死，界面无响应 | 耗时操作改为异步槽或独立线程 |
| 连接关系无管理 | 重复连接、忘记断开、内存泄漏 | 建立连接表，统一注册与销毁 |
| 忽略执行顺序 | 槽之间依赖顺序但未声明 | 明确同步/异步，必要时串行化 |
| 异常未隔离 | 一个槽抛异常导致后续槽不执行 | 槽内捕获异常，记录并降级 |
总结来看，信号是事件声明，槽是处理逻辑，事件循环是调度引擎，观察者模式是设计根基。四者共同构成信号驱动系统的运行骨架。只有把这层骨架看清楚，后续把信号映射为消息、把槽映射为消费者服务、把事件循环映射为消息代理时，才能做到有据可依、边界清晰。