asp.net-core - 在部署槽交换后，如何优雅地迁移打开的 Websocket 连接？

Question

在我的网络应用程序中，当用户登录应用程序时，他们的浏览器会打开一个到服务器的 Websocket，以便可以将更新推送到浏览器。

它是一个在 Azure 应用服务中运行的 ASP.NET Core Web 应用(自托管)。我想使用 Azure 的 deployment slot swapping将代码更新推送到生产环境并实现零停机部署的功能。

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

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

它如何工作的草图:

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

有更好的方法吗？

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

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

Answer 1

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

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