通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

测量每个租户的消耗

  • 项目

作为解决方案提供商，测量多租户解决方案中每个租户的使用量非常重要。 通过测量每个租户的使用量，可确保为每个租户提供服务的所售货物成本 (COGS) 可以盈利。 在此页中，我们为技术决策者提供有关使用量测量重要性的指导，以及可以考虑的租户使用量测量方法和所涉及的权衡。

有两个主要问题促使需要测量每个租户的使用量：

  • 需要测量为每个租户提供服务产生的实际成本。 这对于监视每个租户的解决方案的盈利能力很重要。
  • 使用基于使用量的定价时，需要确定向租户收取的费用。

但在多租户解决方案中测量租户使用的实际资源可能很困难。 大多数可用作多租户解决方案一部分的服务并不会根据你对租户的定义自动区分或细分使用情况。 例如，假设某项服务将所有租户的数据存储在一个关系数据库中。 就数据存储或为任何查询和请求提供服务所需的计算资源而言，很难确切确定每个租户使用该关系数据库的容量。

相比之下，对于单租户解决方案，你可以在 Azure 门户中使用 Microsoft 成本管理，从而获取此租户使用的所有 Azure 资源的完整成本明细。

因此，在面对这些挑战时，重要的是要考虑如何测量使用量。

注意

在某些情况下，在向租户提供服务时承担损失在商业上是可以接受的（例如，进入新市场或区域时）。 这是一种商业选择。 即使在这些情况下，测量每个租户的使用量仍是个好主意，这样方便规划未来。

指示性使用指标

新式应用程序（针对云构建）通常由许多不同的服务组成，每项服务都有不同的使用量测量标准。 例如，存储帐户根据存储的数据量、传输的数据和事务数来测量使用量。 相比之下，Azure App 服务消耗量由一段时间内分配的计算资源量来衡量。 如果你有一个包含存储帐户和应用服务资源的解决方案，那么将所有这些度量组合在一起来计算实际的 COGS（所售货物成本）可能是一项非常艰巨的任务。

通常，使用单个指示性度量来表示解决方案中的使用量会更容易。 例如，如果一个多租户解决方案共享一个关系数据库，则存储的数据可能是很好的指示性使用指标。

即使使用租户存储的数据量作为指示性使用度量值，它也可能不是每个租户的真实使用量。 如果特定租户从解决方案中读取或运行更多报告，但不会写入大量数据，则该租户可以使用比存储要求指示的计算多得多。

提示

有时，应该测量和查看租户的实际消耗量，以创建基线模型。 此模型可帮助你确定你对指示性指标的假设是否正确。

事务度量值

测量使用量的另一种方法是确定代表解决方案 COGS 的关键事务。 例如，在文档管理解决方案中，它可能是创建的文档数。 如果系统中有核心功能是事务性的，并且可以轻松测量，这就很有用。

此方法通常很容易实现且具有成本效益，因为应用程序中通常只有一个点需要记录发生的事务数。

按请求度量的指标

在主要基于 API 的解决方案中，使用基于对解决方案发出的 API 请求数的消耗指标可能很有意义。 这通常很容易实现，但它确实需要你使用 API 作为系统的主要接口。 由于需要记录请求利用率（出于审核和计费目的），实现按请求度量的指标会增加运营成本，特别是对于大批量服务而言。

由单页应用程序 (SPA) 或使用 API 的移动应用程序组成的面向用户的解决方案可能不适合使用按请求度量的指标。 这是因为最终用户对应用程序的使用和 API 的使用量之间的关系知之甚少。 应用程序活跃与否（它发出许多或过少 API 请求），用户不会注意到差异。 但是，如果只需要大致了解每个租户的使用情况，它可能仍然是一个合理的选择。

警告

请确保将请求指标存储在出于此目的而设计的可靠数据存储中。 例如，虽然 Azure Application Insights 可以跟踪请求，甚至可以跟踪租户 ID（通过使用属性），但 Application Insights 并非旨在存储每条遥测数据。 它会移除数据，这是其采样行为的一部分。 出于计费和计量目的，请选择一个可以提供高度准确性的数据存储。

估计使用量

测量租户的使用量时，提供对租户使用量的估计值或许更容易些，而不是尝试计算确切的使用量。 例如，对于在一个部署中为数千个租户提供服务的多租户解决方案，可以合理预估为租户提供服务的成本仅为 Azure 资源成本的百分之几。

在以下情况中，你可能会考虑估算租户的 COGS：

  • 未使用基于使用量的定价。
  • 无论大小如何，每个租户的使用情况模式和成本都是相似的。
  • 每个租户在部署中使用的资源占总资源的百分比很低（例如，<2%）。
  • 每个租户的成本较低。

你还可以选择将指示性使用指标、事务指标或按请求度量的指标结合使用来估算使用量。 例如，对于主要管理文档的应用程序，租户用于存储其文档的总体存储百分比与实际的 COGS 足够接近。 测量 COGS 很困难或使应用程序变得过于复杂时，这或许是一种有用的方法。

收取费用

在某些解决方案中，可以向客户收取其租户资源的 COGS。 例如，可以使用 Azure 资源标记将可计费的 Azure 资源分配给租户。 然后，可以确定专用于每个租户的资源集成本，以及运营利润率。

注意

某些 Azure 服务不支持标记。 对于这些服务，需要根据其他特征（如资源名称、资源组或订阅）将成本归因于租户。

Azure 成本分析可用于分析使用标记、资源组或订阅来归属成本的单租户解决方案的 Azure 资源成本。

但这在大多数新式多租户解决方案中会异常复杂，因为准确确定为单个租户提供服务产生的确切 COGS 是一项挑战。 此方法仅适用于非常简单的解决方案、具有单租户资源部署的解决方案或大型解决方案中特定于自定义租户的附加功能。

某些 Azure 服务提供的功能支持在多租户环境中使用其他方法来归属成本。 例如，Azure Kubernetes 服务支持多个节点池，其中为每个租户分配一个带有节点池标记的节点池，这些标记用于归属成本。

作者

本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。

首席作者：

其他参与者：

若要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。

后续步骤

请考虑将使用的更新部署模型。