Cloud Foundry有状态游戏应用实现优雅停机的最优方案咨询

CF应用是否支持自行终止？ #

支持。Cloud Foundry不会干预应用进程的主动正常退出行为，只要应用进程以0状态码正常退出，CF会将对应实例标记为停止状态，只要你没有配置强制自动重启策略，不会重新拉起实例。

第二种方案的干净自行终止实现步骤 #

你提到的新增运维端点的方案可以正常落地，具体实现注意以下几点即可：

• 先执行cf unmap-route命令将旧版本实例从CF路由表中解绑，从平台层面确保新请求、新WebSocket连接不会再转发到待下线的旧实例，比应用层拦截更稳妥
• 实现POST /api/admin/stop运维端点，内部逻辑包含：
  • 标记应用进入待下线状态，拒绝所有新游戏创建请求
  • 维护全局的运行中游戏/活跃WebSocket会话计数，每结束一个游戏、断开一个会话就更新计数
  • 当计数归0后，应用主动触发正常退出逻辑（不同语言实现不同，比如Java用System.exit(0)、Node.js用process.exit(0)、Go用os.Exit(0)），确保本地资源、数据库连接等全部正常释放
• 应用退出完成后，再执行cf delete清理旧版本实例即可，全程不会触发CF默认的10秒强制杀进程逻辑。

其他可选方案 #

• 调整CF停机超时方案：CF默认的10秒停机超时是可配置的，你可以通过设置环境变量CF_SHUTDOWN_TIMEOUT自定义超时时间，取值为你单局游戏的最大时长（单位秒），比如最长一局1小时就设为3600。之后只需要在应用代码中捕获SIGTERM信号，触发信号后停止接收新请求，等待所有游戏结束后主动退出即可，无需额外开发运维端点，改造成本极低。
• 蓝绿部署+会话粘滞方案：部署新版本应用时，先开启CF的会话粘滞功能，将新流量全部切到新版本实例，旧版本实例仅保留已有连接的流量，等旧版本实例的活跃会话全部清零后，再删除旧版本即可。
• WebRTC架构改造方案：该方案适合长期迭代优化，但改造成本极高，VPN、运营商NAT等场景下需要额外部署STUN/TURN服务器做连通性兜底，没有相关经验的话不建议作为短期解决方案。

最优解决方案 #

优先选择调整CF停机超时+捕获SIGTERM信号的方案，改造成本最低，也完全符合Cloud Foundry的原生设计逻辑，不需要额外开发运维接口和修改部署流程。如果不想调整全局超时配置，再选择你提到的运维端点方案即可。

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