2

对于我们的 Azure 功能，我们使用具有以下应用设置的自动插槽交换功能，以确保我们的插槽在上线之前被预热：

WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS = 1 
WEBSITE_SWAP_WARMUP_PING_PATH = "/api/healthcheck"
WEBSITE_SWAP_WARMUP_PING_STATUSES = "200"

这导致我们的 ADO 管道调用运行状况检查端点（已确认），并且只有在成功时才将插槽交换为活动状态。

问题是，在这一切发生之后，在我们收到响应之前，需要等待很多秒的请求。此后的任何请求几乎都是即时的。这种行为对于每次部署都是一致的。

我们不会预料到这一点，因为我们知道在命中运行状况检查端点时，暂存插槽会被加热，然后插槽会被交换到生产中。那么为什么我们会遇到这种冷启动延迟呢？我们甚至可以在插槽交换完成后等待一两分钟，而且我们总是能体验到它。

是否发生了一些奇怪的事情，例如一旦将插槽移至生产环境，它需要在加热之前再次被击中？

4

1 回答 1

1

这可能会对您有所帮助。

插槽交换后，应用程序可能会遇到意外重启。这是因为在交换之后，主机名绑定配置不同步，这本身不会导致重新启动。但是，某些底层存储事件（例如存储卷故障转移）可能会检测到这些差异并强制所有工作进程重新启动。要最小化这些类型的重启，请在所有插槽上设置 WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1 应用程序设置

如果您将变量设置WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG为1您应该能够摆脱冷启动，这是由重新启动主机引起的。但是，请注意，槽函数期间处理请求的速度可能非常慢。

你也可以查看这个 github 问题，在那里你可以找到关于零停机时间部署的讨论。

于 2020-08-25T10:04:10.380 回答