将元数据发布到Service Fabric [英] Publishing metadata to Service Fabric

问题描述

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

So, I have this idea I'm working on, where services on some nodes need to discover other services dynamically at runtime, based on metadata that they might publish. And I'm trying to figure out the best way to go about this.

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

Some of this metadata will be discovered from the local machine at runtime, but it then has to be published to the Fabric so that other services can make decisions on it.

我在ServiceManifests中看到了Extension的内容.这是一个好的开始.但是似乎您不能在运行时更改或添加扩展名.那就太好了！

I see the Extension stuff in the ServiceManifests. This is a good start. But it doesn't seem like you can alter or add extensions at runtime. That would be nice!

想象一下我的用例.我在Fabric上有很多机器，并向它们部署了很多服务.我要宣传的是给定机器可能支持的音频编解码器.一些节点具有DirectShow.因此，他们将发布可用的本地编解码器.一些机器正在运行32位服务，并发布它们拥有的32位DirectShow编解码器(这确实是我所需要的，因为我有一些专有的ACM编解码器只能在32位上运行).有些计算机是Linux计算机，并且希望提供其GStreamer编解码器.

Imagine my use case. I have a lot of machines on a Fabric, with a lot of services deployed to them. What I'm advertising is the audio codecs that a given machine might support. Some nodes have DirectShow. So, they would publish the local codecs available. Some machines are running 32 bit services, and publish the 32 bit DirectShow codecs they have (this is actually what I need, since I have some proprietary ACM codecs that only run in 32 bit). Some machines are Linux machines, and want to make available their GStreamer codecs.

上述每种方法都需要发布有关其功能的相关元数据，以便其他服务可以从该元数据中串起有关如何处理给定媒体文件的图表.

Each of these needs to publish the associated metadata about what they can do, so that other services can string together from that metadata a graph about how to process a given media file.

然后每个人都会很好地报告其运行状况和负载信息，以便结构可以确定如何缩放.

And then each will nicely report their health and load information, so the fabric can determine how to scale.

这些服务中的每一个都支持相同的IService接口，但是只有基于已发布的元数据决定使用它们的客户端才能使用它们.

Each of these services would support the same IService interface, but each would only be used by clients that decided to use them based on the published metadata.

推荐答案

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

In Service Fabric the way to think about this kind of problem is from a service point of view, rather than a machine point of view. In other words, what does each service in the cluster support, rather than what does each machine support. This way you can use a lot of Service Fabric's built-in service discovery and querying stuff, because the abstraction the platform provides is really about services more than it is about machines.

执行此操作的一种方法是使用放置约束和服务实例，这些实例代表群集整体支持的每个编解码器.这意味着您将拥有一个代表编解码器的服务实例，该实例仅在支持该编解码器的计算机上运行.这是一个简化的示例:

One way you can do this is with placement constraints and service instances representing each codec that the cluster supports as a whole. What that means is that you'll have an instance of a service representing a codec that only runs on machines that support that codec. Here's a simplified example:

比方说，我有一个称为"AudioProcessor"的服务类型，该服务类型使用可用的任何编解码器进行一些音频处理.

Let's say I have a Service Type called "AudioProcessor" which does some audio processing using whatever codec is available.

让我们在集群中有5个节点，其中每个节点都支持编解码器A，B，C，D和E中的一个.我将为每个节点标记一个与其​​支持的编解码器相对应的节点属性(一个节点属性可以是我想要的任何字符串).请注意，这是假设我(集群的所有者)知道每台计算机支持的编解码器.

And let's I have 5 nodes in the cluster, where each node supports one of codecs A, B, C, D, and E. I will mark each node with a node property corresponding to the codec it supports (a node property can just be any string I want). Note this assumes I, the owner of the cluster, know the codecs supported by each machine.

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

Now I can create 5 instances of the AudioProcessor Service Type, one for each codec. Because each instance gets a unique service name that is in URI format, I can create a hierarchy with the codec names in it for discovery through Service Fabric's built-in Naming Service and querying tools, e.g., "fabric:/AudioApp/Processor/A" for codec A. Then I use a placement constraint for each instance that corresponds to the node property I set on each node to ensure the codec represented by the service instance is available on the node.

这是部署所有东西时的样子:

Here's what all this looks like when everything is deployed:

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

Node 1 - Codec: A Instance: fabric/AudioApp/Processor/A

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

Node 2 - Codec: B Instance: fabric/AudioApp/Processor/B

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

Node 3 - Codec: C Instance: fabric/AudioApp/Processor/C

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

Node 4 - Codec: D Instance: fabric/AudioApp/Processor/D

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

Node 5 - Codec: E Instance: fabric/AudioApp/Processor/E

所以现在我可以做类似的事情:

So now I can do things like:

• 通过查询AudioProcessor服务实例列表并检查其名称(类似于在HTTP API中获取URI列表)来查找集群支持的所有编解码器.
• 通过以下方式将处理请求发送到支持编解码器B的服务:fabric:/AudioApp/AudioProcessor/B
• 通过添加更多支持编解码器C的机器来扩展编解码器C的处理能力-Service Fabric将自动在新节点上放置一个新的"C" AudioProcessor实例.
• 添加支持多个编解码器的计算机.通过使用其上的多个节点属性，Service Fabric将自动在其上放置正确的服务实例.

消费者现在对这个应用程序的想法是是否存在支持编解码器E的服务"?或我需要与服务A，C和D进行对话以处理此文件，因为它们具有我需要的编解码器."

The way a consumer thinks about this application now is along the lines of "is there a service that support codec E?" or "I need to talk to service A, C, and D to process this file because they have the codecs I need."

这篇关于将元数据发布到Service Fabric的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！