Go-Micro的Broker本质是逻辑Pub/Sub广播，非UDP多播；依赖注册中心+消息代理中转，支持跨节点；默认HTTP Broker无持久化、不保证投递，生产环境需替换为Kafka/NATS/Redis。
Go-Micro里用Broker做消息广播，本质是Pub/Sub
Go-Micro的broker不是“多播”意义上的网络层UDP多播，而是逻辑上的“发布-订阅”广播：一个服务Publish一条消息，所有订阅了该topic的Subscriber都会收到副本。它不依赖底层网络多播协议，而是靠注册中心+消息代理中转实现，因此天然跨节点、跨主机，也兼容Docker/K8s环境。
常见错误现象：Subscriber没收到消息，但Publish没报错——大概率是topic名称大小写不一致、或订阅/发布用的broker实例不是同一个（比如一个用了默认http broker，另一个手动替换成kafka插件但没统一配置）。
- 确保
service.Init()前已设置好全局broker，例如micro.Broker(broker.NewBroker()) - topic名建议全小写+下划线，避免因注册中心（如etcd）路径敏感性导致匹配失败
- 不要在
Handle函数里直接Publish同一topic——可能触发无限递归（除非你明确需要事件链式传播）
默认HTTP Broker不支持真正的“多播语义”，别被文档误导
Go-Micro v5默认的broker实现是http类型（基于HTTP长轮询模拟），它把消息暂存在内存队列，由各Subscriber主动拉取。这意味着：没有消息持久化、不保证至少一次投递、Subscriber重启后会丢失离线期间的消息。它看起来像广播，实则是“尽力而为”的单播聚合。
使用场景：开发联调、内部状态通知（如配置刷新通知）、非关键业务事件（如日志采样上报）。
- 生产环境务必替换为
kafka、nats或redis插件，地址在github.com/micro/go-plugins/broker - 若坚持用默认HTTP broker，请在
Subscriber启动时加autoAck: false并手动Ack()，否则消息可能被重复消费 -
httpbroker的Subscribe默认超时是30秒，长连接中断后需重连，实际广播延迟不可控
如何让多个服务实例都收到同一条消息？重点看Subscriber注册方式
Go-Micro的broker.Subscribe默认会为每个Subscriber分配唯一ID（基于服务名+随机字符串），所以即使10个helloworld实例都订阅user.created，它们都会各自收到一份。这不是“负载均衡”，而是真正的“广播”——和Kafka的consumer group模式相反。
容易踩的坑：Subscriber函数里没加defer msg.Ack()，导致broker反复重发；或者误以为要手动遍历服务发现列表去逐个HTTP POST——完全没必要，Broker层已封装。
- 订阅代码必须放在
service.Run()之前，否则服务注册完成前就错过了broker初始化时机 - 如果只想让“某个集群内最新上线的一个实例”处理事件（即竞争消费），得改用
broker.Options{AutoAck: true}+ 去重逻辑，而非依赖broker本身 - 消息体推荐用
proto.Message序列化，避免JSON字段名大小写或空值处理差异引发的反序列化失败
mDNS服务发现对Broker广播没直接影响，但会影响Subscriber发现稳定性
registry/mdns只管服务地址注册与解析，不参与Broker消息路由。但如果你用mDNS作为注册中心，又没配健康检查，那么某台机器上挂掉的Subscriber进程仍会留在注册表里——Broker尝试推送消息时会失败，且默认不重试到其他节点（因为它是“广播”，不是“选一个”）。
性能影响：mDNS在局域网内延迟低，但节点数超过50后广播包激增，可能触发交换机限速；跨子网基本失效。
- 生产环境必须换
consul或etcd，并开启health check，确保Broker只向存活Subscriber发消息 - 测试时可用
micro.Registry(registry.NewRegistry())（内存注册表）快速验证逻辑，但别混淆它和broker的功能边界 - 别在
Subscribe回调里做耗时操作（如DB写入），否则阻塞整个broker事件循环——应起goroutine或投递到worker queue
真正麻烦的是消息顺序和幂等——Broker不保证同一topic内消息的全局顺序，也不提供去重ID机制。如果你需要“用户创建后立即同步头像”，就得在业务层加版本号或时间戳校验，不能指望框架兜底。
