管理来宾可执行文件依赖项 - 本地 Service Fabric

Posted 2023-03-27

【中文标题】管理来宾可执行文件依赖项 - 本地 Service Fabric

【英文标题】：Managing guest executables dependencies - On premise Service Fabric

【发布时间】：2019-08-16 12:41:47

【问题描述】：

我们最近决定开始使用本地 Service Fabric，但遇到了“依赖”问题。

我们有几个客户可执行文件，它们之间存在依赖关系，如果不重新启动它们所依赖的服务，则无法从它们所依赖的服务重新启动中恢复。

一个清楚的例子：

在下图中，服务 B 依赖于服务 A。 如果服务 A 遇到意外错误并重新启动，服务 B 将进入“错误”状态（不会报告给结构）。这意味着服务 B 将报告一个正常的健康状态，尽管它处于错误状态。

我们正在考虑围绕这些方面的解决方案：

提出一个独立的服务来监控集群中所有副本/分区/应用程序的健康状态事件，并包含整个依赖树。

当一个服务的健康状态发生变化时，它会重新启动它的直接依赖，这会导致事件的多米诺骨牌效应->重新启动，直到整个子树被重置（如下面的事件->动作流程图所示）。

问题是 healthReport 事件不会在很短的时间间隔内发送（这意味着我的整个系统无法工作，我几分钟内都不知道）。我会监控健康状态，但我确实需要了解历史记录（即使状态现在是健康的，也不意味着它之前没有处于错误状态）。

另一个问题是事件可以在任何服务级别（副本/分区）弹出，这需要我汇总所有事件。

我非常感谢您对此事的任何帮助。我也完全愿意接受任何其他关于这个问题的建议，即使它是完全不同的方向。

【问题讨论】：

当您提到“healthReport”时，您是指向 Service Fabric 报告副本状态吗？

@OlegKarasik 是的，通过健康报告得到报告

【参考方案1】：

通常可以通过在服务之间的通信边界引入容错来避免服务中的级联故障。实现这一目标的一些策略：

对失败的操作引入重试，中间有延迟。延迟之间的时间可能会成倍增长。如果您当前在服务之间进行大量远程过程调用 (RPC) 风格的通信，这是一个容易实现的选项。如果您的依赖服务不需要太长时间重新启动，这可能会非常有效。 Polly 是一个著名的用于实现重试的库。

使用断路器关闭与失败服务的通信。在这个比喻中，两个正常通信的服务之间形成了一个闭路。断路器监视通信。如果它检测到一些失败的通信，它会“打开”电路，导致任何进一步的通信立即失败。然后，断路器会定期向失败的服务发送查询以检查其运行状况，并在失败的服务开始运行时关闭电路。这比重试策略涉及更多一点，因为您负责防止开路使您的服务崩溃，并且还负责决定什么构成健康服务。 Polly 还支持断路器

使用队列在服务之间形成完全异步的通信。不是直接从服务 B 与 A 通信，而是在服务 B 中将出站操作排队到 A。在其自己的线程中处理队列 - 不允许通信失败逃离队列处理器。您还可以将入站队列添加到服务 A 以接收来自服务 B 的出站队列的消息，从而将消息处理与网络完全隔离。这可能是最持久但也是最复杂的，因为它需要与 RPC 非常不同的架构，并且您还必须决定如何处理反复失败的消息。您可能会立即重试失败的消息，延迟后将它们发送到队列的后面，将它们发送到死信集合以进行手动处理，或者完全丢弃消息。由于您使用的是来宾可执行文件，因此您没有可靠的集合来帮助完成此过程，因此如果您决定采用这种方式，像 RabbitMQ 这样的第三方解决方案可能会很有用。

【讨论】：

不幸的是，修复来宾可执行文件不是一种选择。

您的来宾可执行文件的 API 表面有多大？您是否可以通过编写另一个将调用路由到来宾可执行文件的服务来包装它们？你可以在那里注入容错。

这是其中一种选择，但后来我们得到了一个令人恶心的三重包装器。