Pub/Sub push订阅切换pull订阅的滚动部署最佳实践咨询

你提到的新建独立topic+pull订阅的方案是可行的，但不属于最优的最佳实践，该方案需要上游生产者同步适配切换，协同成本高，且旧topic存量消息消费完毕的时间点难以精准判断，会拉长整体切换周期。

最优无感知切换方案（无需修改上游生产者逻辑） #

核心利用Pub/Sub的订阅隔离特性：同一个topic下的多个订阅相互独立，消息会广播给所有订阅，但每个订阅的消费位点完全隔离，互不影响。具体步骤如下：

1. 在现有业务topic下新建独立的pull订阅，创建完成后暂不开启消费，不调整任何现有线上资源
2. 改造消费端代码，同时兼容push、pull两种消费逻辑，新增配置开关控制单实例启用的消费模式，强制两种模式互斥，不能同时启用
3. 灰度滚动发布服务：
   • 首批发布少量实例，配置开关设置为仅启用pull模式，发布后观察pull消费的延迟、错误率是否正常
   • 无异常则逐步扩大pull实例的占比，直到所有运行实例全部切换为pull模式，此时旧push订阅已无消费者承接投递
4. 等待旧push订阅的存量消息全部被消费完成，且至少超过订阅配置的最大消息保留时长后，直接删除旧push订阅
5. 后续常规迭代中，直接移除代码中的push消费逻辑即可完成全部切换

方案优势 #

• 仅需改造消费端，不需要上游生产者配合修改投递逻辑，链路复杂度低，协同成本极低
• 切换过程可灰度、可快速回滚：如果pull模式出现异常，直接将实例配置切回push模式即可恢复
• 完全满足你的要求：
  • 无重复消费：同一时间只有一种模式的消费逻辑在运行，消息虽然会同时投递到两个订阅，但只有一个订阅的消费者会实际处理
  • 无消息丢失：pull订阅创建后所有新消息都会持久化存储，不会漏过切换过程中的任何消息，旧push订阅的存量消息也会全部被消费完毕
• 切换周期可控，不需要等待旧topic完全清空，按消息保留时长到期即可下线旧资源

注意事项 #

• 如果你的业务消费逻辑没有做幂等，必须确保两种消费模式的开关强互斥，禁止单个实例同时运行两类消费逻辑
• 删除旧push订阅前，必须确认所有实例均已切换为pull模式，无任何服务监听push投递端点
• 可将pull订阅的ack_deadline（消息确认超时时间）配置为和原push模式的超时时间一致，避免切换过程中出现不必要的消息重投

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