asp.net-core – 如何在部署插槽交换后优雅地迁移打开的Websocke

发布时间：2020-12-16 04:04:58 所属栏目：asp.Net 来源：网络整理

导读：在我的Web应用程序中,当用户登录到应用程序时,他们的浏览器会打开一个Websocket到服务器,以便可以将更新推送到浏览器. 它是在Azure应用服务中运行的ASP.NET核心Web应用程序(自托管).我想使用Azure的deployment slot swapping功能将代码更新推送到生产,零停机

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

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

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

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

这可能如何工作的草图：

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

有没有更好的方法呢？

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

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

解决方法

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

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

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!