事件溯源是只保存不可变事件而非当前状态，通过重放事件计算状态；微服务中用于解决分布式事务、审计、一致性与历史回溯问题。
什么是事件溯源，为什么微服务中需要它
事件溯源（Event Sourcing）不是记录“当前状态”，而是只保存系统中发生的所有事实——也就是一个个不可变的事件，比如 UserCreated、OrderShipped、PaymentFailed。状态是通过重放这些事件实时计算出来的。在微服务架构中，它天然适合解决分布式事务、审计追踪、数据一致性与历史回溯问题，尤其当多个服务需共享同一业务实体（如订单）的完整生命周期时。
核心结构设计：事件、聚合根与事件存储
Go 中实现事件溯源，关键在于三个组件的清晰分离：
- 事件（Event）：定义为带时间戳、唯一ID、版本号的结构体，用 JSON 或 Protobuf 序列化。例如：type UserRegistered struct { UserID string; Email string; Timestamp time.Time; Version int }
- 聚合根（Aggregate Root）：封装业务规则和状态变更逻辑，只通过 Apply() 方法响应事件并更新内部状态；所有变更必须生成对应事件，禁止直接修改字段。
-
事件存储（Event Store）：推荐使用专用数据库（如 PostgreSQL 表
events含aggregate_id、event_type、payload、version、created_at），或轻量级方案如 SQLite + WAL 模式。避免用通用 ORM 直接存事件，要确保写入原子性与按序读取能力。
典型工作流：从命令到事件再到状态重建
一个用户注册流程可体现完整链路：
- 接收 HTTP 请求，解析为 CreateUserCommand
- 加载已有用户聚合（通过
LoadFromHistory(aggregateID)，从事件存储按 version 升序读取并逐个 Apply） - 调用聚合的 Register(email) 方法 —— 它校验业务规则（如邮箱唯一），若通过则调用
a.Apply(&UserRegistered{...})生成事件并暂存 - 开启事务：将新事件写入事件存储，并更新聚合当前版本号；失败则回滚，不改变状态
- 成功后，可异步发布该事件到消息队列（如 Kafka/NATS），供其他服务消费（如发邮件、更新搜索索引）
实用技巧与避坑提醒
在 Go 实现中容易忽略但影响深远的细节：
- 事件必须向后兼容：新增字段设默认值，避免用
json:"required"；推荐用encoding/gob或 Protobuf 替代纯 JSON，更易控制序列化行为 - 聚合重建性能关键：对高频聚合（如订单），可引入快照（Snapshot）机制——定期保存当前状态+最新 version，在加载时先取快照再重放后续事件
- 不要在事件处理器里做远程调用：消费事件时只更新本地只读视图（Projection）或发通知，复杂逻辑应由新命令触发，保持事件处理幂等且快速
- 版本冲突需显式处理：当并发写入导致 version 不匹配，应返回
ErrOptimisticLock并让客户端重试（或自动重载+重执行）
