Azure 雲實例在哪種類型的異常/崩潰之後執行重新啟動？
據我記得，角色實例應該在崩潰/失敗後自動執行重啟。為了測試這種行為，我編寫了一個應用程序來強制執行記憶體不足異常並且我的應用程序崩潰了。角色實例沒有執行重新啟動，因為它仍在執行並且正常 - 實例只是重新啟動 .NET 執行時。
我試圖找出實例對不同錯誤的反應。就我而言，不需要重新啟動。什麼類型的錯誤/異常（我可以強制執行）會導致實例完全重啟？什麼類型的錯誤/異常會永遠殺死一個實例？
導致角色實例被回收（重新啟動）的唯一原因是RoleEntryPoint的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 託管和程序的更多資訊。
因此，對於 Web 角色，您只需擁有一個具有 IIS 7.0 / 7.5 功能的 Web 應用程序，它不知道此 IIS 是 Azure 部署的一部分。Global.asax 是您管理 ASP.NET 中未處理的 Web 應用程序錯誤的地方。查看這個問題，其答案為 Application_Error() 處理程序提供了一個很好的範例。
您可以使用 RoleEnvironment 類型的RequestRecycle靜態方法在 Application_Error() 方法中手動要求角色回收。但是不建議您這樣做。由於應用程序錯誤，我沒有看到重新啟動 Web 伺服器的好習慣。您應該實施良好的異常處理和錯誤記錄策略，定期檢查您的錯誤日誌並採取措施避免需要重新啟動伺服器的嚴重錯誤。
你的初衷是什麼？要了解角色何時會被自動回收，或者為您的應用程序建模，例如在錯誤時自動回收您的角色？如果是後者，我建議您修改您的業務需求/邏輯。
更新 2
我不能從 Neil 的口中說出來，但“實例故障”是可能導致正在執行的 VM 掛起的所有內容。Windows Azure 中的實例是託管應用程式碼的單一虛擬機（閱讀此部落格文章有關託管服務、角色、實例的詳細說明）。您的應用程序在基於 Windows Server 的作業系統中執行。它是一個虛擬機。任何事情都可能發生——從主機上的硬體故障到客戶作業系統的通用軟體/驅動程序故障。不必成為您的程式碼。因此，如果發生會導致單個 VM 失敗的事情 - 此問題將由 Windows Azure Fabric 自動處理。如果有必要 - 您的程式碼會自動部署到另一個虛擬機。這是自動發生的。你什麼都不做。想像一下 HDD 損壞、記憶體模組燒毀或網路介面停止響應 - 這些只是可能導致正在執行的 VM 失敗的幾個簡單問題。這是一個實例失敗。
您應該注意程式碼中的故障。其他一切 - Windows Azure Fabric 控制器負責處理。
更新 3
- 如果發生異常並且未處理，webrole 中的 asp.net 應用程序會發生什麼？在我尋找它之前，應用程序會一直處於未定義狀態（“損壞”），還是會被 vm 終止？
這個問題完全超出範圍！共享主機帳戶中的 asp.net 應用程序會發生什麼？還是在本地 IIS 安裝中？其操作導致崩潰的使用者的應用程序崩潰。最壞情況下的應用程序池回收。我從未見過“掛起”的 asp.net 應用程序。沒有“終止的 asp.net 應用程序”或“損壞”之類的東西。如果它是在應用程序啟動或第一次請求期間引起的一般錯誤 - 應用程序將永遠不會線上。如果它是由某些使用者操作序列引起的錯誤 - 使用者將看到一條醜陋的錯誤消息，僅此而已（除非您的 Global.asax 中有適當的 Application_Error() 處理程序。我認為這足以解釋一個無關緊要的問題與 Azure。
- 您能想到我的應用程序中的一段 .NET 程式碼可能導致整個 Web 角色崩潰，或者託管程式碼不可能（除了 .NET 中的未知錯誤）？
你在開玩笑嗎？此程式碼將使您的網路角色崩潰並強制回收：
RoleEnvironment.RequestRecycle()請接受這個問題，因為我認為沒有遺漏什麼。此外，它還回答了至少 4 個問題，添加到原始問題中。
最後
沒有“永遠殺死實例”這樣的事情。