【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解决方案的实现中如何共享或专用资源。