我有一个 Azure Web 应用程序（S2 应用程序服务计划），它设置为自动缩放，但最小实例数为 1。由于它大部分时间处于空闲状态，因此实际实例数也几乎一直为 1。
上周发生了“某事”，网站不再可用。每个请求都以 http 状态 500 得到响应。这种情况持续了大约 10 个小时，然后网站突然又可用了。在错误情况发生前几天，我没有做任何更改，也没有做任何事情让网站重新可用。
我为此发起了支持请求，一位支持工程师一直在调查此事。据他说，问题的原因是：
根本原因在于 Windows 进程激活服务，它无法运行与你的应用程序相关的进程，并且平台无法在指定的时间范围内恢复它
由于我无法配置 WPA，因此我认为这是平台的问题。支持工程师确认了这一点。
我思考这意味着 Azure 应该处理这样的状态并采取一切必要措施让应用程序重新启动。由于服务花了 10 个小时才恢复上线，我认为这是偶然发生的，Azure 并没有采取任何措施。我应该发布有关此事件的错误报告吗？（支持工程师在这里真的帮不上什么忙……）
此外，支持工程师坚持认为拥有多个实例可以解决可用性问题，因为
实例，因此我可以确认，此场景中的冗余故障转移选项将使您将站点扩展到至少两个实例。这样，如果其中一个实例不可用，第二个实例将接管。
我认为这根本不正确，因为 Azure 报告该 Web 应用程序为“健康”并且确实响应了请求，尽管状态为 500。
在这种情况下，Azure 真的会只向未返回状态 500 的实例发送流量吗？此外，鉴于我不知道最初是什么导致了 WPA 问题 - 第二个实例是否也会出现完全相同的问题？
答案1
当您将 Web 应用程序扩展到多个实例时，它们将位于负载平衡器后面（您看不到这一点，但这是在幕后发生的）。负载平衡器探测器应检测到来自第一个实例的 500 错误，并且不会将任何流量导向它。
您的 Web 应用实例将在不同的 VM 上运行，因此如果第一个 VM 上发生 WPA 问题，则不会影响第二个 VM。也就是说，第二个主机上可能会发生另一个 WPA 问题，尤其是如果您的应用中的某些内容触发了此问题。