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

前端之家收集整理的这篇文章主要介绍了asp.net-core – 如何在部署插槽交换后优雅地迁移打开的Websocket连接?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
在我的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客户端他们需要断开连接并重新连接.客户端将立即断开连接,选择随机延迟(以防止数千次重新连接),然后在延迟后重新连接.

猜你在找的asp.Net相关文章