Golang使用RabbitMQ在微服务中实现消息队列

必须用单例或依赖注入管理amqp.Connection，配置心跳避免断连；Channel需每goroutine独立创建；队列设durable:true/autoDelete:false/exclusive:false；消息Publish时设DeliveryMode:Persistent；消费者禁用autoAck，手动ACK/NACK并设QoS；消息带版本头和vhost隔离。

能用，但必须按微服务场景重构连接和错误处理逻辑，不能照搬单体示例代码。

如何在Kratos等Go微服务框架中安全复用RabbitMQ连接

RabbitMQ的amqp.Connection是重量级资源，不能每次发消息都amqp.Dial()再conn.Close()——这会导致连接风暴、端口耗尽，且Kratos的gRPC/HTTP服务启动后长期运行，连接理应复用。

• 必须用单例或依赖注入方式管理*amqp.Connection，例如在Kratos的internal/mq/rabbitmq.go中封装NewRabbitMQConn()并缓存
• 连接需配置amqp.Config{Heartbeat: 10 * time.Second}，避免被RabbitMQ主动断连（默认心跳30秒，而很多K8s网络策略会掐掉空闲连接）
• 不要把ch, err := conn.Channel()也做*局单例：Channel不是线程安全的，每个goroutine应自己ch, _ := conn.Channel()再用完ch.Close()

ch.QueueDec

lare的持久化参数必须与业务语义对齐

微服务部署常跨环境（dev/staging/prod），队列是否自动删除、是否持久化，直接影响消息可靠性。例如订单服务发送“支付成功”事件，若队列非持久化，RabbitMQ重启后消息就丢了。

• durable: true → 队列本身存盘，RabbitMQ重启不消失（必须设为true用于核心业务）
• autoDelete: false → 避免最后一个消费者断连后队列被删（微服务滚动更新时常见）
• exclusive: false → 排他队列只允许一个连接使用，无法支持多实例消费
• 注意：durable只保证队列元数据不丢，消息是否持久还需在ch.Publish()时设amqp.Publishing{DeliveryMode: amqp.Persistent}

消费者端必须手动ACK，否则消息会堆积或重复消费

Kratos服务作为消费者时，默认autoAck: true看似省事，但一旦服务崩溃或OOM，未处理完的消息直接被RabbitMQ标记为已投递，永久丢失。

• 务必设autoAck: false，并在业务逻辑执行成功后显式调用delivery.Ack(false)
• 用ch.Qos(1, 0, false)限制预取数（prefetch count），防止一个消费者积压大量消息导致其他实例饿死
• 遇到panic或不可恢复错误，用delivery.Nack(false, true)让消息重回队尾，避免卡死
• 注意：ACK/NACK必须在同一个Channel上调用，跨goroutine传递amqp.Delivery时别漏传ch

微服务间消息格式建议用JSON Schema + 版本字段

不同服务由不同团队维护，消息结构易不一致。直接传裸JSON或map[string]interface{}会导致消费者解析失败却无明确提示。

• 在消息body开头加{"version":"v1","event":"order_paid"}，消费者先校验version再反序列化
• 用amqp.Publishing{Headers: map[string]interface{}{"content-type": "application/json; version=v1"}}带版本头，比塞进body更正交
• 避免用Go struct的json:"-" 忽略字段——下游可能升级了struct但没改消息格式，导致字段静默丢失

最常被跳过的点：RabbitMQ的virtual host（vhost）在微服务里不是可选项。Kratos各服务应分配独立vhost（如/svc-order、/svc-user），而非共用/，否则权限隔离和监控粒度全失效。这个配置藏在amqp.Dial("amqp://user:pass@host:5672/svc-order")的URL末尾，容易被忽略。