1. 课程导论：事件溯源基本概念、状态恢复在发布拓扑中的重要性、课程目标与学习路径
1.1 事件溯源：以事件为第一公民的持久化范式
传统持久化模式（如 CRUD）只保存实体的当前快照，丢失了所有中间状态变更的历史。事件溯源（Event Sourcing, ES）则颠覆了这一假设：每次状态变更都被记录为一个不可变的事件（Event），当前状态由事件流的重放（Replay）推导得出。
| 对比维度 | CRUD 模式 | 事件溯源模式 |
|---|---|---|
| 存储内容 | 当前状态快照 | 事件流（Event Stream） |
| 历史可追溯性 | 无（仅最新状态） | 完整审计日志 |
| 状态推导方式 | 直接读取 | 事件重放（Replay） |
| 并发控制 | 乐观锁/悲观锁 | 事件版本 + 聚合根边界 |
| 数据模型灵活性 | 低（Schema 耦合） | 高（可追加新事件类型） |
核心公式： 当前状态 = fold(初始状态, 事件流) = 事件流上所有事件的累积投影。
1.2 状态恢复：发布拓扑中的关键挑战
在微服务发布拓扑中，服务实例会经历滚动升级、蓝绿部署、金丝雀发布等操作。每次发布都意味着旧实例销毁、新实例启动。对于事件溯源架构而言，新实例必须从事件存储中重建内存状态，这个过程称为状态恢复（State Recovery）。
状态恢复的典型场景包括：
- 冷启动：新节点首次加入集群，从零开始重放所有事件。
- 故障恢复：节点崩溃后重新加入，需从最近快照 + 增量事件恢复。
- 版本迁移：事件 Schema 变更后，需兼容旧事件并升级为新格式。
- 拓扑调整：分区重平衡或副本迁移时，目标节点需重建聚合状态。
常见误区： 认为事件溯源等同于“无限存储事件”。实际生产环境中必须引入快照（Snapshot）机制来截断事件流，否则重放性能会随事件量线性恶化。
1.3 为什么发布拓扑让状态恢复变得复杂
在单体时代，状态恢复只需考虑单进程重启。但在微服务发布拓扑中，多个因素叠加了复杂度：
- 并发发布：多个服务同时发布，状态恢复可能触发级联依赖。
- 版本兼容：新旧实例共存期间，事件格式可能不兼容。
- 分区重平衡：发布过程中可能触发 Kafka/RabbitMQ 分区再分配，导致事件流归属变化。
- 幂等性保障：事件重放可能重复投递，需要去重机制。
| 发布策略 | 状态恢复挑战 | 典型解决方案 |
|---|---|---|
| 滚动升级 | 新旧实例共存，事件流可能被两个版本同时消费 | 事件版本号 + 双写兼容 |
| 蓝绿部署 | 切换瞬间需要快速预热新集群状态 | 预加载快照 + 预热缓存 |
| 金丝雀发布 | 小比例实例恢复状态后需与旧版本保持一致性 | 影子流量 + 状态校验 |
1.4 课程目标与学习路径
本课程旨在帮助后端架构师掌握事件溯源架构中状态恢复的设计原则、实现模式与生产级落地方法。完成本课程后，你将能够：
- 理解事件溯源的核心概念与快照机制。
- 设计支持零停机发布的拓扑状态恢复方案。
- 处理事件版本迁移、并发恢复、幂等性等棘手问题。
- 在真实项目中落地事件溯源 + 发布拓扑的最佳实践。
学习路径分为四个阶段：
- 基础篇（第1-5章）：事件溯源原理、快照策略、事件存储选型。
- 发布拓扑篇（第6-15章）：滚动升级、蓝绿部署、金丝雀发布中的状态恢复设计。
- 进阶篇（第16-25章）：事件版本迁移、并发控制、分布式恢复、监控与告警。
- 实战篇（第26-30章）：完整案例：电商订单系统的发布拓扑状态恢复实现。
学习建议： 每章都配有可运行的代码示例和拓扑图。建议在本地搭建一个简单的 Event Store + Kafka 环境，边学边练效果最佳。