2

因此，我有一个正在研究的想法，即某些节点上的服务需要在运行时根据它们可能发布的元数据动态地发现其他服务。我正在尝试找出解决此问题的最佳方法。

其中一些元数据将在运行时从本地机器中发现，但随后必须将其发布到 Fabric，以便其他服务可以对其做出决策。

我在 ServiceManifests 中看到了扩展内容。这是一个好的开始。但是您似乎无法在运行时更改或添加扩展。那样就好了！

想象一下我的用例。我在 Fabric 上有很多机器，并为它们部署了很多服务。我要宣传的是给定机器可能支持的音频编解码器。一些节点有 DirectShow。因此，他们将发布可用的本地编解码器。一些机器运行 32 位服务，并发布他们拥有的 32 位 DirectShow 编解码器（这实际上是我需要的，因为我有一些仅在 32 位中运行的专有 ACM 编解码器）。有些机器是 Linux 机器，并希望提供其 GStreamer 编解码器。

这些中的每一个都需要发布有关它们可以做什么的相关元数据，以便其他服务可以从该元数据中串起一个关于如何处理给定媒体文件的图表。

然后每个人都会很好地报告他们的健康和负载信息，因此结构可以确定如何扩展。

这些服务中的每一个都将支持相同的 IService 接口，但每个服务只能由根据发布的元数据决定使用它们的客户端使用。

4

1 回答 1

4

在 Service Fabric 中，考虑此类问题的方式是从服务的角度，而不是机器的角度。换句话说，集群中的每个服务都支持什么，而不是每台机器支持什么。通过这种方式，您可以使用大量 Service Fabric 的内置服务发现和查询功能，因为平台提供的抽象实际上是关于服务的，而不是关于机器的。

可以做到这一点的一种方法是使用放置约束和服务实例来表示集群作为一个整体支持的每个编解码器。这意味着您将拥有一个代表编解码器的服务实例，该编解码器仅在支持该编解码器的机器上运行。这是一个简化的示例：

假设我有一个名为“AudioProcessor”的服务类型，它使用任何可用的编解码器进行一些音频处理。

让我们在集群中有 5 个节点，其中每个节点支持编解码器 A、B、C、D 和 E 之一。我将使用与它支持的编解码器相对应的节点属性标记每个节点（节点属性可以只是我想要的任何字符串）。请注意，这假设我，集群的所有者，知道每台机器支持的编解码器。

现在我可以创建 5 个 AudioProcessor 服务类型实例，每个编解码器一个。因为每个实例都有一个 URI 格式的唯一服务名称，所以我可以创建一个包含编解码器名称的层次结构，以便通过 Service Fabric 的内置命名服务和查询工具进行发现，例如“fabric:/AudioApp/Processor/A " 对于编解码器 A。然后我为每个实例使用与我在每个节点上设置的节点属性相对应的放置约束，以确保服务实例表示的编解码器在节点上可用。

这是部署所有内容后的所有内容：

节点 1 - 编解码器：A 实例：fabric/AudioApp/Processor/A

节点 2 - 编解码器：B 实例：fabric/AudioApp/Processor/B

节点 3 - 编解码器：C 实例：fabric/AudioApp/Processor/C

节点 4 - 编解码器：D 实例：fabric/AudioApp/Processor/D

节点 5 - 编解码器：E 实例：fabric/AudioApp/Processor/E

所以现在我可以做这样的事情：

  • 通过查询 AudioProcessor 服务实例列表并检查它们的名称来查找集群支持的所有编解码器（类似于在 HTTP API 中获取 URI 列表）。
  • 通过解析fabric:/AudioApp/AudioProcessor/B向支持codec B的服务发送处理请求
  • 通过添加更多支持编解码器 C 的机器来扩展编解码器 C 的处理能力 - Service Fabric 将自动在新节点上放置一个新的“C”AudioProcessor 实例。
  • 添加支持多个编解码器的机器。在其上使用多个节点属性，Service Fabric 将自动在其上放置正确的服务实例。

消费者现在对这个应用程序的看法是“有支持编解码器 E的服务吗？” 或“我需要与服务 A、C 和 D 交谈以处理此文件，因为他们有我需要的编解码器。”

于 2015-12-28T23:37:14.110 回答