.net - 在发生哪种类型的异常/崩溃后，Azure 云实例会重新启动？

Question

据我所知，角色实例应该在崩溃/失败后自动执行重新启动。
为了测试这种行为，我编写了一个应用程序来强制执行内存不足异常，但我的应用程序崩溃了。角色实例没有执行重新启动，因为它仍在运行并且正常 - 实例只是重新启动了 .NET 运行时。

我试图找出实例对不同错误的 react 。就我而言，不需要重新启动。什么类型的错误/异常(我可以强制执行)会导致实例完全重启？什么类型的错误/异常会永远杀死一个实例？

Answer 1

导致角色实例被回收(重新启动)的唯一原因是 Run RoleEntryPoint的方法退出。这通常发生在您:

已覆盖 Run () 方法，以及

在你的程序代码中有一个未处理的异常，这会导致 Run()退出方法

但是，当您启用 IntelliTrace 日志收集时，您的角色将回收，而是挂起。

WebRole 的默认模板不会覆盖 Run()方法，因此保留默认实现，即“Thread.Sleep(-1);”。没有(自动)事件会导致 WebRole 的自动角色回收。除非您在 RoleEntryPoint 中执行某些操作，否则会导致 Run 方法退出。这种自动回收只发生在 WorkerRole 上，它确实实现了 Run() 方法。

更新 1(根据评论 1)

run-Methoded of a RoleEntryPoint faces an error

不仅是错误，而且是导致 Run() 方法退出的此类错误(即未处理的异常)。

此外，您不能只覆盖 WebRole 中的 Run()，因为您的 RoleEntryPoint 后代与您的 Web 应用程序位于不同的应用程序域(甚至不同的进程)中(因此它不知道您的应用程序的异常)。阅读有关完整 IIS 托管和进程的更多信息 here .

因此，对于 Web 角色，您只有一个功能齐全的 IIS 7.0/7.5 的 Web 应用程序，它不知道此 IIS 是 Azure 部署的一部分。 Global.asax 是您管理 ASP.NET 中未处理的 Web 应用程序错误的地方。退房 this question ，其答案为 Application_Error() 处理程序提供了一个很好的示例。

您可以使用 RequestRecycle RoleEnvironment 类型的静态方法，以在 Application_Error() 方法中手动要求角色回收。但是不建议您这样做。由于应用程序错误，我没有看到重新启动 Web 服务器的好做法。您应该实现良好的异常处理和错误记录策略，定期检查您的错误日志并采取措施避免需要重新启动服务器的严重错误。

你的初衷是什么？了解角色何时会被自动回收，或者对您的应用程序建模，例如在出错时自动回收您的角色？如果是后者，我建议你修改你的业务需求/逻辑。

更新 2

我不能从 Neil 的嘴里说出来，但“实例失败”是导致正在运行的 VM 挂起的一切。 Windows Azure 中的实例是托管应用程序代码的单一虚拟机(阅读 this blog post 有关托管服务、角色、实例的详细说明)。您的应用程序在基于 Windows Server 的操作系统中运行。它是一个虚拟机。任何事情都可能发生 - 从主机上的硬件故障到 guest 操作系统的通用软件/驱动程序故障。不必成为您的代码。因此，万一发生会导致单个 VM 出现故障的情况 - 此问题会由 Windows Azure Fabric 自动处理。如果有必要 - 您的代码会自动部署到另一个虚拟机。这会自动发生。你什么都不做。想象一下硬盘驱动器坏了，或者内存模块烧坏了，或者网络接口(interface)停止响应——这些只是一些可能导致正在运行的虚拟机失败的简单问题。这是一个实例故障。

代码中的失败是您应该注意的事情。其他一切 - Windows Azure Fabric Controller 负责。

更新 3

1. What happens to an asp.net application in a webrole if an exception occurs and it is not handled? Will the application just hang in an undefined state ("broken") until I look for it or will it be terminated by the vm?

这个问题完全超出范围!共享主机帐户中的 asp.net 应用程序会发生什么情况？还是在本地 IIS 安装中？其操作导致崩溃的用户的应用程序崩溃。最坏的情况是应用程序池回收。我从未见过“挂起”的asp.net 应用程序。没有“终止的 asp.net 应用程序”或“损坏”这样的东西。如果是在应用程序启动或第一次请求期间引起的一般错误 - 应用程序将永远不会在线。如果它是由某些用户操作序列引起的错误 - 用户将看到一条丑陋的错误消息，仅此而已(除非您的 Global.asax 中有适当的 Application_Error() 处理程序。我认为这足以解释无关紧要的问题与 Azure。

2. Can you think of a piece of .NET code in my application that could cause the crash of a whole web role or it is not possible with managed code (apart from an unknown bug in .NET)?

你在开玩笑吗？此代码将使您的 Web 角色崩溃并强制回收:

RoleEnvironment.RequestRecycle()

请接受这个问题，因为我认为没有遗漏什么。此外，它至少还有 4 个问题的答案，添加到原来的问题。

最终版

没有“永远杀死实例”这样的东西。