在我的Web应用程序中,当用户登录到应用程序时,他们的浏览器会打开一个Websocket到服务器,以便可以将更新推送到浏览器.
它是在Azure应用服务中运行的ASP.NET核心Web应用程序(自托管).我想使用Azure的deployment slot swapping功能将代码更新推送到生产,零停机部署.
在我完成的有限测试中,看起来在插槽交换后,Websocket连接保持打开到浏览器所连接的原始插槽. (因此,如果浏览器的Websocket连接到插槽A,并且我们交换插槽A和B以便新连接进入插槽B,则Websocket仍将对插槽A上运行的应用程序开放.)
在某些时候,旧插槽将脱机,这将强行关闭任何打开的Websockets.我希望尽可能优雅地重新打开Websocket到新插槽,并在插槽交换后尽快重新打开,这样如果我更新与Websocket相关的代码,所有客户端将尽快运行新代码.
这可能如何工作的草图:
>进行插槽交换
>将通知发送到旧插槽上运行的代码
>在旧插槽上运行的代码会推送Websocket消息以重新连接
>收到消息后,浏览器将打开一个新的Websocket连接(将转到新的插槽)
>连接成功后,浏览器将关闭旧的Websocket
有没有更好的方法呢?
如何在旧插槽上运行的代码知道它何时被交换?
是否可以优雅地处理这个问题?或者总会有一堆竞争条件?