为什么在交换插槽时 Azure 应用服务会重新启动？

Question

在生产中遇到这个问题很长一段时间后，并且阅读了我能找到的任何内容（例如this 或this 或that），我做了一个简单的测试。

1. 创建一个空的 asp.net 网站
2. 在 Application_Start 中，向您发送电子邮件或消息（我使用过 PushBullet），以便您知道应用程序何时启动
3. 创建新的应用服务计划和资源组
4. 在 Azure 上创建网站并发布
5. 创建临时部署槽
6. 交换分期/生产
7. 再次发布网站，使两个广告位具有相同的网站版本

所以我有一个空网站，没有连接字符串，没有插槽设置：

当我点击交换时，我会收到插槽重启的通知（每个至少一次）。

为什么会这样？

更新：

在研究了 Mohit 的回答后，我需要进一步澄清。

• 我们在 Application_Start 方法中发送通知，如果我理解正确，该方法由 AppInit 事件触发。

• 我不明白你解释的行为。该顺序似乎对于确保没有停机非常重要，但您说它不一定是该顺序。为什么需要重新启动生产槽的应用程序域？为什么用户会因为网站关闭而烦恼（它不应该）？

• 什么是“新交换”功能？与“旧交换”有什么区别？对于我的测试，我只是使用门户交换。

• 您提到“新交换”在交换之前暂停。我想这只是意味着它等待 applicationInitialization 完成（例如 / 上的 HTTP 200）？

• 从昨天开始我又做了一些测试。在 Application_Start 方法中，我添加了一些 Thread.Sleep 以使应用程序启动时间更长。但是，当我交换时，我发现暂存或生产都没有停机时间。我不应该在登台时遇到停机时间，至少在我的应用程序启动期间是这样吗？这是否意味着预热然后与生产交换的插槽实际上是另一个既不是 staging 也不是 prod 的临时插槽？

Answer 1

我有非常相似的问题，应用程序在切换到生产槽后重新启动，这会导致不必要的停机。经过大量搜索，我发现了以下内容：

在某些情况下，在交换后，生产槽中的 Web 应用程序可能稍后会重新启动，而应用程序所有者无需采取任何操作。这通常发生在 Azure 应用服务的底层存储基础结构发生一些变化时。发生这种情况时，应用程序将同时在所有 VM 上重新启动，这可能会导致冷启动和 HTTP 请求的高延迟。虽然您无法控制底层存储事件，但您可以将它们对生产槽中的应用程序的影响降至最低。在应用的每个插槽上设置此应用设置：

WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG：将此设置为“1”将阻止 Web 应用的工作进程和应用域在应用服务的存储基础架构重新配置时回收。

你可以找到整个 Ruslany 帖子，我觉得这很有帮助 here