我们在Azure App Service上托管了一个.net核心应用程序。它在64位平台上运行，已启用“始终在线”，并且还启用了本地缓存功能。
除了生产插槽，我们还有一个质量检查插槽。 QA插槽的配置与生产插槽相同。当前，我们的部署过程包括手动发布到QA插槽，然后手动执行几次“健全性”测试，然后从门户调用“交换预览”（源质量检查，目标生产）选项的第一步。然后，我们最终调用“完全交换”选项。
通常（但并非总是）（可能每隔第二次），在调用“交换预览”选项的第一步后，生产广告位会立即重新启动。 QA插槽永不重启。我们通过在Kudu控制台中的Process Explorer中查看相关流程的开始时间来知道这一点。
根据我的理解，“与预览交换”的第一步应该永远不会影响生产版位。如果有的话，它应该只接触到QA插槽，因此我们的观察似乎落后于我们的预期。重新启动生产广告位会导致实时应用中大约15秒钟没有响应（但是至少不会返回“服务不可用”错误）。
这种不可预测的行为使我们不愿在“繁忙”时间内进行部署，因为我们“害怕”生产槽位会重新启动并给我们的用户造成延迟。
我们尝试使用全新的“诊断和解决问题”工具来弄清楚生产版位重新启动的原因，但该工具甚至都没有报告重新启动（即使很明显，该应用程序已从Kudu中的Process Explorer）。
我试图通过一个简单的Web应用程序在一个隔离的帐户中重现此行为，但无济于事。
我的问题：也许有人可以阐明为什么生产插槽可能会重新启动和/或如何继续诊断该问题吗？
答案 0 :(得分：0)
也许有人能弄清楚为什么生产槽可能会重新启动
正如您所说，您将部署过程手动发布到QA插槽。要利用暂存槽，请更新Jenkins（您的CI）中的Git部署位置，以指向暂存槽的Git URL。 不要手动执行，请设置Jenkins作业即可。
按两次交换键将执行一次交换，然后再进行另一次交换，从而将原始应用程序代码放回原处。 这会导致重新启动生产版位，并将您的生产应用程序关闭1至5分钟。
有关更多详细信息，您可以参考此article。
答案 1 :(得分：0)
要检查的是配置。如果配置之间存在差异（appsettings / connectionstring，还有其他设置），则它们可能会在交换时重新启动。至少我在这些情况下看到过奇怪的行为。
尝试一下，导出应用程序服务的ARM模板（和暂存槽）并比较所有配置值。确保所有内容都相同。并查看问题是否仍然存在。