在微服务架构下,SSE 长连接通常终止于网关层(如腾讯云API网关、Kong、Nginx ),或由专门的推送服务统一管理。如果每个微服务实例都直接维护SSE连接,当该实例下线或扩容时,连接到该实例的用户会全部断线并重连,造成较大的重连风暴。推荐方案是将SSE连接管理抽离为独立的推送服务(Push Service),其他微服务通过消息队列或gRPC向推送服务发送事件,由推送服务统一负责向在线客户端广播。
典型的微服务SSE架构为:多个业务微服务将需要推送的事件发布到消息队列(如腾讯云CMQ、CKafka 、RabbitMQ ),SSE 推送服务消费这些队列中的消息,并通过内存中的连接映射表将消息推送到对应的客户端SSE连接。该方案实现了业务处理逻辑与连接管理的解耦,且支持推送服务的水平扩展(通过按用户ID哈希分片连接到不同推送服务实例)。
当SSE推送服务需要水平扩展时,客户端的SSE连接会分散到多个推送服务实例上。如果业务服务需要向特定用户推送消息,需要一种机制来确定该用户的SSE 连接当前由哪个推送服务实例持有。常见解决方案包括:使用Redis 等分布式KV存储记录用户ID到推送服务实例地址的映射;或使用腾讯云CMQ等消息队列的广播/订阅能力,让所有推送服务实例都收到消息后各自判断是否需要处理。
在腾讯云TKE 等Kubernetes环境中部署SSE推送服务时,需注意:Pod缩容或滚动更新会导致该Pod上的SSE连接全部断开,需确保客户端有自动重连机制;可使用Pod的preStop钩子,在Pod退出前等待足够长时间(如30秒),让客户端重连到其他Pod;Ingress Controller(如Nginx Ingress)需配置足够大的代理读取超时(proxy-read-timeout),避免正常但空闲的SSE连接被Ingress主动断开。