Golang微服务事件驱动通信关键在于消息不丢不重、可追溯、易维护，需攻克序列化设计、消费者幂等性、连接生命周期管理三关；NATS JetStream是轻量首选，配合nats.go简洁高效，须强制事件结构含type/version字段、业务幂等+手动ACK、合理生命周期管理。
用 Golang 实现微服务间事件驱动通信，核心不是“能不能发消息”，而是“如何让消息不丢、不重、可追溯、易维护”。选对中间件只是起点，真正卡住团队的往往是序列化设计、消费者幂等性、连接生命周期管理这三关。
用 nats.go 快速搭建轻量级事件总线
NATS（尤其 JetStream）是 Go 微服务内部通信最顺手的选择：启动快、延迟低、API 简洁，且官方 nats.go 库成熟稳定。它不像 Kafka 那样需要 ZooKeeper 或复杂配置，适合快速验证 EDA 模式。
- 开发阶段直接用
nats-server单节点启动，无需 Docker Compose 编排 - 发布事件只需
js.Publish("order.created", data)，订阅用js.Subscribe("order.created", handler) - JetStream 启用持久化流后，消费者重启也能回溯未处理事件，避免“上线即丢数据”
- 注意：默认 NATS 是无状态的，不启用 JetStream 时，消费者断连期间发布的事件会丢失
定义事件结构体时必须带 Type 字段和版本标识
没有类型字段的 JSON 事件等于裸奔——消费者收到消息后根本不知道该交给哪个 handler 处理。更糟的是，如果后续加字段或改语义，不带版本的事件会让旧消费者 panic 或静默出错。
- 强制在每个事件 struct 中嵌入公共字段：
Type string `json:"type"`和Version string `json:"version"`（如"v1"） - 避免用
interface{}做Payload，而应为每类事件定义具体 struct（如OrderCreatedEvent），再通过json.Unmarshal到对应类型 - 不要把时间戳存在字符串里，用
time.Time字段 +json:"timestamp,string"标签，既可读又防解析错 - 错误示例：
{"event":"order_created","data":{"id":123}}→ 类型模糊、无版本、时间缺失
消费者必须实现幂等 + 手动 ACK，否则必然重复消费
所有消息中间件（NATS JetStream / Kafka / RabbitMQ）在故障恢复时都可能重投消息。如果你的库存扣减逻辑没做幂等，一次网络抖动就可能导致超卖。
立即学习“go语言免费学习笔记（深入）”；
- 用业务唯一键（如
order_id）+ 去重表（Redis SETNX 或数据库唯一索引）拦截重复事件 - NATS JetStream 订阅时设
DeliverPolicy = nats.DeliverAll并开启AckWait，处理完调用msg.Ack()；不手动 ACK，消息会在超时后自动重发 - Kafka 消费者需控制
CommitInterval，避免频繁提交 offset 导致“已处理但未提交”状态丢失 - 切忌在 handler 里直接写 DB 更新后就返回——要确保业务逻辑执行完毕、幂等校验通过、ACK 发出，三者缺一不可
segmentio/kafka-go vs sarama：选型看维护成本，不是性能
别被 benchmark 迷惑。在绝大多数微服务场景中，kafka-go 的吞吐完全够用，且它的 API 设计更贴近 Go 习惯；而 sarama 功能全但配置项爆炸，一个 Producer 初始化要填 20+ 参数，升级还常破兼容性。
- 用
kafka-go：适合中小团队，关注点在业务而非客户端调优；Writer自带重试、压缩、负载均衡，开箱即用 - 用
sarama：仅当你需要细粒度控制 SASL/SSL、自定义 Partitioner、或对接旧版 Kafka（ - 两者都需注意：Kafka 主题名不能含大写字母或下划线（只允许小写字母、数字、连字符），否则生产者会静默失败
- 本地调试时，
kafka-go支持localhost:9092直连；sarama默认要求 broker 返回的 host 名与客户端请求一致，需改/etc/hosts或配AdvertisedHost
最容易被忽略的一点：事件总线不是“加个库就能跑”的功能模块，它是整个系统的神经反射弧。一旦某个消费者卡住、序列化失败或 ACK 超时，问题会像多米诺骨牌一样蔓延到上游。所以从第一天起，就要把事件消费日志、重试次数、DLQ（死信队列）接入 Prometheus + Grafana，而不是等线上告警才去翻日志。
