17370845950

NATS最轻量适合内部微服务通信，Kafka+ sarama支持持久化与多分区；channel仅限单进程goroutine通信，跨服务无效；NATS需显式Subscribe且主题名严格匹配；Kafka消费需谨慎选择OffsetNewest/OffsetOldest并手动提交offset。

用 nats.go 实现事件订阅最轻量、启动最快，适合内部微服务通信；若需持久化、重试、多分区消费，则必须换 Kafka + sarama。

为什么不能直接用 channel 做跨服务订阅

本地内存级 chan 看似简单，但微服务是独立进程——user-service 和 email-service 不在同一个地址空间，发到 chan 的消息另一方根本收不到。硬用会卡死或 panic，常见错误是：fatal error: all goroutines are asleep - deadlock!。

• channel 只适用于单进程内 goroutine 通信，不是消息中间件替代品
• 没有持久化：服务重启后未消费事件全丢
• 无广播能力：一个事件无法同时通知多个服务（如 email + sms + audit）
• 无确认机制：消费者处理失败，没人知道该重发

nats.Connect() 后必须显式调用 Subscribe() 才能收事件

NATS 默认不自动监听任何主题，连接成功只是“通了网”，不等于“开了收音机”。漏掉这步会导致服务静默运行、日志无报错、但永远收不到 "user.created" 这类事件。

nc, err := nats.Connect(nats.DefaultURL)
if err != nil {
    log.Fatal(err)
}
// ✅ 必须手动订阅
nc.Subscribe("user.created", func(msg *nats.Msg) {
    var event UserCreatedEvent
    if err := json.Unmarshal(msg.Data, &event); err != nil {
        log.Printf("parse fail: %v", err)
        return
    }
    sendWelcomeEmail(event.Email)
})
// ❌ 没有这一行，代码跑得再快也收不到消息

• 主题名（subject）要和发布方完全一致，大小写敏感，不支持通配符模糊匹配（除非用 SubscribeSync 配合 wildcard）
• 回调函数里别直接做耗时操作（如发邮件），建议起 goroutine 或投递到 worker pool，避免阻塞 NATS 内部 reader
• 如果需要确保至少一次投递，要用 QueueSubscribe + 消费组，否则默认是广播模式，每个订阅者都收到一份

用 sarama 订阅 Kafka 时，OffsetNewest 和 OffsetOldest 切换影响极大

新消费者第一次连 Kafka，默认从最新 offset 开始读（OffsetNewest），意味着它会跳过所有历史事件。上线灰度时经常发现“老用户没收到欢迎邮件”，就是因为这个配置没改。

• OffsetNewest：只收启动后的新事件，适合测试环境或事件幂等性极强的场景
• OffsetOldest：从最早一条开始读，上线初期用于补数据，但要注意重复消费风险
• 生产环境推荐用 OffsetNewest + 外部存储记录已处理的 order_id，靠业务层去重
• 别依赖 consumer group 自动 commit offset —— sarama 默认关闭 auto-commit，必须手动调用 MarkOffset，否则重启就重放

真正难的不是写几行 Subscribe，而是决定事件边界：一个“订单创建”事件，该不该包含用户手机号？库存扣减要不要等它？这些业务语义一旦定错，后面加字段、改格式、做兼容，比换中间件还疼。