用消息队列（如 RabbitMQ、Kafka 或 NATS JetStream）实现服务间异步调用，是 Golang 微服务中最可靠、可扩展性最强的方式；单纯靠 goroutine 跨服务调用只是伪异步，本质仍是同步网络请求，无法解耦、不可重试、不抗压。
用消息队列（如 RabbitMQ、Kafka 或 NATS JetStream）实现服务间异步调用，是 Golang 微服务中最可靠、可扩展性最强的方式；单纯靠 goroutine 跨服务调用只是伪异步，本质仍是同步网络请求，无法解耦、不可重试、不抗压。
为什么不用 goroutine 直接发 HTTP/gRPC？
很多人第一反应是“起个 goroutine 调用另一个服务不就异步了？”，但这是典型误区：
- HTTP/gRPC 本身是阻塞协议，
goroutine只是把阻塞转移到后台协程，下游服务挂了、超时、慢响应，依然会堆积协程、耗尽连接池或内存 - 没有持久化、无 ACK、无重试、无死信——消息丢了就真丢了
- 无法水平扩缩消费者：10 个实例同时拉取同一订单事件？必须靠消息队列的消费者组机制来协调
- 调试困难：没有消息轨迹、无法追溯“谁发的、谁没收到、哪条失败了”
RabbitMQ 生产者怎么写才不丢消息
关键不是“发出去”，而是“确认发成功”。RabbitMQ 默认是 fire-and-forget 模式，必须显式开启确认机制：
- 连接时启用
amqp.Publishing{DeliveryMode: amqp.Persistent}，确保消息写入磁盘 - 调用
channel.Confirm()开启发布确认，并用channel.NotifyPublish()监听成功/失败 - 不要在循环里直接
channel.Publish()—— 要等上一条确认后再发下一条，或批量确认（需自行维护序号与回调映射） - 错误处理必须包含：网络断开重连、信道异常重建、失败消息落库或进死信交换器（
dead-letter-exchange）
ch.Publish(
"", // exchange
"order.created", // routing key
false, // mandatory
false, // immediate
amqp.Publishing{
ContentType: "application/json",
Body: payload,
DeliveryMode: amqp.Persistent, // ← 必须设为持久化
},
)消费者如何保证“至少一次”且不重复处理
“至少一次”靠 RabbitMQ 的手动 ACK；“不重复”靠业务幂等——两者缺一不可：
立即学习“go语言免费学习笔记（深入）”；
- 创建 channel 时设
channel.Qos(1, 0, false)，限制未确认消息数，防止单个消费者积压拖垮全局 - 消费逻辑完成后，**再调用**
delivery.Ack(false)；若 panic 或 error，调用delivery.Nack(true, true)重回队列头部（注意避免无限循环） - 每条消息带唯一
message_id（如 UUID），入库前先查SELECT 1 FROM processed_msgs WHERE msg_id = ?，命中则跳过 - 不要依赖 RabbitMQ 的
delivery.Tag做幂等——它只在当前 channel 有效，重启后重置
什么时候该切到 Kafka 或 NATS JetStream
选型取决于你的 SLA 和运维能力：
-
RabbitMQ：适合中小规模、需要灵活路由（topic/exchange/bindings）、强事务语义（如延迟队列插件）、已有运维经验的团队 -
Kafka：吞吐 > 10k msg/s、需长期留存（7–30 天）、多订阅方独立消费偏移、有 Flink/Spark 实时链路——但注意__consumer_offsets主题故障会导致整个集群不可用 -
NATS JetStream：轻量、嵌入友好、Go 官方 client 集成极顺，适合边缘计算或新项目快速启动；但不支持传统 DLQ，需自己用 stream + consumer filter 模拟
跨服务异步的本质不是“快”，而是“稳”和“可修复”。消息队列不是锦上添花的组件，它是微服务之间那根看不见但必须绷紧的保险绳——松了，整条链路就断得无声无息。
