所以，我有这个想法，我正在努力，某些节点上的服务需要根据它们可能发布的元数据在运行时动态发现其他服务。我正试图找出解决这个问题的最佳方法。
部分元数据将在运行时从本地计算机中发现，但必须将其发布到Fabric，以便其他服务可以对其做出决策。
我在ServiceManifests中看到了扩展内容。这是一个好的开始。但似乎您不能在运行时更改或添加扩展。那太好了！
想象一下我的用例。我在Fabric上有很多机器，并为它们部署了大量服务。我要宣传的是给定机器可能支持的音频编解码器。有些节点有DirectShow。因此，他们将发布可用的本地编解码器。有些机器运行32位服务，并发布他们拥有的32位DirectShow编解码器（这实际上是我需要的，因为我有一些专有的ACM编解码器，只能运行32位）。有些机器是Linux机器，并希望提供他们的GStreamer编解码器。
其中每个都需要发布关于他们可以做什么的关联元数据，以便其他服务可以从该元数据串起一个关于如何处理给定媒体文件的图表。
然后每个人都会很好地报告他们的健康状况和负载信息，因此结构可以确定如何扩展。
这些服务中的每一个都支持相同的IService接口，但每个服务仅由决定根据发布的元数据使用它们的客户端使用。
答案 0 :(得分：3)
在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
所以现在我可以做以下事情：
消费者现在对这个应用程序的看法是“是否有服务支持编解码器E？”或者“我需要与服务A，C和D交谈以处理此文件，因为它们具有我需要的编解码器。”