实战Go微服务消息推送系统-Golang-PHP中文网

不能直接用 net/http + gorilla/websocket 上生产，因为二者不处理连接管理、心跳保活、并发写安全、多端互斥、离线兜底五件事；Go-Zero 通过微服务拆分明确职责边界；Gotify 仅适用于弱送达要求的内部通知；企业微信 SDK 严格受限于应用消息接口与通讯录权限。

实战go微服务消息推送系统

为什么不能直接用 `net/http` + `gorilla/websocket` 上生产

因为连接管理、心跳保活、并发写安全、多端互斥、离线兜底这五件事，net/http 和 gorilla/websocket 都不负责——它们只管“连上”和“收发字节”，其余全是业务逻辑。

常见现象包括：用户切后台 5 分钟后连接静默断开但服务端无感知；同一用户手机+PC 同时在线，消息重复推；高并发推送时 panic: concurrent write to websocket connection；HTTP 接口触发推送，目标用户离线，直接卡住整个 handler。

必须自己实现 TCP 层 + 应用层双心跳：conn.SetPingHandler 处理 websocket.PingMessage，同时客户端每 30s 主动发 {"type":"pulse"}，服务端回 {"type":"pong"}，连续 2 次未收到就 conn.Close()
http.Request.Context().Done() 在 WebSocket 升级后失效，不能用来判断断连
所有写操作必须串行：用 chan []byte 做写队列，单 goroutine 顺序调用 conn.WriteMessage，写前检查 conn.IsClosed()
用户 ID 到连接的映射要用 map[string][]*Client + sync.RWMutex，新连接建立时主动 close 所有旧连接，不能等超时或 GC

Go-Zero 怎么简化消息推送的微服务拆分

Go-Zero 不是帮你少写代码，而是把“谁该管什么”这件事划清楚。比如 user 服务只管认证和在线状态更新；message 服务只管消息格式校验、路由决策、落库；push 服务只管连接管理、实时下发、离线兜底。

它通过 goctl 自动生成 RPC 接口定义和 client/stub 代码，避免手写序列化/反序列化和错误码透传。比如 message.Push 方法被调用时，push 服务拿到用户 ID 后，直接查 user 服务获取当前活跃连接列表，再批量投递——RPC 调用天然带超时、重试、熔断。

连接状态建议存 Redis，但 DEL 连接 key 和 PUBLISH 离线事件之间有竞态，必须用 Lua 脚本保证原子性
离线消息不能只写 MySQL，要加内存环形缓冲（如 ringbuffer 包）做写缓冲，再异步落库，否则高并发写 DB 直接拖垮
广播类推送（如全量通知）必须拆任务：center 服务把目标用户分片，每个分片由独立 goroutine 调用 push 服务，避免单点阻塞

Gotify 适合什么场景，又容易在哪翻车

Gotify 是开箱即用的轻量级推送服务，不是框架，也不解决“用户身份绑定”“消息幂等”“多端互斥”这些事。它适合内部工具通知、CI/CD 结果推送、运维告警这类“发了就行、不强求送达、不关心谁发给谁”的场景。

WebSocket 8.18.2

WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。

下载

典型翻车点：用 gotify/server 的 token 当作业务用户凭证；在 Android 客户端里硬编码 server 地址导致无法灰度；把 priority=5 当作消息重要性分级，却没配好客户端通知渠道权限。