我们正在考虑在内部使用Service Fabric，尽管我们对SF的了解还很有限，但还是完全或部分替代了基于NServiceBus构建的旧解决方案。我们喜欢NServiceBus的是开箱即用的功能，以声明性地限制具有最大线程数量的任何服务。如果我们有多种服务，而其中一项由于某些外部因素而开始出现问题，那么我们不希望其他服务受此影响。该“问题”服务将仅占用我们在其配置中为其分配的最大线程数，并且其队列将开始增长，但是由于计算机资源仍然可用，其他服务仍能正常工作。在Service Fabric中，如果我们让应用程序根据需要创建任意数量的“问题”参与者，则将导致“问题”参与者的增长失控，这将消耗所有服务器资源。
关于我如何在我描述的情况下使用SF保护我们的资源的任何想法？我的第一印象是在Service Fabric中没有实现诸如排队或参与者限制机制之类的东西，而所有这些都必须手动完成。
P.S。我认为，对于在一个应用程序内以某种方式平衡不同类型的参与者之间的资源，以减少它们在消耗资源方面彼此之间的依赖关系的能力，并不是一个罕见的需求。我简直不敢相信SF中没有为此提供任何服务。
谢谢
答案 0 :(得分：0)
我不确定您如何将NServiceBus（这是一种消息传递解决方案）与Service Fabric（一种用于构建微服务的平台）进行比较。 Service Fabric是一个支持许多不同类型的工作负载的平台。因此，它没有提供开箱即用的线程限制功能。
此外，在资源消耗方面，对于参与者或服务，您对Service Fabric会有什么期望。取决于您要做什么以及如何做出反应。我不想让SF自动杀死演员或限制服务请求。我希望能够在发生这种情况时通知我，并且这些机制可用。
也就是说，SF 确实具有一种使用指标See the docs对负载做出反应的机制：
度量标准是您的服务关心的资源，由群集中的节点提供。指标是您要管理以改善或监视服务性能的任何内容。例如，您可能会观察内存消耗，以了解服务是否过载。另一个用途是弄清楚该服务是否可以移动到内存较少受约束的其他地方，以获得更好的性能。
诸如内存，磁盘和CPU使用率之类的指标就是示例。这些指标是物理指标，即与节点上需要管理的物理资源相对应的资源。度量也可以是（并且通常是）逻辑度量。逻辑指标是“ MyWorkQueueDepth”或“ MessagesToProcess”或“ TotalRecords”之类的东西。逻辑指标是由应用程序定义的，并且间接对应于某些物理资源消耗。逻辑度量标准是常见的，因为很难按每个服务来度量和报告物理资源的消耗。测量和报告自己的物理指标的复杂性也是为什么Service Fabric提供一些默认指标的原因。
您可以定义自己的自定义指标，并使群集通过将服务移至其他节点来对这些指标做出反应。或者，您可以使用Health Reporting system发出运行状况事件，并使您的应用程序或外部流程对此采取行动。