借助Service Fabric，我们可以获得创建自定义指标和容量的工具。通过这种方式，我们可以创建资源平衡器用于在运行时执行的资源模型。我想监视和使用物理资源，如：内存，CPU和磁盘使用情况。只要我们继续使用默认负载，这样就可以正常工作。
但是对于服务/角色来说，Load不是静态的，所以我想使用内置的动态负载报告。这是我遇到问题的地方，ReportLoad在分区级别上工作。但是，分区在节点上都在同一进程中。我发现的所有监视物理资源的方法都是使用进程作为最小的度量单位，例如PerformanceCounter。如果使用这个值，可能会有多个分区报告相同的负载和一个不代表分区的负载。
所以问题是：如何在分区级别上测量资源使用情况？
答案 0 :(得分：5)
服务实例和副本不仅托管在同一进程中，而且默认情况下它们在.NET中也共享一个线程池！每次创建新的服务实例时，平台实际上只是在宿主进程内创建服务类的实例（从StatefulService或StatelessService派生的实例）。这很棒，因为它快速，便宜，而且您可以将大量服务打包到单个主机进程中，也可以打包到群集中的每个VM或计算机上。
但它也意味着资源是共享的，那么您如何知道每个分区的每个副本使用了多少？
答案是您报告虚拟资源上的负载而不是物理资源。我们的想法是，您（服务作者）可以跟踪对您的服务的一些衡量标准，并根据该信息制定指标。以下是基于物理资源的虚拟资源的简单示例：
假设您有一个Web服务。您在Web服务上运行负载测试，并确定它可以在各种硬件配置文件上处理的每秒最大请求数（使用Azure VM大小和完全虚构的数字作为示例）：
现在，在创建群集时，可以根据您使用的硬件配置文件相应地设置容量。因此，如果您有一个D2群集，每个节点将定义1000 RPS的容量。
然后，您的Web服务的每个实例（或有状态的副本）都会报告平均RPS值。这是一个虚拟资源，您可以轻松计算每个实例/副本。它对应于某些硬件配置文件，即使您没有直接报告CPU，网络，内存等。您可以将此应用于您可以衡量服务的任何内容，例如队列长度，并发用户数等。
如果您不希望将容量定义为特定于每秒请求的容量，则可以通过定义公共资源（如内存或磁盘使用情况）的物理容量来采用更通用的方法。但是你在这里真正做的是为你的服务定义可用的内存和磁盘，而不是总可用。在您的服务中，您可以跟踪每个实例/副本使用的每个容量的大小。但这不是一个总价值，它只是你所知道的东西。因此，例如，如果您跟踪存储在内存中的数据，则不一定包括运行时开销，临时堆分配等。
我在我编写的Reliable Collection包装器中有一个这种方法的例子，它通过计算字节来报告严格按照您存储的数据量加载度量：https://github.com/vturecek/metric-reliable-collections。它不报告总内存使用情况，因此您必须合理估计所需的开销并相应地定义容量，但同时不报告临时堆分配和其他瞬时内存使用情况，指标报告的内容应该更平滑，更能代表您正在存储的实际数据（例如，您不一定要仅仅因为.NET GC尚未运行而重新平衡群集）。