交换插槽时，为什么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来延长应用程序的启动时间。但是，当我调换产品时，无论是分期还是生产，都不会停机。我是否应该至少在应用程序启动期间经历登台停机时间？这是否意味着经过预热然后与生产交换的插槽实际上是另一个既未登台也不生产的临时插槽？

Answer 1

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

\n\n

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

\n\n

WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG：将此设置为 \xe2\x80\x9c1\xe2\x80\x9d 将阻止 Web app\xe2\x80\x99s 工作进程和应用程序域在应用服务\xe2\x80\x99s 存储基础结构重新配置时回收。

\n\n

你可以在这里找到整个 Ruslany 帖子，我发现它非常有帮助

\n