在 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 交谈以处理此文件,因为他们有我需要的编解码器。”