Azure Web 应用程序随机重启 - 有人可以扩展此建议吗？

Question

最近对 Azure Web api 宕机进行调查(它不喜欢冷重启，因为排队的请求会淹没服务器，即 503)，我收到以下信息:

Your application was restarted as site binding status changed. This can most likely occur due to recent deployment slot swap operations. In some cases after the swap the web app in the production slot may restart later without any action taken by the app owner. This restart may take place several hours/days after the swap took place. This usually happens when the underlying storage infrastructure of Azure App Service undergoes some changes. When that happens the application will restart on all VMs at the same time which may result in a cold start and a high latency of the HTTP requests. This event occurred multiple times during the day.

建议是

to minimize the random cold starts, you can set this app setting WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG to 1 in every slot of the app.

有人可以详细说明一下吗？我是否正确地认为，如果我们在未来的某个随机点进行交换(例如:暂存到生产环境)，应用程序将重新启动？

应用程序设置的实际作用是什么？它将如何阻止 Azure 重新启动生产槽？

答案来自 Patrick Goode 提供的链接，他的 google-foo 比我的好得多

"Just to explain the specifics of what WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG app setting does. By default we put the site’s hostnames into the site’s applicationHost.config file “bindings” section. Then when the swap happens the hostnames in the applicationHost.config get out of sync with what the actual site’s hostnames are. That does not affect the app in anyway while it is running, but as soon as some storage event occurs, e.g. storage volume fail over, that discrepancy causes the worker process app domain to recycle. If you use this app setting then instead of the hostnames we will put the sitename into the “bindings” section of the appHost.config file. The sitename does not change during the swap so there will be no such discrepancy after the swap and hence there should not be a restart."

Answer 1

看起来此设置应该防止“随机冷重启”

https://ruslany.net/2019/06/azure-app-service-deployment-slots-tips-and-tricks