在测量和分配成本以及优化成本时，通常需要特别考虑多租户解决方案。 在此页面上，我们描述了一些关键指南，供解决方案架构师考虑多租户应用程序的成本测量、分配和优化。
关键考虑因素和要求
请考虑你对于测量解决方案的消耗量方面的要求。 在测量每个租户的消耗量中更详细讨论了这一方面。
测量的目的
决定具体的目标是非常重要的。 下面是目标的示例：
- 计算每个租户的大致销售商品成本。 例如，如果你部署了大量共享资源，你可能只对每个租户产生的成本的粗略近似值感兴趣。
- 计算每个租户产生的确切成本。 例如，如果按照租户产生的确切消耗量向租户收取费用，则需要获得有关每个租户的资源成本的准确信息。
- 确定成本明显高于其他租户的离群值租户。 例如，如果提供统一费率定价模型，则可能需要确定是否有任何租户消耗了不成比例的预配容量，以便可以应用合理使用策略。 在许多情况下，此用例不需要精确测量成本。
- 降低解决方案的总体 Azure 成本。 例如，您可能希望查看每个组件的成本，然后确定是否为工作负载进行了过度预配。
通过了解租户测量消耗的目标，可以确定成本分配方法需要是近似的还是高度精确的，这会影响可以使用的特定工具以及可以遵循的做法。
共享组件
通过将租户移动到共享基础结构，可以降低多租户解决方案的成本。 但是，你需要仔细考虑共享资源的影响，例如，你的租户是否会开始遇到吵闹邻居问题。
还需要考虑度量和分配共享组件成本的方式。 例如，可以在使用共享组件的每个租户之间平均分配成本。 或者，可以计量每个租户的使用情况，以更精确地测量其共享组件的使用情况。
要考虑的方法和模式
使用资源标记分配成本
Azure 使你能够将标记应用于资源。 标签是一种键值对。 使用标记来添加自定义元数据。 标记对于许多管理操作很有用，并且可以用于分析 Azure 消耗的成本。 应用标记后，可以确定与每个标记关联的成本。
在多租户解决方案中使用标记的方式可能会有所不同，具体取决于你的体系结构。
在某些解决方案中，你可以为每个租户部署专用资源，例如，为每个租户部署专用部署缩放单元。 在这些情况下，显然这些资源的任何 Azure 消耗都应分配给该租户，因此可以使用租户 ID 来标记 Azure 资源。
在其他情况下，你可能有一组共享资源。 例如，在应用分片模式时，可以部署多个数据库并将租户分布在这些数据库中。 请考虑对租户的组使用带有标识符的资源。 采用这种方法，可能无法轻松地将成本分配给单个租户，但至少可以将成本缩小到一组租户。 如果你注意到特定分片的成本高于其他分片，则还可以使用消耗信息来帮助跨分片重新平衡租户。
注意
针对可应用于资源的标记数量有限制。 使用共享资源时，最好不要为共享资源的每个租户添加标记。 相反，请考虑添加具有分片 ID 的标记，或者以其他方式标识租户组。
请考虑使用部署标记模式和垂直分区租户模型构建的示例多租户解决方案。 每个部署缩放单元都包括一个共享 Web 服务器和分片数据库。 标记可以应用于每个 Azure 组件，如下图所示。
此处采用的标记策略如下：
- 每个资源都有一个
stamp-id标记。 - 每个分片数据库都有一个
shard-id标记。 - 专用于特定租户的每个资源都有一个
tenant-id标记。
使用此标记策略，可以轻松地将成本信息筛选为单个缩放单元。 还很容易找到特定于租户的资源的成本，例如租户 C 的数据库总成本。共享组件没有 tenant-id 标记，但缩放单元的共享组件的成本可以在分配使用该缩放单元或分片的租户之间分配。
检测应用程序
如果 Azure 资源和租户之间没有直接关系，请考虑检测应用程序以收集遥测数据。
你的应用层可能已经收集了有助于回答有关计量问题的日志和指标，例如：
- 大约每个租户发出多少个 API 请求？
- 特定租户在一天中的什么时间最忙？
- 租户 A 的使用模式与租户 B 的使用模式相比有什么区别？
在 Azure 中，这些指标通常由 Application Insights 捕获。 通过使用遥测初始值设定项，你可以扩充 Application Insights 捕获的遥测数据，以包含租户标识符或其他自定义数据。
但是， Application Insights 和其他日志记录和监视解决方案不适用于精确的成本测量或计量目的。 应用程序见解旨在对数据进行采样，尤其是在应用程序具有大量请求时。 采样旨在降低监视解决方案的成本，因为捕获每个遥测数据的成本通常变得昂贵。
如果需要出于计费目的跟踪有关消耗或使用量的精确详细信息，则应改为生成自定义管道来记录必要的数据。 然后，应根据你的需求来聚合数据。 可用于此目的的 Azure 服务包括事件中心（用于捕获大量遥测数据）和流分析（用于实时处理遥测数据）。
使用 Azure 预留和 Azure 节省计划来降低成本
Azure 预留：借助 Azure 预留，你可以通过预先承诺一定程度的支出来降低 Azure 成本。 预留适用于许多 Azure 资源类型。
可以在多租户解决方案中有效地使用预留。 请注意以下事项：
- 部署包含共享资源的多租户解决方案时，请考虑工作负载所需的基线消耗级别。 可以考虑为该基准消耗量预留，然后在不可预测的峰值期间为更高的消耗量支付标准费率。
- 为每个租户部署资源时，请考虑是否可以预先承诺特定租户的资源消耗，或是可以跨租户组合预先承诺资源消耗。
使用 Azure 预留，可以将限定预留的范围以应用于某一资源组、某一订阅或一组订阅。 这意味着您可以利用预留，即使你跨多个订阅对工作负载进行分片也是如此。
预留范围在租户具有不可预测的工作负载时也很有用。 例如，考虑一个解决方案，其中租户 A 只需要特定资源的一个实例，但租户 B 和租户 C 各需要两个实例。 租户 B 后来的忙碌程度降低，因此你减少了实例数，租户 A 的忙碌程度增加，因此你增加了实例数。 你的预留将应用于需要它们的租户。
适用于计算的 Azure 节省计划：适用于计算的 Azure 节省计划是一种灵活的成本节省计划，与即用即付价格相比，可实现显著节省。 你同意签订为期一年或三年的合同，并获得符合条件的计算服务的折扣。 这些服务包括虚拟机、专用主机、容器实例、Azure Premium Functions 和 Azure 应用服务。 无论区域、实例大小或操作系统如何，这些计算服务都会节省成本。 有关详细信息，请参阅 Azure 节省计划概述和 Azure 节省计划文档。
结合使用预留与节省计划：若要进一步优化成本和灵活性，可以将 Azure 节省计划与 Azure 预留结合使用。
要避免的反模式
- 根本不跟踪成本。 请务必至少大致了解要产生的成本，以及每个租户如何影响交付解决方案的成本。 否则，如果成本随时间而变化，则没有基线可供比较。 你还可能无法预测租户的增长将会如何影响成本和盈利能力。
- 做出假设或猜测。 确保您的成本衡量是基于真实信息。 可能不需要高度精确，但即使是估计值也应该通过实际测量来获知。
- 不必要的精度。 可能不需要对每个租户产生的每个成本进行详细核算。 构建不必要的精确成本测量和优化流程可能会适得其反，因为这会增加工程复杂性并导致流程变得脆弱。
- 实时测量。 大多数解决方案不需要最新的成本测量。 由于计量和消耗数据的处理可能很复杂，因此应记录必要的数据，然后以异步聚合和处理数据。
- 使用监视工具进行计费。 如检测应用程序中所述，请确保使用为成本监视和计量而设计的工具。 应用程序监视解决方案通常不适合此类数据，尤其是在需要高精度时。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
主要作者：
- John Downs | FastTrack for Azure 首席客户工程师
其他参与者：
- Sherri Babylon | FastTrack for Azure 高级客户工程师
- 阿森·弗拉基米尔斯基|首席工程师，FastTrack for Azure
若要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。