Go gRPC聊天应用：微服务环境下如何跨实例共享HTTP2/gRPC流？

问题场景 #

我正在用Go实现一个基于gRPC的简单聊天应用，单体架构下运行正常：用户连接时调用CreateStream函数，将流保存到服务器的Connection列表中，消息广播通过遍历列表调用stream.Send推送。

type Server struct {
    Connection []*Connection
}

func (s *Server) CreateStream(pconn *proto.Connect, stream proto.Broadcast_CreateStreamServer) error {
    conn := &Connection{
        stream: stream,
        id:     pconn.User.Id,
        active: true,
        error:  make(chan error),
    }

    s.Connection = append(s.Connection, conn)

    return <-conn.error
}

但当微服务部署在负载均衡器后，由于服务器实例动态创建销毁，这种本地连接管理方式失效了。请问：

• 如何在微服务环境中管理HTTP2（或gRPC）流？
• 是否可以将流存储到数据库中，让同一微服务的多个实例访问相同的流？

核心结论 #

首先明确：gRPC流无法直接存储到数据库供多实例共享。因为gRPC流是绑定在当前服务器进程的TCP连接上的双向通信通道，包含实时的网络状态、读写缓冲区等进程内资源，数据库只能存储静态元数据（比如用户ID、连接标识），没法序列化和复用活跃的流对象。

微服务场景下的可行方案 #

1. 基于消息中间件的全局消息路由 #

这是最常用的适配方案，核心是用中间件做消息的全局转发，每个实例只维护自己进程内的连接：

• 每个gRPC服务器实例启动时，订阅消息中间件的指定主题（比如按聊天房间、用户分组）。
• 当某个实例收到用户的消息时，先将消息发送到中间件的对应主题。
• 所有实例收到中间件推送的消息后，遍历自己维护的Connection列表，找到目标用户的连接，调用stream.Send推送消息。
• 可选中间件：Redis Pub/Sub（轻量、低延迟）、Kafka（高吞吐量、持久化）、RabbitMQ（可靠投递）。

2. 粘性会话+实例映射 #

通过负载均衡的粘性会话策略，让同一用户的所有gRPC连接都路由到同一个实例：

• 配置负载均衡器（比如Nginx、Envoy）开启粘性会话，基于用户ID或连接标识做哈希路由。
• 用Consul、Etcd等服务注册中心维护用户到实例的映射，当实例扩容或缩容时，更新映射关系，并通知客户端重新连接到新的实例（因为gRPC长连接无法直接迁移）。
• 注意：实例故障时会导致用户连接中断，需要客户端实现自动重连逻辑。

3. 独立网关层管理连接 #

单独部署一层网关服务，专门负责维护所有用户的gRPC长连接：

• 所有用户客户端直接连接到网关，网关维护全局的Connection列表。
• 网关和后端gRPC业务实例用普通的gRPC调用交互，业务实例只处理消息的业务逻辑（比如消息存储、权限校验）。
• 网关收到业务实例的消息后，负责推送给对应的用户连接。
• 优势：后端实例无需关心连接管理，专注业务；网关可以独立扩容，更容易实现连接的监控和运维。

内容的提问来源于stack exchange，提问作者Vingtoft