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

多租户解决方案的定价模型

一个好的定价模型可确保在租户数量增长和添加新功能时保持盈利。 开发商业多租户解决方案时，一个重要考虑因素是如何为产品设计定价模型。 在此页上，我们将为技术决策者提供有关你可以考虑的定价模型和相关利弊权衡的指导。

确定产品的定价模型时，需要平衡客户的价值回报 (ROV) 与提供服务所需的所售货物成本 (COGS)。 提供更灵活的商业模型（针对解决方案）可能会增加客户的 ROV，但也可能会增加解决方案的体系结构和商业复杂性，从而增加你的 COGS。

为解决方案开发定价模型时，应考虑的一些重要因素如下：

• COGS 是否高于你从解决方案中获得的利润？
• COGS 能否根据用户的增长或使用模式的变化随时间而变化？
• 测量和记录操作定价模型所需的信息有多难？ 例如，如果你计划根据客户进行的 API 调用次数来计费，是否已确定如何测量每个客户进行的 API 调用次数？
• 你的盈利能力是否取决于确保客户以有限的方式使用你的解决方案？
• 如果客户过度使用解决方案，这是否意味着你不再盈利？

有一些关键因素会影响你的盈利能力：

• Azure 服务定价模型。 构成解决方案的 Azure 或第三方服务的定价模型可能会影响哪些模型可盈利。
• 服务使用模式。 用户可能只需要在工作时间访问你的解决方案，或者可能只有一小部分高容量用户。 当使用率较低时，能否通过减少未使用的容量来降低 COGS？
• 存储增长。 大多数解决方案会随时间推移累积数据。 数据越多，就意味着存储和保护数据的成本越高，从而降低了每个租户的盈利能力。 能否设置存储配额或强制实施数据保留期？
• 租户隔离。 所用租户模型会影响租户之间的隔离级别。 如果共享资源，是否需要考虑租户可能会过度使用或滥用服务的情况？ 租户隔离级别对每个人的 COGS 和性能有何影响？ 如果未针对资源分配实施额外控制，一些定价模型就无法盈利。 例如，若要让统一费率定价模型具有可持续性，你可能需要实施服务限制。
• 租户生命周期。 例如，客户流失率较高的解决方案或需要更多入职培训工作的服务的盈利能力可能较低，尤其是在使用基于消耗的模型定价时。
• 服务级别要求。 需要更高级别的服务的租户可能意味着你的解决方案不再盈利。 你必须清楚客户的服务级别期望和你需要承担的所有义务，这样才能相应地规划定价模型。

常见定价模型

有许多常见的定价模型通常可用于多租户解决方案。 其中每个定价模型都有相关的商业优势和风险，并且需要额外考虑体系结构问题。 了解这些定价模型之间的差异非常重要，这样才能确保解决方案在发展过程中保持盈利。

注意

你可以为解决方案提供多个模型或将模型组合在一起。 例如，可以为用户数量相当稳定的客户提供每用户模型，也可以为使用模式波动的客户提供消耗模型。

基于消耗的定价

消耗模型有时称为即用即付或 PAYG。 随着服务使用量的增加，你的收入也会增加：

测量消耗时，可以考虑一些简单的因素，例如添加到解决方案的数据量。 或者，可以考虑将使用属性组合在一起。 消耗模型具备许多优势，但它们可能难以在多租户解决方案中实现。

优势：从客户的角度来看，使用你的解决方案所需的前期投资极少，因此该模型的进入门槛较低。 从你（服务运营商）的角度来看，你的托管和管理成本会随着客户使用量和你的收入的增加而增加。 这种增加会使其成为一个高度可缩放的定价模型。 当解决方案中使用的 Azure 服务也基于消耗时，消耗定价模型尤其适用。

复杂性和运营成本：消耗模型依赖于对使用量的准确测量以及按租户拆分此使用量。 这很有挑战性，尤其是在具有许多分布式组件的解决方案中。 你需要保留计费和审核的详细消耗记录，并为客户提供访问其消耗数据的方法。

风险：消耗定价会促使客户减少对系统的使用，以降低成本。 此外，消耗模型还会导致不可预测的收入流。 你可以通过提供产能预留来缓解此问题，即，客户预先支付一定程度的消耗费用。 作为服务提供商，你可以将这笔收入用于投资解决方案的改进、降低运营成本或通过添加功能来增加价值回报。

注意

实施和支持产能预留可能会增加应用程序中计费流程的复杂性。 你可能还需要考虑客户如何获得退款或交换其产能预留，这些流程也会增加商业和运营挑战。

每用户定价

每用户定价模型涉及根据使用服务的人数向客户收费，如下图所示。

每用户定价模型非常常见，因为它们在多租户解决方案中实现起来很简单。 但是，它们存在一些商业风险。

优势：针对每个用户向客户收费时，可以轻松计算和预测收入流。 此外，假设为每个用户采用相当一致的使用模式，那么收入的增长速率将与服务的采用速率相同，从而使其成为一个可缩放的模型。

复杂性和运营成本：每用户模型往往易于实现。 但是，在某些情况下，你需要测量每个用户的消耗，这有助于确保单个用户的 COGS 保持盈利。 测量消耗并将其与特定用户相关联会增加解决方案的操作复杂性。

风险：不同的用户消耗模式可能会导致盈利能力下降。 例如，使用解决方案较多的用户可能会比使用解决方案较少的用户花费更多服务费用。 此外，解决方案的实际价值回报 (ROV) 不会反映在所购用户许可证的实际数量上。

每活跃用户定价

此模型类似于每用户定价，但不需要客户预先承诺预期用户的数量，客户只需为一段时间内实际登录并使用解决方案的用户付费（如下图所示）。

你可以在任何有意义的时间段内对此进行测量。 每月周期的使用非常普遍，此指标通常记录为每月活跃用户数或 MAU。

优势：从客户的角度来看，此模型需要的投资较少、风险较低，因为浪费最少；未使用的许可证不可计费。 这使得它在营销解决方案或为大型企业客户扩大解决方案时特别有吸引力。 从你（服务所有者）的角度来看，ROV 将以每月活跃用户数的形式更准确地反映给客户。

复杂性和运营成本：每活跃用户模型要求记录实际使用情况，并将其作为发票的一部分提供给客户。 测量每用户消耗有助于确保单个用户的 COGS 保持盈利能力，但同样需要执行额外的工作来测量每个用户的消耗。

风险：与每用户定价一样，其风险在于各个用户的不同消耗模式可能会影响你的盈利能力。 与每用户定价相比，每活跃用户模型的收入流更难以预测。 此外，折扣定价无法提供刺激增长的有用方法。

每单位定价

在许多系统中，用户数量并不是对整体 COGS 影响最大的元素。 例如，在面向设备的解决方案（也称为物联网或 IoT）中，设备数量通常对 COGS 的影响最大。 在这些系统中，可以使用每单位定价模型，你可以在该模型中定义什么是单位，例如设备。 请参阅下图。

此外，一些解决方案具有高度可变的使用模式，其中少数用户对 COGS 产生不成比例的影响。 例如，在销售给实体零售商的解决方案中，每商店定价模型可能适用。

优势：在单个用户对 COGS 没有显著影响的系统中，每单位定价可以更好地表示系统的缩放方式及其对 COGS 产生的影响。 它还可以提高与客户实际使用模式的一致性。 对于许多 IoT 解决方案，其中每个设备都会产生可预测且恒定的消耗量，此模型可能对扩大解决方案增长非常有效。

复杂性和运营成本：通常，每单位定价易于实现，运营成本相当低。 但是，如果需要区分和跟踪单个单位（如设备或零售店）的使用情况，运营成本可能会变得较高。 测量每单位消耗有助于确保保持盈利能力，因为你可以确定单个单位的 COGS。

风险：每单位定价模型的风险类似于每用户定价。 某些单位的不同消耗模式可能意味着盈利能力下降，例如，如果某些设备或商店的用户对解决方案的使用量比其他设备或商店大得多。

基于功能和服务级别的定价

你可以选择以不同的价格点提供具有不同层级的功能的解决方案。 例如，你可以提供两个月度统一费率或每单位价格，一个是具有可用功能子集的基本产品/服务，另一个提供解决方案的完整功能集。 请参阅下图。

此模型还可以为不同的层级提供不同的服务级别协议。 例如，基本层可以提供 99.9% 的运行时间，而高级层可以提供 99.99% 的运行时间。 可以通过支持更高可用性目标的服务和功能来实现更高的服务级别协议 (SLA)。

尽管此模型可以带来商业利益，但需要成熟的工程实践才能实现。 只要仔细评估，此模型会非常有用。

优势：基于功能的定价通常对客户很有吸引力，因为他们可以根据所需的功能集或服务级别选择层级。 它还会向你明确指出，向需要其他功能或更高复原能力的客户追加销售。

复杂性和运营成本：基于功能的定价模型实现起来很复杂，因为它们要求你的解决方案了解每个价格层可用的功能。 功能切换是提供对某些功能子集的访问权限的有效方式，但这需要持续维护。 此外，功能切换会增加开销以确保高质量，因为要测试的代码路径更多。 在某些层级中启用更高的服务可用性目标可能需要额外的体系结构复杂性，以确保为每个层级使用正确的基础结构集，此过程可能会增加解决方案的运营成本。

风险：如果层级或选项过多，基于功能的定价模型可能会变得复杂和混乱。 此外，动态切换功能所需的开销可能会减慢交付附加功能的速度。

免费增值定价

你可以选择提供服务的免费层，该层级提供基本功能，但没有服务级别保证。 然后，你可以提供单独的付费层，该层级提供附加功能和正式的服务级别协议（如下图所示）。

免费层也可以作为限时试用版提供，在试用期间，客户可以使用全部或有限的功能。 这称为免费增值模型，实际上是基于功能的定价模型的延伸。

优势：当解决方案免费时，推广起来很轻松。

复杂性和运营成本：具有基于功能的定价模型的所有复杂性和运营成本问题。 但是，你还必须考虑管理免费租户所涉及的运营成本。 你可能需要确保将过时的租户卸载或删除，并且必须制定明确的保留策略，尤其是对于免费租户。 将租户提升到付费层时，可能需要在 Azure 服务之间迁移租户，以获得更高的 SLA。 迁移到付费层时，保留租户的数据和配置也很重要。

风险：需要确保为租户提供足够高的 ROV，以考虑切换到付费层。 此外，为免费层客户提供解决方案的成本需要由付费层客户的利润率来支付。

所售货物成本定价

你可以选择为解决方案定价，使每个租户只需支付其 Azure 服务份额的运营成本，而不会增加利润率。 此模型（也称为传递成本或定价）有时用于不打算成为利润中心的多租户解决方案。

所售货物成本模型非常适合面向内部的多租户解决方案。 每个组织单位对应一个租户，Azure 资源的成本需要在它们之间分摊。 如果收入来自使用或扩充多租户解决方案的其他产品和服务的销售，此模型可能也适用。

优势：由于此模型不会增加任何利润率，因此租户的成本较低。

复杂性和运营成本：与消耗模型类似，所售货物成本定价依赖于对使用量的准确测量以及按租户拆分此使用量。 跟踪消耗很有挑战性，尤其是在具有许多分布式组件的解决方案中。 你需要保留计费和审核的详细消耗记录，并为客户提供访问其消耗数据的方法。

对于面向内部的多租户解决方案，租户可以接受近似成本估算，计费审核要求也更宽松。 这些宽松的要求降低了操作解决方案的复杂性和成本。

风险：所售货物成本定价会促使租户减少对系统的使用，以降低成本。 但是，因为此模型用于并非利润中心的应用程序，所以这可能不是问题。

统一费率定价

此模型将在给定时间段内向租户收取访问解决方案产生的统一费率。 无论其使用的服务数量、用户数量、连接的设备数量或任何其他指标如何，都适用相同的定价。 请参阅下图。

这是最易实现也是客户最易理解的模型，企业客户通常要求部署此模型。 但是，如果你需要继续添加新功能，或者如果租户消耗增加，却没有任何额外的收入，它很容易变得无利可图。

优势：统一费率定价易于销售，并且客户容易理解和做预算。

复杂性和运营成本：统一费率定价模型易于实现，因为向客户计费不需要任何计量或跟踪消耗。 但是，虽然不是必需的，但建议测量每个租户的消耗，以确保准确测量 COGS 并保持盈利能力。

风险：如果你的租户大量使用你的解决方案，那么这种定价模型很容易变得无利可图。

折扣定价

定义定价模型后，可以选择实施商业策略，通过折扣定价来激励增长。 折扣定价可用于消耗、每用户和每单位定价模型。

注意

除了添加对更复杂的计费结构的支持外，折扣定价通常不需要考虑体系结构问题。 对折扣定价的商业利益的完整讨论超出了本文档的范围。

常见的折扣定价模式包括：

• 固定定价。 无论购买量或消耗量是多少，每个用户、单位或消耗量的成本都一样。 这是最简单的方法。 但是，大量使用你的解决方案的客户可能会觉得他们应该通过获得折扣从规模经济中受益。
• 递减定价。 随着客户购买或消耗更多单位，降低单位成本。 这对客户更具商业吸引力。
• 阶梯定价。 随着客户购买更多单位，降低单位成本。 不过，你可以根据预定义的数量范围逐步降低成本。 例如，你可以对前 100 名用户收取高一点的价格，对第 101 到 200 名用户收取低一点的价格，对第 200 名以后的用户收取更低一点的价格。 这可能更有利可图。

下图演示了这些定价模式。

非生产环境折扣

在许多情况下，客户需要访问可用于测试、训练或创建自己的内部文档的非生产环境。 非生产环境通常具有较低的消耗要求和运营成本。 例如，非生产环境通常不受服务级别协议 (SLA) 的约束，并且速率限制可能设置为较低的值。 你还可以考虑对 Azure 服务进行更积极的自动缩放。

同样，客户往往认为非生产环境比生产环境便宜很多。 当你提供非生产环境时，有几种替代方案可能适用：

• 提供免费增值层，就像你可能已经为付费客户所做的那样。 应仔细监视此层级，因为一些组织可能会创建许多测试和训练环境，这将消耗额外的资源来运行。

  注意

  使用免费增值层的限时试用版通常不适合测试和训练环境。 客户通常需要其非生产环境在生产服务的整个生存期内都可用。

• 提供服务的测试层或训练层，其使用限制较低。 你可以选择将此层级限制为仅供已有付费租户的客户使用。
• 为非生产租户提供打折的每用户、每活跃用户或每单位定价，其服务级别协议较低，甚至没有服务级别协议。
• 对于使用统一费率定价的租户，可以协商将非生产环境作为协议的一部分。

注意

基于功能的定价通常不适合非生产环境，除非提供的功能与生产环境提供的功能相同。 这是因为租户通常希望测试生产环境中可用的所有相同功能，并针对这些功能提供训练。

非盈利性定价模型

使用非盈利性定价模型时，提供服务花费的成本比赚取的收入更高。 例如，你可能对每个租户收取统一费率，并且对服务不设任何限制，但随后使用基于消耗的 Azure 资源构建服务，并且没有每租户使用限制。 在这种情况下，你可能会面临租户过度使用你的服务的风险，从而使为租户提供服务变得无利可图。

通常，你希望避免使用非盈利性定价模型。 但是，在某些情况下，你可能会选择采用非盈利性定价模型，包括：

• 为实现增长而提供免费服务。
• 服务或附加功能提供额外的收入流。
• 托管特定租户提供另一种商业价值，例如将其用作新市场的主力租户。

如果无意中创建了非盈利性定价模型，可通过一些方法来缓解与之相关的风险，包括：

• 通过使用限制限制服务的使用。
• 要求使用产能预留。
• 要求租户迁移到更高的功能或服务层级。

有风险的定价模型

为解决方案实现定价模型时，通常需要对其使用方式做出假设。 如果这些假设被证明是错误的，或者使用模式随时间推移而变化，那么你的定价模型可能会变得无利可图。 有可能变得无利可图的定价模型称为有风险的定价模型。 例如，如果你采用的定价模型期望用户自行限制对你的解决方案的使用量，那么你可能实现了一个有风险的定价模型。

大多数 SaaS 解决方案会定期添加新功能。 这会增加用户的 ROV，但同时也可能导致解决方案使用量的增加。 如果新功能的使用推动了解决方案的使用，但定价模型未考虑到这一点，这可能会导致解决方案变得无利可图。

例如，如果在解决方案中引入了新的视频上传功能，该功能使用基于消耗的资源，并且用户对该功能的接受度高于预期，请考虑将使用限制和功能和服务级别定价结合使用。

使用限制

使用限制使你能够限制服务的使用，以防止定价模型变得无利可图，或防止单个租户过度消耗你的服务容量。 这在多租户服务中尤其重要，其中单个租户可能会通过过度消耗资源影响其他租户的体验。

注意

必须让客户知道你应用了使用限制。 如果你在实施使用限制时未让客户知晓，则会导致客户不满。 这意味着，你必须提前确定和计划使用限制。 目标应该是计划限制，然后在限制成为必然之前将其告知客户。

使用限制通常与功能和服务级别定价结合使用，以在更高的层级提供更多的使用量。 限制也常用于保护核心组件，过度使用这些组件会导致系统瓶颈或性能问题。

速率限制

应用使用限制的常见方法是向 API 或特定应用程序函数添加速率限制。 这也称为限制。 速率限制可防止持续过度使用。 它们通常用于限制在定义的时间段内对 API 的调用次数。 例如，某个 API 每分钟只能被调用 20 次，如果调用频率高于此值，它将返回 HTTP 429 错误。

一些经常使用速率限制的情况包括：

• REST API。
• 异步任务。
• 对时间不敏感的任务。
• 执行成本很高的操作。
• 报告生成。

实施速率限制会增加解决方案的复杂性，但 Azure API 管理等服务可以通过应用速率限制策略对其进行简化。

定价模型生命周期

与解决方案的任何其他部分一样，定价模型具有生命周期。 当应用程序随着时间推移而发展时，你可能需要更改定价模型。 这可能是由不断变化的客户需求、商业需求或应用程序中的功能变化驱动的。 一些常见的定价生命周期更改包括：

• 添加全新的定价模型。 例如，将消耗定价模型添加到当前提供统一费率模型的解决方案。
• 停用现有定价模型。
• 向现有定价模型添加层级。
• 停用现有定价模型中的层级。
• 更改定价模型中某个功能的使用限制。
• 在功能和服务级别定价模型中添加或删除功能。
• 从企业对消费者 (B2C) 商业模型转变为企业对企业 (B2B) 商业模型。 这种转变需要你为企业客户提供新的定价结构。

一次实现和管理许多不同的定价模型通常很复杂。 同时也会让客户感到困惑。 因此，最好只实现一到两个包含少量层级的模型。 这将使解决方案更易于访问和管理。

注意

应测试定价模型和计费功能，最好使用自动化测试，就像系统的任何其他部分一样。 定价模型越复杂，需要测试的内容就越多，因此开发和新功能的成本也会增加。

更改定价模型时，需要考虑以下因素：

• 租户是否希望迁移到新模型？
• 租户能否轻松迁移到新模型？
• 新的定价模型是否会使你的服务面临风险？ 例如，是否会取消当前保护关键资源免于过度使用的速率限制？
• 租户是否有迁移到新定价模型的明确路径？
• 如何阻止租户使用较旧的定价模型，以便停用这些模型？
• 更改定价模型后，租户是否可能会受到高额帐单冲击（对意外帐单的负面反应）？
• 是否针对新的或更改的定价模型监视服务的性能和利用率，以确保持续盈利？
• 是否能够将新定价模型的 ROV 清楚地传达给现有租户？

作者

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

首席作者：

• 丹尼尔·斯科特-伦斯福德|高级合作伙伴技术解决方案顾问

其他参与者：

• Bohdan Cherchyk | FastTrack for Azure 高级客户工程师
• John Downs | FastTrack for Azure 首席客户工程师
• Chad Kittel | 首席软件工程师
• Paolo Salvatori | FastTrack for Azure 首席客户工程师
• 阿森·弗拉基米尔斯基|首席工程师，FastTrack for Azure

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

后续步骤

考虑如何在解决方案中测量租户的消耗。