Service Fabric 未处理的异常和最佳做法

Posted 2023-02-23

【中文标题】Service Fabric 未处理的异常和最佳做法

【英文标题】：Service Fabric Unhandled Exceptions and best practices

【发布时间】：2016-12-07 01:31:55

【问题描述】：

只是好奇是否有人对 Service Fabric 中未处理的异常有过经验，以及围绕它们的最佳实践是什么。主要是对服务的故障状态感到好奇。如果服务处于故障状态，它们会被回收吗？或者是否应该对未处理的异常进行全局异常处理，如果该概念甚至存在于 SF 中。我在这个主题上搜索的内容不多。

【参考方案1】：

在我的公司，我们在guidelines for using ITransaction 之后构建了一些可重复使用的代码，它允许我们运行任意代码并使用适当的异常处理和重试策略对其进行包装。在该文档中，有关于各种类型的异常应如何影响RunAsync 方法以及它们应如何影响作为远程端点一部分的方法的指南。

通常，文档中讨论的任何异常的处理都由您决定。就我自己而言，我只会让异常冒泡，如果出现意外异常则让服务失败。应始终使用适当的重试策略来处理预期的异常。

【参考方案2】：

您的问题范围很广，答案会根据微服务的类型而有所不同。一个好的开始点，也了解这个主题的广泛性，是查看Service Fabric health monitoring 文章和相关的子主题。如您所见，有很多配置选择，根据我的经验（我是 Microsoft Azure 架构师），没有灵丹妙药，也没有“一刀切”的解决方案。唯一的最佳实践是设计最适合您的项目的异常管理，尽可能利用 Fabric 健康政策。

【讨论】：

好吧，可靠服务的故障状态（我应该提到）并不是一个广泛的问题。不同的服务以不同的方式处理故障状态。我只是好奇无状态可靠服务如何处理故障状态。看来，在 runasync 期间发生的任何导致故障状态的故障都会导致 SF 最终回收服务。虽然真的很少有人谈论这个。

@g.t.w.d 我认为这个主题很少见的原因是因为两个交叉领域有很多：（1）服务结构健康和（2）可靠的服务状态。两者通过在服务中使用 System.Fabric.Health 相交，以允许 Fabric 健康监视器对服务状态管理在 Fabric 中引发的事件采取行动。