在部署插槽交换后,如何正常迁移打开的Websocket连接？

Question

在我的Web应用程序中,当用户登录到应用程序时,他们的浏览器会打开一个Websocket到服务器,以便可以将更新下推到浏览器.

它是在Azure应用服务中运行的ASP.NET核心Web应用程序(自托管).我想使用Azure的部署插槽交换功能将代码更新推送到生产中,无需停机部署.

在我完成的有限测试中,看起来在插槽交换后,Websocket连接保持打开到浏览器所连接的原始插槽.(因此,如果浏览器的Websocket连接到插槽A,并且我们交换插槽A和B以便新连接进入插槽B,则Websocket仍将对插槽A上运行的应用程序开放.)

在某些时候,旧的插槽将被脱机,这将强行关闭任何打开的Websockets.我希望尽可能优雅地重新打开Websocket到新插槽,并在插槽交换后尽快重新打开,这样如果我更新与Websocket相关的代码,所有客户端将尽快运行新代码.

这可能如何工作的草图:

1. 插槽交换发生
2. 将通知发送到旧插槽上运行的代码
3. 在旧插槽上运行的代码会推送Websocket消息以重新连接
4. 收到消息后,浏览器将打开一个新的Websocket连接(将转到新的插槽)
5. 连接成功后,浏览器将关闭旧的Websocket

有没有更好的方法呢？

如何在旧插槽上运行的代码知道它何时被交换？

是否可以优雅地处理这个问题？或者总会有一堆竞争条件？

Answer 1

WebSockets 确实保持连接，因为 ARR 只能将新请求定向到“新”应用程序。例如，如果您在交换中间下载一个大文件，您会看到相同的行为。

我处理这个问题的方法是让我的部署系统 (Octopus) 进行交换，然后向“旧”应用程序发出请求，通知所有连接的 WebSocket 客户端它们需要断开连接并重新连接。客户端将立即断开连接，选择一个随机延迟（以防止一次重新连接数千次），然后在该延迟后重新连接。