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