所以，我有一个正在研究的想法，某些节点上的服务需要在运行时根据它们可能发布的元数据动态发现其他服务。我正在努力找出解决这个问题的最佳方法。
其中一些元数据将在运行时从本地计算机中发现，但随后必须将其发布到 Fabric，以便其他服务可以对其做出决策。
我在 ServiceManifests 中看到了扩展内容。这是一个好的开始。但似乎您无法在运行时更改或添加扩展。那就太好了!
想象一下我的用例。我在 Fabric 上有很多机器，并且部署了很多服务。我所宣传的是给定机器可能支持的音频编解码器。某些节点具有 DirectShow。因此，他们会发布可用的本地编解码器。有些机器正在运行 32 位服务，并发布它们拥有的 32 位 DirectShow 编解码器(这实际上是我所需要的，因为我有一些仅在 32 位中运行的专有 ACM 编解码器)。有些机器是 Linux 机器，并且希望提供其 GStreamer 编解码器。
其中每一个都需要发布有关它们可以做什么的关联元数据，以便其他服务可以从该元数据中将有关如何处理给定媒体文件的图表串在一起。
然后每个都会很好地报告它们的运行状况和负载信息，以便结构可以确定如何扩展。
这些服务中的每一个都将支持相同的 IService 接口(interface)，但每个服务只能由根据已发布的元数据决定使用它们的客户端使用。
最佳答案
在Service Fabric中，思考此类问题的方式是从服务的角度，而不是从机器的角度。换句话说，集群中的每个服务支持什么，而不是每个机器支持什么。这样，您就可以使用 Service Fabric 的许多内置服务发现和查询功能，因为该平台提供的抽象实际上更多的是关于服务，而不是关于机器。
实现此目的的一种方法是使用位置约束和表示集群作为整体支持的每个编解码器的服务实例。这意味着您将拥有一个代表编解码器的服务实例，该实例仅在支持该编解码器的计算机上运行。这是一个简化的示例:
假设我有一个名为“AudioProcessor”的服务类型，它使用任何可用的编解码器进行一些音频处理。
让我们在集群中有 5 个节点，其中每个节点都支持编解码器 A、B、C、D 和 E 之一。我将使用与其支持的编解码器相对应的节点属性来标记每个节点(一个节点属性可以是我想要的任何字符串)。请注意，这假设我(集群的所有者)知道每台机器支持的编解码器。
现在我可以创建 5 个 AudioProcessor 服务类型实例，每个编解码器一个实例。由于每个实例都有一个 URI 格式的唯一服务名称，因此我可以创建一个包含编解码器名称的层次结构，以便通过 Service Fabric 的内置命名服务和查询工具进行发现，例如“fabric:/AudioApp/Processor/A ”对于编解码器 A。然后，我对每个实例使用与我在每个节点上设置的节点属性相对应的放置约束，以确保服务实例表示的编解码器在该节点上可用。
以下是部署所有内容后的样子:
节点 1 - 编解码器:实例: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 向支持编解码器 B 的服务发送处理请求
- 通过添加更多支持编解码器 C 的计算机来扩展编解码器 C 的处理能力 - Service Fabric 会自动在新节点上放置一个新的“C”AudioProcessor 实例。
- 添加支持多种编解码器的计算机。使用其上的多个节点属性，Service Fabric 将自动在其上放置正确的服务实例。
消费者现在对该应用程序的看法是“是否有支持编解码器 E 的服务？”或“我需要与服务 A、C 和 D 通信来处理此文件，因为它们具有我需要的编解码器。”
关于azure-service-fabric - 将元数据发布到 Service Fabric，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/34456775/