重新定义多租户

多租户和 SaaS 这两个术语通常紧密相连。在某些情况下，组织将 SaaS 和多租户混为一谈。虽然这看起来可能很自然，但将 SaaS 等同于多租户往往会导致团队从纯粹的技术角度看待 SaaS。而实际上，与其说 SaaS 是一种架构策略，倒不如说它是一种业务模式。

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

例如，假设您有一个微服务或 Amazon Elastic Compute Cloud (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 解决方案的实施过程中共享或专用资源。