Azure 应用服务在源和目标之间交换 "Bounces"

Question

我在 Azure 应用服务上看到了一些有趣的行为，希望有人能够对此发表评论。

复制步骤(所有 Azure 步骤都可以在门户中完成):

• 在应用服务中创建一个新的 Web 应用(标准定价级别，单实例即可)，例如我的网站
• Create a new staging slot对于该应用程序，例如mysite-staging
• 使用包含内容 //ONE 的文件/scripts/test.js 将一个简单的 ASP.NET 应用部署到 mysite
• 使用包含内容 //TWO 的文件/scripts/test.js 将一个简单的 ASP.NET 应用部署到 mysite-staging
• 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(?v2 是一个新的查询字符串)
• 浏览器从 CDN 请求脚本，CDN 又从 mysite.azurewebsites.net 请求脚本。这次，“弹跳”导致响应成为脚本的 v1 版本。
• 现在，我们在 CDN 中缓存了 v1 版本的脚本，该地区的所有用户都将加载 v2 版本的页面

我的问题:交换操作期间的这种“弹跳”行为是“设计使然”吗？如果是这样，解决上述病理情况的推荐方法是什么？

Answer 1

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

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