【SaaS架构】SaaS架构基础--删除单个租户术语

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

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

引入筒仓和水池

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

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

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

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

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

筒仓和水池模型

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

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

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

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

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