我们面临的问题是我们正在进行视频编码，并希望将负载分配到群集中的多个节点。
我们希望将特定节点上的视频编码作业数限制为某个最大值。我们还希望将小视频编码作业发送到群集中的某些节点组，并将长视频编码作业发送到群集中的另一组节点。
这背后的想法是通过将大型作业划分为单独的节点池来帮助维护客户端之间的公平性。这有助于确保运行长编码作业的单个租户不会阻止/限制小视频编码作业。
我们计划使用ASF服务进行视频编码。考虑到这一点，我们想到了为每个作业动态创建服务。然后可以使用放置约束来确定作业将在哪个节点池中运行。自定义指标基于内存使用情况，CPU使用情况......可用于限制节点上活动作业的数量。
使用此方法，分发作业的节点必须轮询当前是否可以创建满足放置约束和度量标准的新服务。
我们的视频编码可执行文件与服务一起打包，大约80MB。这是否会使新服务的启动需要很长时间？ （分钟与秒数）
作为替代方案，我们可以使用可靠的基于队列的系统，其中大型作业池从一个队列拉出，而小型作业池从另一个队列拉出。这似乎是更简单的方法，但我想探索所有选项，以确保我不会错过Service Fabric的一些功能。还有其他更好的建议吗？
答案 0 :(得分：1)
我没有放置约束和动态服务的经验，因此我无法与之对话。
perf计数器的轮询并不是非常昂贵，据说这不是免费操作。一秒钟的轮询间隔不应该造成任何巨大的性能影响，同时仍然提供相当程度的分辨率。
服务包在部署时被复制到每个节点，而不是在服务被启动时复制，因此它会使部署速度稍慢但不会影响服务创建。
您希望以任何方式将作业数据放入可靠的集合中，但问题是如何。我刚才有一个值得考虑的想法是将作业处理服务作为分区服务，并根据编码作业大小和/或租户来建立分区策略，以便来自同一租户的大型作业卡在同一队列中，并且更小别人的工作去其他地方。
顺便说一下，我过去处理的一件事是SF远程控制限制了发送的邮件的大小，如果它太大则抛出，所以如果你的视频文件从服务传递到服务你＆＃ 39;重新想要考虑用于服务间通信的寻呼策略。