0

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

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

一个清楚的例子：

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

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

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

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

事件动作流

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

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

我真的很感激任何关于此事的帮助。我也完全愿意接受任何其他关于这个问题的建议，即使它完全是另一个方向。

4

1 回答 1

1

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

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

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

  • 使用队列在服务之间形成完全异步的通信。代替直接从服务 B 到 A 的通信，将出站操作排队到服务 B 中的 A。在其自己的线程中处理队列 - 不允许通信失败逃离队列处理器。您还可以将入站队列添加到服务 A 以接收来自服务 B 的出站队列的消息，从而将消息处理与网络完全隔离。这可能是最持久但也是最复杂的，因为它需要与 RPC 完全不同的架构，并且您还必须决定如何处理重复失败的消息。您可能会立即重试失败的消息，延迟后将它们发送到队列的后面，将它们发送到死信集合以进行手动处理，或者完全丢弃消息。自从你'

于 2019-03-31T18:12:34.353 回答