Azure App-Service交换源和目标之间的“跳出”

Question

我在Azure App Service上看到了一些有趣的行为，我希望有人会对此发表评论。

复制步骤（所有Azure步骤都可以在门户中完成）：

• 在App Service中创建一个新的Web App（标准定价级别，单个实例很好），例如mysite
该应用的
• Create a new staging slot，例如mysite-staging
• 使用内容为mysite
的文件/scripts/test.js将一个简单的ASP.NET应用程序部署到//ONE
• 使用内容为mysite-staging
的文件/scripts/test.js将一个简单的ASP.NET应用程序部署到//TWO
• Swap the deployment slots
• 交换开始后，立即导航到mysite.azurewebsites.net/scripts/test.js并在交换操作期间监控返回的内容（通过在浏览器中不断进行强制刷新）

我期望看到的内容：

• 在互换期间的某个时刻，内容从//ONE到//TWO
无缝/一致/不可逆地变化

我实际看到的内容：

• 在互换操作期间，内容在//ONE和//TWO之间“闪烁”/“反弹”。交换操作完成后，行为稳定并始终返回//TWO

观察到的行为表明，没有一个时间点可以说所有流量都可用于新版本。

我担心的原因如下：

• 用户请求一个页面mysite.azurewebsites.net，在此“弹跳”阶段，使用“v2”版本的页面响应CDN托管的脚本mycdn.com/scripts/test.js?v2（{{ 1}}是一个新的查询字符串）
• 浏览器从CDN请求脚本，然后CDN从?v2请求脚本。这一次，“弹跳”导致响应成为脚本的v1版本。
• 现在我们在CDN中缓存了一个v1版本的脚本，该区域的所有用户都将使用v2版本的页面加载

我的问题：在“按设计”的交换操作中，这种“弹跳”行为是什么？如果是这样，解决上述病理情况的推荐方法是什么？

Answer 1

您所描述的行为目前正在设计中。当我们执行交换时，我们更新主机名和数据库中站点之间的映射，但是我们的前端实例会缓存这些映射并每隔30秒刷新一次。因此，“弹跳”时段可能持续长达30秒。

我目前没有关于如何解决此案的好建议，但会研究解决此问题的可能方法。