当应用程序处于错误状态时，我想实现以下恢复尝试：
- 重新启动应用程序本身
- 重新启动基础 VM
- 重新生成底层虚拟机
使用云服务，调用Environment.FailFast并自动触发上述序列就足够了。
如何使用 Service Fabric 实现相同的目标？目前，它用作 VM 规模集顶部的部署/维护层(每个 VM 一个应用实例(。
更新：无法使用 Service Fabric 执行此操作。对于我们的服务，我们决定直接在 VM 规模集之上生成它。希望我们能看到云服务 v2 构建在 VM 规模集之上，这将负责部署/维护。
ServiceFabric 具有用于重启失败应用的内置机制，但 Service Fabric 不了解什么是"错误状态"。如果应用程序失败并且进程关闭，SF 将重新启动它几次，直到它放弃并将应用程序视为已损坏并阻止重新启动。
如果它不时发生，例如，每周几次，它不会有任何问题，因为对于它将连续失败视为同一问题的一部分的时间有一个阈值。
当您说"错误状态">时，每个应用程序可能具有不同的错误状态概念，因此除非应用程序通过运行状况事件报告它，否则无法 SF 识别它。
例：
应用程序- 可能消耗了太多内存(内存泄漏(，您唯一能做的就是限制应用程序内存设置一个限制，SF不知道这是泄漏，也许是应用程序设计的内存消耗部分。
- 另一个问题是，由于配置无效或依赖服务而返回错误响应的 API 已关闭。如果错误是由于应用程序故障或服务设计造成的，则 Service Fabric 不会结结。
在这些情况下，您必须实现一种机制来告知 SF 这些错误不是预期的，SF 将为您处理故障转移。您可以将其实现为：
- 作为应用程序的一部分，它将发出自己的运行状况报告
- 在群集中运行的监视器应用，监视服务事件或代表其他服务记录和发出事件。
对于第一种方法，将其报告为发生故障的快速方法是使用 ReportFault：
使副本能够向运行时报告故障并指示 它遇到了无法恢复的错误，必须 重新启动或删除。
有关其他运行状况报告的详细信息，请查看此文档：Service Fabric 运行状况报告
对于您问题的第 2 项和第 3 项， 有一种机制可以识别节点在集群中不可用时，它会被降级，SF 会暂时将其从 RING 中删除。常见问题是当网络问题阻止节点相互通信时，在某些情况下，内存不足可能会影响 SF 主机管理器，它开始失败，响应缓慢，然后 SF 将从可用节点列表中删除该节点，直到它恢复正常。
我不知道SF中有什么东西会重新启动VM，可能是由于前面所说的相同原因，它会在SF资源管理器中引发失败以通知该问题，您必须处理它。
可以创建一个解决方案，作为上述监视器方法的一部分，Disable-ServiceFabricNode从节点移动任何正常服务，然后可以使用 Azure SDK 重启基础 VM。