我的理解是，当App Service的“扩展单元”（即Azure区域内的虚拟机集合）进行升级时，它们将被批量升级，称为“升级域”，与其他租户共享。
升级域完成后，会将应用程序移到该域上。这将导致冷启动，建议您使用AppInit模块...到目前为止一切正常。
我不清楚的是双重的：
A。将应用程序移至新升级的升级域时，负载平衡器是否会等到预热完成后再进行交换？类似于等待插槽交换的方式？
B。扩展实例是否始终在不同的升级域上？如果不是这种情况，则有目的地向外扩展实例，使其不太倾向于由升级引起的冷启动，或者它们不太倾向于在什么时候完成升级域？
要澄清：
对于A。 该应用程序是否仍在旧的预先升级的“升级域”上运行，而新升级的升级域却被预热，然后前端交换给它？
还是与插槽交换不同，并且应用程序正在过渡到新的VM，而不考虑其预热状态吗？然后启动AppInit？
答案 0 :(得分：1)
使用AppInit功能，随着新的Web应用程序实例被添加到循环中，我们确保应用程序初始化模块报告网站已完全预热，然后再从前端发送请求。
要使用此功能，请像下面这样在web.config中添加一个applicationInitialization部分：
<system.webServer>
<applicationInitialization remapManagedRequestsTo="/Content/warmup.html">
<add initializationPage="/api/values/100" />
</applicationInitialization>
</system.webServer>
您可以有多个初始化页面，并且AppInit模块将确保在声明站点正式预热之前所有页面都返回200。
同时，您可以（可选）使用remapManagedRequestsTo属性来创建一个友好的页面，以显示该站点仍在预热中。
借助AppInit功能，在轮换添加新实例时，客户将看不到该页面，但是，如果某个进程由于某种原因而崩溃并再次进入AppInit，它将起作用。