上图提供了核心SaaS架构概念的概念视图。现在，让我们深入了解，并更好地定义SaaS环境如何分解为不同的层。对SaaS概念之间的界限有了更清晰的了解，将更容易描述SaaS解决方案的移动部分。

下图将SaaS环境划分为两个不同的平面。右侧是控制平面。图的这一侧包括用于机载、认证、管理、操作和分析多租户环境的所有功能和服务。

控制平面与应用平面

该控制平面是任何多租户SaaS模型的基础。无论应用程序部署和隔离方案如何，每个SaaS解决方案都必须包含那些服务，这些服务使您能够通过单一、统一的体验管理和运营租户。

在控制平面内，我们进一步将其分解为两个不同的元素。这里的核心服务代表用于协调多租户体验的服务集合。我们已经包括了一些常见的服务示例，这些服务通常是核心的一部分，承认每个SaaS解决方案的核心服务可能会有所不同。

您还将注意到，我们显示了一个单独的管理应用程序。这表示SaaS提供商可能用来管理其多租户环境的应用程序（web应用程序、命令行界面或API）。

一个重要的警告是，控制平面及其服务实际上不是多租户的。该功能没有提供SaaS应用程序的实际功能属性（它确实需要多租户）。例如，如果您查看任何一个核心服务，您都不会发现租户隔离和其他构造是多租户应用程序功能的一部分。这些服务面向所有租户。

图的左侧引用SaaS环境的应用程序平面。这是应用程序的多租户功能所在的位置。图中显示的内容需要保持一定的模糊，因为每个解决方案都可以根据您的领域需求、技术足迹等进行不同的部署和分解。

应用程序域分为两个元素。SaaS应用程序代表您解决方案的租户体验/应用程序。这是租户与SaaS应用程序交互时所接触的表面。然后是表示SaaS解决方案的业务逻辑和功能元素的后端服务。这些可以是微服务，也可以是应用程序服务的其他打包。

您还将注意到，我们已经中断了资源调配。这样做是为了强调这样一个事实，即在入职期间为租户提供的任何资源都将是该应用程序域的一部分。有些人可能认为这属于控制平面。然而，我们将其放置在应用程序域中，因为它必须提供和配置的资源更直接地连接到在应用程序平面中创建和配置的服务。

将其分解为不同的平面，可以更容易地思考SaaS架构的整体布局。更重要的是，它强调需要一组完全超出应用程序功能范围的服务。

前面提到的控制平面提到了一系列核心服务，它们代表了用于机载、管理和操作SaaS环境的典型服务。进一步强调其中一些服务的作用可能有助于突出它们在SaaS环境中的范围和用途。以下是这些服务的简要概述：

• 入职——每个SaaS解决方案都必须提供一种无摩擦的机制，以将新租户引入您的SaaS环境。这可以是自助注册页面，也可以是内部管理的体验。无论哪种方式，SaaS解决方案都应该尽其所能消除此体验中的内部和外部摩擦，并确保此过程的稳定性、效率和可重复性。它在支持SaaS业务的增长和规模方面发挥着至关重要的作用。通常，该服务协调其他服务以创建用户、租户、隔离策略、资源调配和每租户资源。
• 租户–租户服务提供了一种集中租户的策略、属性和状态的方法。关键是租户不是个人用户。事实上，租户可能与许多用户关联。
• 身份–SaaS系统需要一种明确的方式来将用户连接到租户，从而将租户上下文带入其解决方案的身份验证和授权体验。这会影响入职体验和用户档案的总体管理。
• 计费–作为采用SaaS的一部分，组织通常采用新的计费模式。他们还可以探索与第三方计费提供商的集成。这项核心服务主要集中于支持新租户的入职，并收集用于为租户生成账单的消费和活动数据。
• 指标–SaaS团队非常依赖于他们捕获和分析丰富的指标数据的能力，这些数据可以让租户更清楚地了解他们如何使用系统、他们如何使用资源以及他们如何使用他们的系统。这些数据用于制定运营、产品和业务战略。
• 管理员用户管理–SaaS系统必须同时支持租户用户和管理员用户。管理员用户代表SaaS提供商的管理员。他们将登录到您的运营经验中，以监控和管理您的SaaS环境。

SaaS和托管服务提供商（MSP）模型之间的界限也存在一些混淆。如果您查看MSP模型，它可能具有与SaaS模型类似的目标。

然而，如果您深入了解MSP，您会发现MSP和SaaS实际上是不同的。下图提供了MSP环境的概念视图。

托管服务提供商（MSP）模型

该图表示MSP模型的一种方法。在左侧，您将看到使用MSP模型运行的客户。通常，这里的方法是使用任何可用的自动化来配置每个客户环境，并为该客户安装软件。

右边是MSP为支持这些客户环境而提供的运营足迹的近似值。

需要注意的是，MSP通常安装和管理给定客户想要运行的产品版本。所有客户都可以运行相同的版本，但MSP模型通常不需要这样做。

总的策略是通过拥有这些环境的安装和管理来简化软件提供商的生活。虽然这让提供商的生活更简单，但它并没有直接映射到SaaS产品所必需的价值观和思维方式。

重点是减轻管理责任。这样做并不等同于让所有客户都在同一版本上运行，并拥有统一的管理和运营经验。相反，MSP通常允许单独的版本，并且通常将这些环境中的每一个视为在操作上独立的。

在某些领域，MSP可能开始与SaaS重叠。如果MSP本质上要求所有客户运行相同的版本，并且MSP能够通过一次体验对所有租户进行集中安装、管理、运营和计费，那么可能会开始比MSP更多的SaaS。

更广泛的主题是，自动化环境安装并不等于拥有SaaS环境。只有当您添加了前面讨论的所有其他注意事项时，这才更能代表真正的SaaS模型。

如果我们从本故事的技术和运营方面进行回顾，MSP和SaaS之间的界限将变得更加明显。通常，作为SaaS业务，您的产品能否成功取决于您是否能够深入参与体验的所有活动部分。

这通常意味着掌握入职体验的脉搏，了解运营事件如何影响租户，跟踪关键指标和分析，并与客户保持密切联系。在MSP模型中，如果这项工作交给了其他人，那么您可能最终会从SaaS业务运营的核心关键细节中脱离一个层次。

作为使用术语多租户的一部分，人们自然会使用术语单租户来描述SaaS环境。然而，鉴于前面概述的背景，“单一租户”一词造成了混乱。

上图是否为单租户环境？虽然从技术上讲，每个租户都有自己的堆栈，但这些租户仍在多租户模式下运行和管理。这就是为什么通常避免使用“单一租户”一词的原因。相反，所有环境都被描述为多租户，因为它们只是实现了一些租赁的变体，其中一些或全部资源是共享的或专用的。

引入筒仓和水池

考虑到模型的所有这些变化以及多租户这一术语带来的挑战，我们引入了一些术语，使我们能够更准确地捕捉和描述构建SaaS时使用的不同模型。

我们用来描述SaaS环境中资源使用的两个术语是筒仓和池。这些术语允许我们标记SaaS环境的性质，使用多租户作为可应用于任何数量的基础模型的总体描述。

在最基本的层面上，术语思洛用来描述资源专用于给定租户的场景。相反，池模型用于描述租户共享资源的场景。

在我们研究筒仓和池术语的使用方式时，必须明确筒仓和池不是全部或全部概念。筒仓和池可以应用于整个租户的资源堆栈，也可以选择性地应用于整个SaaS环境的一部分。因此，如果我们说某些资源使用了筒仓模型，这并不意味着该环境中的所有资源都是筒仓。这同样适用于我们如何使用术语pooled。

下图提供了一个示例，说明如何在SaaS环境中更细粒度地使用孤立模型和合并模型：

筒仓和水池模型

该图包括一系列示例，旨在说明筒仓和池模型的更具针对性。如果您从左到右执行此操作，您将看到我们从一个订单微服务开始。该微服务具有孤立的计算和池存储。它与具有池计算和池存储的产品服务交互。

然后，产品服务与一个发票微服务交互，该服务汇集了计算和孤立存储。此服务通过队列将消息发送到发货服务。队列以孤立模型部署。

最后，运送微服务从孤立队列获取消息。它使用池计算和存储。

虽然这看起来有点复杂，但目标是突出筒仓和池概念的粒度特性。在您设计和构建SaaS解决方案时，预计您将根据您的领域和客户的需求做出这些筒仓和池决策。

嘈杂的邻居、隔离、分层以及许多其他原因可能会影响您选择应用筒仓或池模型的方式和时间。

为了解决这一经典软件困境的需求，组织转向了一种模式，该模式允许他们创建一种单一的、统一的体验，从而允许对客户进行集体管理和操作。

下图提供了一个环境的概念视图，其中所有客户都通过共享模型进行管理、入职、计费和运营。

一个环境的概念视图，其中所有客户都通过共享模型进行管理、入职、计费和运营

乍一看，这可能与以前的模型没有什么不同。然而，当我们进一步深入研究时，您会发现这两种方法存在根本性的显著差异。

首先，您将注意到客户环境已重命名为租户。租户的概念是SaaS的基础。基本思想是，您有一个单一的SaaS环境，您的每个客户都被视为该环境的租户，消耗他们所需的资源。租户可以是一家拥有许多用户的公司，也可以直接与单个用户关联。

为了更好地理解租户的想法，可以考虑公寓或商业建筑的想法。这些建筑中的每一个空间都出租给了单独的租户。租户依靠建筑物的一些共享资源（水、电等）来支付他们的消费。

SaaS租户遵循类似的模式。您拥有SaaS环境的基础设施，以及使用该环境基础设施的租户。每个租户消耗的资源量可能不同。这些租户也是集体管理、计费和运营的。

如果你回头看图表，你会看到租赁的概念变得生动起来。在这里，租户不再拥有自己的环境。相反，所有租户都被安置在一个集体SaaS环境中并在其中进行管理。

该图还包括围绕SaaS环境的一系列共享服务。这些服务对SaaS环境的所有租户都是全球性的。这意味着，例如，该环境的所有租户都共享登录和身份。管理、运营、部署、计费和度量也是如此。

这种统一的服务集的思想是SaaS的基础，这些服务普遍应用于所有租户。通过分享这些概念，您可以解决与上述经典模型相关的许多挑战。

这个图的另一个关键的、有点微妙的元素是，这个环境中的所有租户都在运行相同版本的应用程序。为每个客户运行单独的一次性版本的想法已经不复存在。让所有租户运行同一版本是SaaS环境的一个基本区别属性。

通过让所有客户运行相同版本的产品，您不再面临经典安装软件模型的许多挑战。在统一模型中，新功能可以通过一个共享流程部署到所有租户。

这种方法使您能够使用一个单一的操作面板来管理和操作所有租户。这使您能够通过共同的运营体验来管理和监控租户，从而允许在不增加增量运营开销的情况下添加新租户。这是SaaS价值主张的核心部分，它使团队能够减少运营费用，并提高整体组织敏捷性。

想象一下，在这个模型中增加100或1000个新客户意味着什么。不用担心这些新客户会如何侵蚀利润并增加复杂性，您可以将这种增长视为它所代表的机会。

通常，SaaS的重点是如何实现此模型中间的应用程序。企业希望关注数据的存储方式、资源的共享方式等。然而，现实是，尽管这些细节非常重要，但有许多方法可以构建应用程序，并将其作为SaaS解决方案呈现给客户。

重要的是，更广泛的目标是为租户环境提供单一、统一的体验。拥有这种共享的经验，使您能够推动与SaaS业务总体目标相关的增长、敏捷性和运营效率。

为了理解SaaS，让我们从一个相当简单的概念开始，了解我们在创建SaaS业务时要实现的目标。最好的开始是看看传统（非SaaS）软件是如何创建、管理和操作的。

下图提供了几个供应商如何打包和交付其解决方案的概念视图。

打包和交付软件解决方案的经典模型

在这个图中，我们描述了一组客户环境。这些客户代表购买了供应商软件的不同公司或实体。这些客户中的每一个基本上都在一个独立的环境中运行，在这个环境中他们安装了软件提供商的产品。

在此模式下，每个客户的安装都被视为专用于该客户的独立环境。这意味着客户将自己视为这些环境的所有者，可能需要一次性定制或支持其需求的独特配置。

这种心态的一个常见副作用是，客户将控制他们运行的产品版本。这种情况可能有多种原因。客户可能担心新功能，或者担心采用新版本带来的干扰。

您可以想象这种动态会如何影响软件提供商的运营足迹。您越允许客户拥有一次性环境，管理、更新和支持每个客户的不同配置就越具有挑战性。

这种对一次性环境的需求通常要求组织创建专门的团队，为每个客户提供单独的管理和运营经验。虽然这些资源中的一些可能会在客户之间共享，但该模型通常会为每个新入职的客户引入增量费用。

让每个客户在自己的环境中（在云中或内部）运行他们的解决方案也会影响成本。虽然您可以尝试扩展这些环境，但扩展将仅限于单个客户的活动。本质上，您的成本优化仅限于在单个客户环境的范围内实现的目标。这也意味着您可能需要单独的扩展策略来适应客户之间的活动变化。

最初，一些软件企业会将此模型视为一个强大的架构。他们利用提供一次性定制的能力作为销售工具，允许新客户提出其环境特有的要求。尽管客户数量和业务增长仍然温和，但这种模式似乎完全可持续。

然而，随着公司开始取得更广泛的成功，这种模式的限制开始产生真正的挑战。例如，设想一个场景，您的业务达到了显著的增长高峰，从而快速增加了大量新客户。这种增长将开始增加运营开销、管理复杂性、成本和一系列其他问题。

最终，这种模式的总体开销和影响可能开始从根本上破坏软件业务的成功。第一个痛点可能是运营效率。与吸引客户相关的人员配置和成本增加开始侵蚀业务利润。

然而，运营问题只是挑战的一部分。真正的问题是，这种模式随着规模的扩大，直接开始影响企业发布新功能和跟上市场步伐的能力。当每个客户都有自己的环境时，提供商必须在尝试将新功能引入其系统时平衡一系列更新、迁移和客户需求。

这通常会导致更长和更复杂的发布周期，这往往会减少每年发布的数量。更重要的是，这种复杂性使得团队在每个新特性发布给客户之前就花了更多的时间来分析它们。团队开始更专注于验证新功能，而不是交付速度。发布新功能的开销变得如此巨大，以至于团队更加专注于测试机制，而较少关注推动其产品创新的新功能。

在这种较慢、更谨慎的模式下，团队往往会有较长的周期时间，这会在创意开始与客户手中之间产生越来越大的差距。总的来说，这会阻碍你对市场动态和竞争压力做出反应的能力。

定义SaaS意味着什么首先要同意一个关键原则：SaaS是一种商业模式。这意味着最重要的是，SaaS交付模型的采用是由一组业务目标直接驱动的。是的，技术将被用来实现其中的一些目标，但SaaS就是要建立一套针对特定业务目标的思维方式和模式。

让我们更仔细地看看与采用SaaS交付模式相关的一些关键业务目标。

• 敏捷性——这一术语概括了SaaS的更广泛目标。成功的SaaS公司是建立在这样一个理念之上的：他们必须做好准备，不断适应市场、客户和竞争动态。伟大的SaaS公司的结构是不断接受新的定价模式、新的细分市场和新的客户需求。
• 运营效率–SaaS公司依靠运营效率来提高规模和灵活性。这意味着要建立一种文化和工具，专注于创建一个可促进频繁快速发布新功能的运营足迹。它还意味着拥有一种单一、统一的体验，允许您集体管理、操作和部署所有客户环境。支持一次性版本和定制的想法已经不复存在。SaaS业务将运营效率作为其成功增长和扩展业务能力的核心支柱。
• 无摩擦加入——作为更加灵活和包容增长的一部分，您还必须重视减少租户客户入职过程中的任何摩擦。这普遍适用于企业对企业（B2B）和企业对客户（B2C）客户。无论您支持哪一个细分市场或哪种类型的客户，您都需要关注客户的价值实现时间。向以服务为中心的模式的转变要求SaaS业务专注于客户体验的各个方面，特别强调整个入职生命周期的可重复性和效率。
• 创新——转向SaaS不仅仅是为了满足当前客户的需求；这是关于让你进行创新的基本要素。您希望在SaaS模型中对客户需求做出反应和响应。然而，您也希望利用这种灵活性来推动未来的创新，从而为您的客户打开新的市场、机会和效率。
• 市场反应——SaaS不再是传统的季度发布和两年计划的概念。它依靠其敏捷性，使组织能够对市场动态做出反应和响应。对SaaS的组织、技术和文化元素的投资为基于新兴客户和市场动态的业务战略提供了机会。
• 增长–SaaS是一种以增长为中心的业务战略。围绕敏捷性和效率调整组织的所有活动部分，使SaaS组织能够以增长模式为目标。这意味着要建立一种机制，以接受并欢迎您的SaaS产品的快速采用。

您会注意到，这些项目中的每一项都集中在业务结果上。有多种技术策略和模式可用于构建SaaS系统。然而，这些技术策略并没有改变更广泛的商业故事。

当我们与组织坐下来，询问他们在采用SaaS的过程中想要实现什么时，我们总是从以业务为中心的讨论开始。技术选择很重要，但必须在这些业务目标的背景下实现。例如，在没有实现敏捷性、运营效率或无摩擦的情况下成为多租户会破坏SaaS业务的成功。

以此为背景，让我们尝试将其形式化为更简洁的SaaS定义，该定义符合前面概述的原则：

SaaS是一种业务和软件交付模式，它使组织能够以低摩擦、以服务为中心的模式提供解决方案，从而为客户和提供商实现最大价值。它依靠敏捷性和运营效率作为促进增长、覆盖和创新的业务战略的支柱。

您应该看到业务目标之间的一致性，以及它们如何依赖于为所有客户提供共享体验。迁移到SaaS的很大一部分意味着远离可能是传统软件模型一部分的一次性定制。任何为客户提供专业化服务的努力通常都会使我们偏离我们试图通过SaaS实现的核心价值。

采用“服务”模式不仅仅是营销或术语。在服务思维中，您会发现自己正在远离传统的基于产品的开发方法。虽然特性和功能对每种产品都很重要，但SaaS更强调客户对您的服务的体验。

这是什么意思？在以服务为中心的模式中，您需要更多地考虑客户如何加入您的服务，他们如何快速实现价值，以及您如何快速引入满足客户需求的功能。与您的服务构建、运营和管理方式相关的详细信息不在客户的视野之内。

在这种模式下，我们将SaaS服务视为我们可能使用的任何其他服务。如果我们在餐馆，我们当然关心食物，但我们也关心服务。你们的服务员多久来到你们的餐桌上，多久给你们补充一次水，食物多久送来，这些都是服务体验的衡量标准。这是我们构建SaaS服务的思维方式和价值体系。

这种“服务即服务”模式应该对您构建团队和服务的方式产生重大影响。您的积压工作现在将使这些体验属性与特性和功能处于同等或更高的地位。企业还将这些视为SaaS产品长期增长和成功的基础。

摘要

在软件即服务（SaaS）模型中运行业务的范围、目标和性质可能很难定义。用于描述SaaS的术语和模式因其来源而异。本文档的目标是更好地定义SaaS的基本元素，并创建在AWS上设计和交付SaaS系统时应用的模式、术语和价值体系的更清晰的图景。更广泛的目标是提供一系列基础见解，让客户更清楚地了解他们在采用SaaS交付模式时应考虑的选项。

本文针对的是SaaS构建者和架构师，他们正处于SaaS之旅的开始阶段，以及更多经验丰富的构建者，他们希望完善对核心SaaS概念的理解。这些信息中的一些信息对SaaS产品所有者和策略师也很有用，他们希望更加熟悉SaaS环境。

您的架构是否完善？

AWS良好架构框架有助于您了解在云中构建系统时所做决策的利弊。框架的六大支柱使您能够学习设计和运行可靠、安全、高效、经济高效和可持续系统的架构最佳实践。使用AWS管理控制台中免费提供的AWS良好架构工具，您可以通过回答每个支柱的一组问题，对照这些最佳实践检查工作负载。

有关云架构参考架构部署、图表和白皮书的更多专家指南和最佳实践，请参阅AWS架构中心。

介绍

术语软件即服务（SaaS）用于描述业务和交付模型。然而，挑战在于，SaaS意味着什么并没有得到普遍理解。

虽然在SaaS的一些核心支柱上达成了一些共识，但对于SaaS意味着什么仍然存在一些困惑。团队看待SaaS的方式自然会有所不同。同时，SaaS概念和术语的不清晰可能会给那些探索SaaS交付模型的人带来一些困惑。

本文档侧重于概述用于描述核心SaaS概念的术语。围绕这些概念有一个共同的思维方式，可以清晰地了解SaaS架构的基本元素，为您提供描述SaaS架构结构的共同词汇。当您深入挖掘基于这些主题的其他内容时，这尤其有用。

本白皮书回顾了多租户的体系结构细节，并探讨了我们如何定义SaaS的基本概念。理想情况下，这也将提供一组更清晰的术语，使组织能够更快地调整其SaaS解决方案的风格和性质。

SaaS为应用程序的身份模型添加了新的考虑因素。当每个用户都经过身份验证时，他们必须连接到特定的租户上下文。此租户上下文提供了整个SaaS环境中使用的租户的基本信息。

租户与用户的这种绑定通常被称为应用程序的SaaS身份。当每个用户进行身份验证时，身份提供者通常会生成一个包含用户身份和租户身份的令牌。

将租户与用户连接是SaaS架构的一个基本方面，具有许多下游影响。此身份过程中的令牌流入应用程序的微服务，用于创建租户感知日志、记录度量、计费、强制租户隔离等。

必须避免依赖于将用户映射到租户的独立机制的场景。这会破坏系统的安全性，并经常在架构中造成瓶颈。

SaaS产品面向B2B和B2C市场。虽然市场和客户肯定有不同的动态，但SaaS的总体原则不会以某种方式改变每个市场。

例如，如果您查看入职培训，B2B和B2C客户可能有不同的入职体验。的确，B2C系统可能更关注自助登机流程（尽管B2B系统可能也支持这一点）。

虽然在如何向客户提供入职培训方面可能存在差异，但入职培训的基本基本价值基本相同。即使您的B2B解决方案依赖于内部入职流程，我们仍然希望该流程尽可能无摩擦和自动化。B2B并不意味着我们会改变对客户的期望值。

本文档的目标是概述基本的SaaS架构概念，围绕用于描述SaaS模式和策略的模型和术语提供一些澄清。希望这将使组织能够更清晰地了解SaaS的整体情况。

这里所涉及的大部分内容都集中在SaaS意味着什么，重点是创建一个环境，让您通过统一的体验管理和运营所有SaaS租户。这与SaaS首先是一种商业模式的核心思想相联系。您构建的SaaS架构旨在促进这些基本业务目标。

多租户和SaaS这两个术语通常紧密相连。在某些情况下，组织将SaaS和多租户描述为同一回事。虽然这看起来很自然，但将SaaS和多租户等同起来往往会导致团队对SaaS采取纯粹的技术观点，而实际上，SaaS更多的是一种业务模式，而不是一种架构策略。

为了更好地理解这个概念，让我们从多租户的经典观点开始。在这个纯粹以基础设施为中心的视图中，多租户用于描述租户如何共享资源以提高灵活性和成本效率。

例如，假设您有一个由SaaS系统的多个租户使用的微服务或Amazon弹性计算云（Amazon EC2）实例。该服务将被视为在多租户模式中运行，因为租户共享运行该服务的基础设施。

这个定义的挑战在于它太直接地将多租户的技术概念附加到SaaS上。它假设SaaS的定义特征是它必须拥有共享的多租户基础设施。当我们研究SaaS在不同环境中实现的各种方式时，SaaS的这种观点开始瓦解。

下图提供了SaaS系统的视图，揭示了我们在定义多租户时面临的一些挑战。

在这里，您将看到前面描述的经典SaaS模型，其中包含一系列由共享服务包围的应用程序服务，允许您共同管理和运营租户。

新的是我们包含的微服务。该图包括三个示例微服务：产品、订单和目录。如果仔细观察这些服务的租赁模式，您会发现它们都采用了稍微不同的租赁模式。

SaaS和多租户

产品服务与所有租户共享其所有资源（计算和存储）。这符合多租户的经典定义。然而，如果您查看订单服务，您会发现它为每个租户提供了共享计算，但存储空间是独立的。

目录服务添加了另一种变体，其中每个租户的计算是独立的（每个租户都有单独的微服务部署），但它为所有租户共享存储。

这种性质的变化在SaaS环境中很常见。嘈杂的邻居、分层模型、隔离需求这些都是您可能会选择性地共享或隔离SaaS解决方案的原因之一。

考虑到这些变化和许多其他可能性，弄清楚如何使用术语“多租户”来描述这种环境变得更具挑战性。总体而言，就客户而言，这是一个多租户环境。然而，如果我们使用最技术的定义，这个环境的某些部分是多租户的，有些则不是。

这就是为什么有必要不再使用术语多租户来描述SaaS环境。相反，我们可以讨论如何在应用程序中实现多租户，但避免使用它来将解决方案描述为SaaS。如果要使用术语“多租户”，那么将整个SaaS环境描述为多租户更有意义，因为知道架构的某些部分可能是共享的，而有些部分可能不是共享的。总体而言，您仍在多租户模式中操作和管理此环境。

极端情况

为了更好地强调这种租赁的概念，让我们来看一个SaaS模型，其中租户共享零资源。下图提供了一些SaaS提供商使用的示例SaaS环境。

每个租户的堆栈

在这个图中，您将看到我们仍然有共同的环境围绕着这些租户。然而，每个租户都部署了一个专用的资源集合。在此模型中，租户不共享任何内容。

这个例子挑战了多租户的含义。这是一个多租户环境吗，即使没有共享任何资源？使用该系统的租户对具有共享资源的SaaS环境有着相同的期望。事实上，他们可能不知道在SaaS环境下如何部署资源。

即使这些租户在一个孤立的基础设施中运行，他们仍然是集体管理和运营的。他们共享统一的入职、身份、指标、计费和运营经验。此外，当发布新版本时，它将部署到所有租户。为了实现这一点，您不能允许为单个租户进行一次性定制。

这个极端的例子为测试多租户SaaS的概念提供了一个很好的模型。虽然它可能无法实现共享基础设施的所有效率，但它是一个完全有效的多租户SaaS环境。对于一些客户，他们的领域可能会规定他们的一些或所有客户在这个模型中运行。这并不意味着它们不是SaaS。如果他们使用这些共享服务，并且所有租户运行相同的版本，这仍然符合SaaS的基本原则。

考虑到这些参数和SaaS的更广泛定义，您可以看到需要发展多租户这一术语的使用。将任何以多租户的方式共同管理和操作的SaaS系统称为多租户更有意义。然后，您可以使用更精细的术语来描述在SaaS解决方案的实现中如何共享或专用资源。

SaaS的讨论也倾向于包括计量、度量和计费的概念。这些概念通常合并为一个概念。然而，区分计量、度量和计费在SaaS环境中扮演的不同角色很重要。

这些概念的挑战在于，它们经常对同一个词有重叠的用法。例如，我们可以讨论用于生成账单的计量。同时，我们还可以讨论用于跟踪与计费无关的资源的内部消耗的计量。我们还讨论了许多上下文中的度量和SaaS，这些上下文可以混合到讨论中。

为了帮助解决这个问题，让我们将一些特定的概念与这些术语中的每一个联系起来（知道这里没有绝对的概念）。

• 计量——这个概念有很多定义，但最适合SaaS计费领域。其想法是，您可以测量租户活动或资源消耗，以收集生成账单所需的数据。
• 度量标准–度量标准代表您为分析业务、运营和技术领域的趋势而捕获的所有数据。该数据用于跨SaaS团队中的许多上下文和角色。

这一区别并不重要，但有助于简化我们对SaaS环境中计量和度量的作用的思考。

现在，如果我们将这两个概念与示例联系起来，您可以考虑使用特定的计量事件来检测应用程序，这些事件用于显示生成账单所需的数据。这可能是请求的数量、活动用户的数量，也可能映射到与对客户有意义的某个单元相关的某个消耗总量（请求、CPU、内存）。

在您的SaaS环境中，您将从应用程序中发布这些计费事件，它们将被您的SaaS系统采用的计费结构吸收和应用。这可能是一个定制的第三方计费系统。

相比之下，衡量标准背后的思维方式是捕捉那些对评估不同租户对您的系统造成的健康和运营影响至关重要的行动、活动、消费模式等。您在这里发布和聚合的度量更多地取决于不同角色（运营团队、产品所有者、架构师等）的需求。在这里，这些度量数据被发布并聚合到一些分析工具中，这些分析工具允许这些不同的用户构建系统活动的视图，以分析系统中最符合其角色的方面。产品所有者可能想了解不同租户是如何使用功能的。架构师可能需要帮助他们理解租户如何消耗基础设施资源的视图，等等。

筒仓和池也可以用来描述整个SaaS堆栈。在这种方法中，租户的所有资源都以专用或共享的方式部署。下图提供了如何在SaaS环境中实现这一点的示例。

全堆筒仓和水池模型

在该图中，您将看到用于全栈租户部署的三种不同模型。首先，您将看到有一个完整的堆栈池环境。此池中的租户共享所有资源（计算、存储等）。

所示的其他两个堆栈旨在表示全堆栈孤立的租户环境。在这种情况下，租户3和租户4被显示为各自具有自己的专用堆栈，其中没有资源与其他租户共享。

在相同的SaaS环境中，筒仓模型和池模型的混合并不那么典型。例如，假设您有一组基本层租户，他们为使用您的系统支付适中的价格。这些租户被安置在联合环境中。

同时，你也可能有高级租户愿意为在筒仓中运行的特权支付更多费用。这些客户使用单独的堆栈进行部署（如图所示）。

即使在这个模型中，您可能允许租户在自己的全栈筒仓中运行，这些筒仓也必须不允许对这些租户进行任何一次性的更改或定制。在所有方面，这些堆栈中的每一个都应该运行相同的堆栈配置和相同的软件版本。当发布新版本时，它将部署到池租户环境和每个孤立环境。

数据分区用于描述用于在多租户环境中表示数据的不同策略。该术语广泛用于涵盖一系列不同的方法和模型，这些方法和模型可用于将不同的数据结构与单个租户相关联。

请注意，经常有人倾向于将数据分区和租户隔离视为可互换的。这两个概念并不等同。当我们谈论数据分区时，我们谈论的是如何为单个租户存储租户数据。对数据进行分区并不能确保数据被隔离。隔离仍然必须单独应用，以确保一个租户无法访问另一个租户的资源。

每种AWS存储技术都为数据分区策略带来了自己的考虑因素。例如，在AmazonDynamoDB中隔离数据与使用AmazonRelationalDatabaseService（AmazonRDS）隔离数据看起来非常不同。

通常，在考虑数据分区时，首先要考虑数据是孤立的还是汇集的。在孤立模型中，每个租户都有一个不同的存储结构，没有混合数据。对于池式分区，数据根据租户标识符进行混合和分区，租户标识符确定哪些数据与每个租户关联。

例如，对于AmazonDynamoDB，一个孤立的模型为每个租户使用一个单独的表。通过将租户标识符存储在管理所有租户数据的每个AmazonDynamoDB表的分区键中，可以实现AmazonDynamo DB中的数据池化。

您可以想象这在AWS服务的范围内会有怎样的变化，每个服务都引入了自己的结构，这可能需要不同的方法来实现每个服务的筒仓和池存储模型。

虽然数据分区和租户隔离是单独的主题，但您选择的数据分区策略可能会受到数据隔离模型的影响。例如，您可能会存储一些存储，因为这种方法最符合您的领域或客户的要求。或者，您可能会选择思洛存储器，因为池模型可能不允许您以解决方案所需的粒度级别强制隔离。

吵闹的邻居也会影响你的隔离方式。应用程序中的某些工作负载或用例可能需要保持独立，以限制来自其他租户的影响或满足服务级别协议（SLA）。

您将客户转移到多租户模式中的次数越多，他们就越担心一个租户访问另一个租户的资源的可能性。SaaS系统包括明确的机制，确保每个租户的资源即使在共享基础设施上运行也是隔离的。

这就是我们所说的租户隔离。租户隔离背后的思想是，您的SaaS架构引入了严格控制资源访问的结构，并阻止任何访问另一个租户资源的尝试。

请注意，租户隔离与一般安全机制是分开的。您的系统将支持身份验证和授权；然而，租户用户经过身份验证并不意味着您的系统已实现隔离。隔离与应用程序中的基本身份验证和授权分开应用。

为了更好地理解这一点，假设您使用了身份提供者来验证对SaaS系统的访问。来自该认证体验的令牌还可以包括关于用户角色的信息，该信息可以用于控制该用户对特定应用功能的访问。这些构造提供安全性，但不提供隔离。事实上，用户可以经过身份验证和授权，并且仍然可以访问另一个租户的资源。关于身份验证和授权的任何内容都不一定会阻止此访问。

租户隔离只关注于使用租户上下文来限制对资源的访问。它评估当前租户的上下文，并使用该上下文来确定该租户可以访问哪些资源。它对该租户内的所有用户应用此隔离。

当我们研究如何在所有不同的SaaS架构模式中实现租户隔离时，这变得更具挑战性。在某些情况下，可以通过将整个资源堆栈专用于租户来实现隔离，其中网络（或更粗粒度的）策略阻止跨租户访问。在其他场景中，您可能拥有需要更细粒度策略来控制资源访问的池资源（AmazonDynamoDB表中的项）。

任何访问租户资源的尝试都应仅限于属于该租户的资源。SaaS开发人员和架构师的工作是确定哪些工具和技术组合将支持特定应用程序的隔离需求。

有许多资源围绕SaaS架构模式进行了更详细的讨论，这些模式符合这里描述的模式。

有关更多信息，请参阅：

• SaaS租户隔离策略（AWS白皮书）
• SaaS存储策略（AWS白皮书）
• 架构良好的SaaS镜头（AWS白皮书）