概述

作为SaaS架构师，选择多租户部署模型是您需要做的第一件事。在此阶段，您需要从多租户实现的细节中抽身，思考SaaS环境的基本架构。您在应用程序部署模型上的选择将对成本、运营、分层以及其他众多属性产生深远影响，这些属性将直接影响您的SaaS业务成功。

在本章中，将详细探讨多种不同的多租户部署模型，分析这些模型如何用于满足各种技术和业务需求。在此过程中，我将重点阐述各模型的优缺点，并帮助您理解所选模型如何影响SaaS产品的复杂性、可扩展性、性能和敏捷性。理解这些模型及其核心价值与权衡是制定一种架构策略的关键，这种策略需要平衡业务现实、客户需求、时间压力以及长期SaaS目标。虽然这些模型中存在一些适用于许多SaaS团队的共同主题，但并不存在适用于所有人的通用蓝图。相反，您需要在这些部署模型中进行选择，权衡各种选项，并最终选定一个模型或多个模型的组合，以满足您当前及未来的需求。

我们还将利用本章继续扩展SaaS术语库，为这些模型及其支撑架构赋予专业术语，这些术语将在本书后续内容中反复引用。这些新术语将为您提供更精准的方式来描述SaaS环境的本质，并使您能够更清晰、更细致地描述多租户架构中各组件的运作机制。这些术语和概念允许您以更灵活的方式描述和分类SaaS架构，从而更好地适应实际环境中多租户架构的各种变体。

随着我们开始部署模型，您将逐渐看到特定技术在这些模式探索中崭露头角。尽管部署模型本身没有直接对应的具体技术，但您将开始看到它们如何在与更具体的构造关联时逐渐成形。

什么是部署模型？

描述SaaS架构的挑战之一在于，并不存在一种通用的架构策略能够适用于所有SaaS解决方案。相反，我们发现SaaS架构呈现出多种形态、规模和足迹，每种架构都拥有其独特的价值主张和原则。您的任务是确定这些策略的哪些组合最适合您的解决方案需求。部分租户是否需要完全专用的基础设施？其他租户是否需要共享基础设施？还是需要混合使用这些选项？这些更高层次的根本性问题，正是您在定义SaaS架构部署范围时需要首先思考的。

我在这一领域面临的第一个挑战是缺乏能够准确分类不同多租户部署模式的精确术语。该领域需要一种更好的方式来描述资源如何在环境中部署以支持不同租户的差异化需求。这就是部署模型概念的起源。定义部署模型的目标是为开发者提供一种描述更高层次架构策略的手段，这些策略用于描述不同租户环境的部署特征。部署模型表明了您将在多租户解决方案的应用层中如何部署资源和基础设施。我们通过几个部署模型来帮助澄清这一概念。图3-1展示了两个示例部署模型。

图3-1

在左侧，您会看到一个部署模型，其中所有租户资源在多租户环境的计算层中共享。然而，存储资源专用于各个租户。相比之下，右侧的图表提供了一个部署模型的另一种变体，其中租户的所有基础设施（计算、存储等）都部署在专用模型中。这些只是两种部署模型的示例，但它们为您提供了更具体的视图，说明我们在描述SaaS部署模型的基本方面时所指的内容。关键要点是，您的部署模型代表了您用于确定租户工作负载如何映射到其对应基础设施资源的策略。

它明确了哪些资源将被共享，哪些将被专用。在这一阶段，部署模型是一个相对简单的概念。随着您深入探索这些部署模型如何实际应用，您将逐渐理解定义部署模型时需要考虑的细节。这一概念在您开始考虑多租户解决方案的工作负载、合规性、隔离和分层需求时尤为重要。这些因素最终会在很大程度上影响部署模型的整体架构。您选择的部署模型将贯穿整个架构，影响环境的路由、授权、成本效率及运营特征。在选择部署模型时所做的决策，将对我们SaaS产品几乎所有维度产生深远影响。

选择部署模型

了解每种部署模型的价值主张是有帮助的。然而，选择部署模型不仅仅是评估单一模型的特性。当您坐下来确定哪种部署模型最适合您的应用程序和业务时，通常需要权衡一系列参数。

在某些情况下，您当前解决方案的状态可能会对您选择的部署模型产生重大影响。例如，SaaS迁移通常更多是关于找到一个目标部署模型，使您能够在不重建整个解决方案的情况下实现SaaS化。上市时间、竞争压力、遗留技术考虑以及团队构成也是在SaaS迁移故事中可能代表重要变量的因素。这些因素中的每一个都可能影响部署模型的选择。

显然，正在构建新SaaS解决方案的团队拥有更大的自由度。在此情况下，您选择的部署模型可能更多地由目标用户群体和您希望通过多租户服务实现的用户体验所驱动。挑战在于选择一个能够平衡业务短期和长期目标的部署模型。如果选择的模型过于聚焦于短期体验，可能在业务达到临界规模时限制增长。同时，过度倾向于一种超出当前客户需求范围的部署模型，可能意味着过早优化。在灵活性与聚焦之间找到合适的平衡点颇具挑战性。

无论您从何处开始SaaS转型之旅，都必然会受到一些更广泛的全球性因素影响。例如：产品包装、分层策略和定价目标往往在决定哪种部署模型最适合您的业务目标方面发挥关键作用。成本和运营效率也是部署模型选择中的重要考量因素。虽然每个解决方案都希望尽可能实现成本和运营效率的最大化，但您的业务领域或现实情况可能要求您做出妥协，这些妥协将影响您选择部署模型的思路。如果您的业务利润率非常紧张，您可能会更倾向于选择那些能从部署模型中榨取每一分成本效率的部署模型。而其他企业可能面临合规或性能方面的挑战，这可能导致选择在成本与客户需求之间寻求平衡的部署模型。

这些只是您在确定哪种部署模型能满足业务核心需求时，需要经历的基本思考过程中的简单示例。随着我深入探讨多租户部署的细节，架构模式中，你会发现越来越多的场景中，多租户架构策略的细微差别将为部署模型图增添更多维度。这也将帮助你更好地理解这些模型差异如何影响底层解决方案的复杂性。每种部署模型的本质都可能将复杂性从系统的一个领域转移到另一个领域。

关键在于，你不应寻求一种通用的部署模型来适用于你的应用程序。相反，你应该从业务需求、客户需求和商业目标出发，反向推导出满足这些需求的组合，从而找到与当前及未来目标相匹配的部署模型。

此外，需注意SaaS环境的部署模型会随时间演进。虽然架构中部分核心要素可能保持相对稳定，但您应预期并主动寻找基于客户需求变化、市场动态及新业务策略调整，进一步优化部署模型的机会。无需过分追求初始部署的完美，而是要预期通过环境数据持续发现优化部署模型的机会。例如，最初作为专用资源的资源可能因使用量、扩展性和成本考量而转为共享资源。新增的层级可能要求部分系统组件采用专用部署模式。以数据为驱动并具备适应性，正是多租户技术体验的核心要素。

介绍专用和共享模型

在探讨部署模型时，我们将发现这些模型需要引入新的术语，以更精准地描述SaaS架构构造。这与我们之前探讨的“多租户”概念需要扩展其含义以适应SaaS业务现实的情况相呼应。现在，当我们开始探讨部署模型时，你会发现我们仍然需要一些术语，以更好地捕捉和准确传达在多租户架构中，资源如何被租户消费。

在此，我将引入两个术语，以更细粒度的方式分类专用资源与共享资源。在本书的其余部分，我将使用“孤岛”（silo）一词代指将资源分配给特定租户的专属模型。而“池”（pool）则用于描述租户资源被一个或多个租户共享的模型。这可能看起来只是语言上的细微差别。实际上，它对描述多租户架构具有重要意义。它使我们能够在不带多租户标签的模糊性和历史包袱的情况下，描述SaaS架构资源的行为和范围。随着我们进一步探讨部署模型以及贯穿本书的SaaS架构概念，我将使用“孤岛”和“池”作为基础术语，来描述多租户架构中资源的使用、部署和消费方式。

为了帮助澄清这一概念，让我们看一个包含以专用和共享模式组合消费资源的概念架构。图3-2展示了部署到SaaS架构中的一系列微服务。在此示例中，我创建了一个假设环境，其中一系列微服务采用不同的策略来专用和共享租户资源。

图3-2

在图3-2的顶部，您会看到我放置了两个租户，以示我们在环境中如何部署租户并使其消费资源。这些租户正在运行一个通过产品，订单和发票微服务实现的电子商务应用程序。现在，如果我们从左到右依次跟踪这些微服务的路径，您将看到我们为每个微服务应用了不同的部署策略。

首先来看产品微服务。对于该服务，我选择了将所有租户的计算和存储资源部署在池模型中的策略。在此场景下，我认为该服务的隔离性和性能特征与池部署模式的价值最匹配。当我们转向订单微服务时，你会发现我选择了完全不同的模型。在此场景中，每个租户的计算和存储均被隔离。同样，这一决策基于环境的具体需求，可能是出于服务级别协议（SLA）要求，也可能是合规性需求。

从订单服务中，您会看到系统向一个队列发送消息以准备这些订单进行计费。此场景被纳入以强调我们的隔离和池化概念不仅限于微服务，还扩展到环境中的任何资源。为此，我选择为每个租户使用隔离的队列。最后，右侧有一个发票服务，从这些队列中拉取消息并生成发票。为了满足解决方案的要求，我在这个微服务中混合使用了孤岛和池化模型。在这里，计算资源是池化的，而存储资源是孤岛的。

关键要点是，“隔离”和“池化”这两个术语用于一般性地描述一个或多个资源的架构占用范围。这些术语可以以非常细粒度的形式应用，突出显示租户如何映射到架构中的特定元素。这些术语也可以更广泛地用于描述为租户部署的一组资源，因此不要试图将“隔离”和“池化”映射到特定的构造。相反，应将其视为描述单个资源或一组资源的租户属性。这一注意事项在我们本章后续探讨部署模型时尤为重要，它将使我们能够在多租户架构的不同范围内部署隔离区和池的概念。

全栈隔离部署

现在您已经对部署模型的范围和作用有了高层次的理解，是时候深入探讨并开始定义特定类型的部署模型了。让我们从我将标记为“全栈孤岛部署模型”开始。正如其名，全栈孤岛模型将每个租户置于一个所有资源完全隔离的环境中。图3-3展示了一个全栈孤岛环境的示例。在此环境中，我们有一个应用程序层，为两个租户运行工作负载。这两个租户在各自的孤岛中运行，计算、存储以及租户所需的所有资源均部署到某个逻辑结构中，从而在租户之间建立清晰的边界。

图3-3

在此示例中，我简化了孤岛内的内容，展示了每个租户环境中运行的微服务范围。实际上，孤岛内可能包含任何数量的不同技术和设计策略。这可能是一个具有独立Web、应用程序和存储层的分层环境。我还可能包含任何数量的不同计算模型和其他服务（如队列、对象存储、消息传递等）。在此阶段，重点不在于每个租户环境中包含的内容，而在于它们的部署方式。

全栈孤岛模式的适用场景

全栈孤岛模型似乎与SaaS的反模式有些矛盾。毕竟，我们对SaaS的讨论大多围绕敏捷性和效率展开。在这里，当我们看到完全隔离的租户资源时，可能会觉得我们牺牲了SaaS的一些基本目标。然而，如果你回想一下第一章中对SaaS的定义，你会记得SaaS不仅仅是通过共享基础设施来实现规模经济。SaaS是一种运营模式，其中所有租户都是集体运营、管理和部署的。这是在考虑全栈孤岛模型时需要牢记的关键点，这一点至关重要。是的，它确实存在效率挑战。我们稍后会详细探讨。但只要每个环境完全一致，且运行的是应用程序的同一版本，我们仍能实现SaaS的大部分价值主张。

既然全栈孤岛模式符合SaaS的标准，那么真正的问题在于何时适合采用这种模式。哪些因素通常会促使组织选择全栈孤岛模式？它何时适合您业务和技术环境的现实情况？虽然没有绝对的答案，但存在一些常见主题和环境因素会引导团队选择全栈孤岛模式。合规性和遗留系统考虑是团队选择全栈孤岛架构的两个典型原因。在高度监管的领域，团队可能选择全栈孤岛模型以简化架构并更轻松地满足特定合规要求。这些领域的客户也可能对采用全栈孤岛模型产生影响，要求将孤岛资源作为选择SaaS解决方案的一部分。

全栈孤岛模型也适用于正在将传统解决方案迁移到SaaS的组织。该模型的完全孤岛化特性使这些组织能够在不进行重大重构的情况下，将现有代码迁移到SaaS模型。这使他们能够更快地迁移到SaaS，并减少了在架构迁移过程中立即为所有组件添加多租户功能的需求。迁移团队仍需对遗留环境进行改造，以使其与SaaS控制平面、身份模型以及其他多租户相关考虑因素保持一致。然而，如果解决方案迁移至无需考虑任何租户资源池化场景的全栈孤岛环境，这些影响的范围和程度将显著降低。

全栈孤岛也可作为分层策略。例如，部分组织可能提供解决方案的高级版本，通过支付相应费用，为租户提供完全专属的体验。需注意，这种专属体验并非为这些租户单独创建的独立环境，而是与系统其他层级共同运行同一版本的应用程序，并由中央系统统一管理。

在某些情况下，全栈模型仅仅代表了团队进入的较低门槛——尤其是那些不针对大量租户的团队。对于这些组织而言，全栈孤岛模式使他们能够在不处理构建、隔离和运营共享环境带来的额外复杂性的情况下，快速实现SaaS化。当然，这些团队还需考虑全栈孤岛模型对业务快速扩展能力的影响。在这种情况下，全栈模式的初始优势可能被孤岛模型带来的低效和利润率影响所抵消。

全栈孤岛模型考量

选择全栈孤岛模型的团队需要考虑该模型带来的细微差别。这种方法确实存在优缺点，您在选择此类部署时应将其纳入考量。以下各节将详细分解与全栈孤岛部署模型相关的关键设计、构建和部署考量因素。

控制平面复杂性

如您所知，我曾将所有SaaS架构描述为包含控制平面和应用平面，其中租户环境位于应用平面，并由控制平面进行集中管理。如今，随着全栈孤岛模型的引入，您需要考虑全栈模型的分布式特性将如何影响控制平面的复杂性。

在图3-4中，您可以看到一个全栈孤岛部署的示例，该示例突出了构建和管理此模型时需要考虑的一些关键要素。由于我们的解决方案采用按租户隔离的模型运行，应用层必须支持每个租户的完全独立环境。与交互单一共享资源不同，我们的控制平面必须对这些租户隔离环境有所感知。这本质上增加了控制平面的复杂性，因为它现在必须能够管理这些独立环境。

图3-4

想象在该示例中实现租户接入流程。每个新租户加入环境时，必须完全预配置和配置其独立的租户环境。这也会增加任何用于监控和管理租户环境健康状况的工具的复杂性。您的控制平面代码必须知道每个租户环境的位置，并有权访问每个租户孤岛。您用于管理基础设施资源的任何运维工具也需要处理这些租户环境更大的、更分布式的足迹，这可能使故障排除和管理基础设施资源变得难以管理。您创建的用于集中化租户指标、日志和分析的工具也需要能够聚合来自这些独立租户环境的数据。应用程序更新的部署在这种模型中也更为复杂。您的DevOps代码需要将更新部署到每个租户隔离环境。

这里可能还存在其他复杂性。然而，核心问题是，全栈孤岛模型的分布式特性会影响控制平面体验的多个关键组件，带来在其他部署模型中可能不那么明显的复杂性。尽管这些挑战均可管理，但要为全栈孤岛环境创建一个完全统一的管理和运维视图，确实需要额外努力。

扩展影响

规模是全栈孤岛部署模型的另一个重要考虑因素。每次为每个租户provision独立基础设施时，都需要考虑该模型在添加更多租户时的扩展性。虽然全栈孤岛模型在拥有10个租户时具有吸引力，但当考虑支持数百或数千个租户时，其价值可能会开始削弱。对于任何规模庞大且租户数量众多的B2C环境，全栈孤岛模型均不实用。当然，架构的特性也会对这一决策产生影响。例如，若使用Kubernetes，关键在于Kubernetes的隔离结构（如集群、命名空间等）能否有效扩展。若为每个隔离租户使用独立的云网络或账户结构，则需考虑云服务提供商可能施加的限制与约束。

更广泛的主题是，全栈孤岛部署并非适合所有人。当我深入探讨具体全栈孤岛架构时，你会看到这种模型在扩展过程中会遇到重要瓶颈。更重要的是，即使你的环境能在全栈孤岛模型中实现扩展，你也可能发现存在一个临界点，此时全栈孤岛架构将变得难以管理。这可能削弱你整体的敏捷性和创新目标。

成本考量

成本也是采用全栈孤岛模型时需重点探索的关键领域。尽管可以通过措施限制孤岛环境的过度配置，但这种模型确实会限制您在SaaS环境中最大化规模经济效益的能力。通常，此类环境需要为每个租户配备大量专用基础设施，且在某些情况下，这些基础设施可能不存在闲置状态（即不产生成本）。对于每个租户，您将面临一些基础成本，即使系统无负载时也需承担。此外，由于这些环境不共享资源，无法通过将多个租户的负载分布在可根据所有租户负载动态扩展的共享基础设施上，从而获得效率提升。以计算资源为例，在孤岛环境中，计算资源可以动态扩展，但仅基于单个租户的负载和活动。这可能导致每个孤岛内部出现过度配置，以应对来自单个租户的突发需求。

通常，采用全栈孤岛模型的组织需要创建成本模型，以应对该模型带来的额外基础设施成本。这可能包括使用量计费与部分固定费用相结合的模式，也可能是直接提高订阅价格。关键在于，尽管全栈孤岛模型可能适合某些层级或业务场景，但仍需考虑该模型的孤岛特性如何影响SaaS环境的定价模型。

在成本公式中，我们还需考虑全栈孤岛模型对组织运营效率的影响。若您已构建了强大的控制平面并自动化了所有入驻、部署等环节，仍可为全栈孤岛模型打造丰富的运营体验。然而，这种模型本身存在一些固有复杂性，可能会为您的运营体验增加额外开销。这可能意味着您需要在支持该模型的员工和工具上投入更多资源，从而为您的SaaS业务带来额外成本。

路由考虑

在图3-4中，我还添加了一个概念占位符，用于表示应用程序层内的流量路由。在全栈孤岛架构中，您需要考虑如何根据租户上下文将流量路由到每个孤岛。虽然可以使用多种网络构造来路由这些负载，但您仍需考虑如何进行配置。您是否为每个租户使用子域名？是否会使用共享域名并在每个请求中嵌入租户上下文？您选择的每种策略都需要系统能够提取该上下文并路由租户到相应的孤岛。

此路由构造的配置必须完全动态。随着每个新租户被接入系统，您需要更新路由配置以支持将新租户路由到其对应的隔离区。虽然这并非特别困难，但这是在设计全栈隔离环境时需要仔细考虑的领域。每个技术栈都会为路由问题带来其独特的考虑因素。

可用性和影响范围

全栈孤岛模型在整体可用性和可靠性方面确实具有一些优势。在此模型中，每个租户位于独立的环境中，这有助于限制任何潜在运营问题的影响范围。孤岛模型的专用特性使您能够将某些问题限制在单个租户环境内。这无疑对服务可用性指标产生整体积极影响。

在孤岛环境中，新版本的发布行为也略有不同。与将发布内容同时推送给所有客户不同，全栈孤岛模型可能分批次向客户发布。这允许您在发布到整个用户群体前检测并恢复与部署相关的问题。当然，这也会复杂化可用性配置。由于需要分别向每个孤岛部署，您必须采用更复杂的发布流程，这在某些情况下可能损害解决方案的可用性。

更简单的成本归因

全栈孤岛模型的一个显著优势在于能够将成本分配给单个租户。如第14章所示，在SaaS环境中，由于部分或全部租户资源可能被共享，计算多租户环境中的每租户成本较为复杂。在资源池环境中，准确判断某个租户消耗了多少共享数据库或计算资源并不容易。然而，在全栈孤岛模型中，您无需面对这些复杂性。由于每个租户都拥有独立的基础设施，将成本汇总并映射到各个租户变得相对简单。云服务提供商和第三方工具通常擅长将成本映射到特定基础设施资源，并为每个租户计算成本。

实际应用中的全栈孤岛模型

现在我们对全栈孤岛模型有了基本了解，让我们看看一些在实际架构中实现该模型的示例。如您所想，跨不同云服务提供商、技术栈等环境实现该模型的方式多种多样。每种技术栈的细节都会为设计和实施带来额外考量。您选择的技术和策略来实现全栈孤岛模型，很可能受到上述部分因素的影响。它们也可能受到您的技术栈属性和领域现实的塑造。

租户独立账户模型

若您在云环境中运行应用程序——这正是许多SaaS应用的常见部署场景——您会发现云服务提供商都设有账户机制。这些账户代表着实体（组织或个人）与其所使用基础设施之间的绑定关系。虽然账户涉及计费和安全维度，但本文重点探讨的是如何利用账户对基础设施资源进行分组管理。

在此模型中，账户通常被视为租户之间可建立的最严格边界。对某些人而言，这使得账户成为全栈孤岛模型中每个租户的天然归属。账户机制使每个租户环境的孤岛都能被云服务商用于隔离客户账户的所有机制所包围和保护。这大大降低了您在SaaS环境中实现租户隔离所需投入的精力和成本。在全栈孤岛模型中采用“每个租户一个账户”的方案时，这种隔离效果几乎是自然而然产生的附带效益。

在按租户计费的模式下，将基础设施成本分配给各个租户的过程也变得简单得多。通常，云服务提供商已具备在账户层面追踪成本所需的所有内置机制，因此采用按租户计费模式时，您只需借助这些现成的解决方案，即可将基础设施成本分配给每个租户。虽然您可能需要额外工作将这些成本汇总为统一视图，但整合成本数据的过程相对简单明了。

在图3-5中，我展示了按租户划分的账户架构视图。您会看到我呈现了两个完整的孤岛式租户环境。这两个环境是镜像对称的，作为克隆环境配置，运行着完全相同的基础设施和应用服务。当应用任何更新时，这些更新将统一应用于所有租户账户。

在每个账户中，您将看到为支持SaaS应用需求而可能部署的基础设施与服务示例。其中包含代表解决方案功能支持服务的占位符。在这些服务右侧，我还添加了租户环境中使用的额外基础设施资源，具体包括对象存储（S3）和托管队列服务（SQS）。对象存储可能存放全局资产，队列则用于支持服务间的异步消息传递。添加这些组件旨在强调：我们的租户独立账户隔离模型通常会封装所有必要的基础设施，以满足特定租户的需求。

图3-5

现在的问题是：这种模型是否意味着租户账户之间无法共享基础设施资源？例如，这两个租户能否在各自独立的账户中运行所有微服务，同时共享对集中式身份提供商的访问权限？这种做法并不违背逻辑。您在此处的选择取决于业务/租户需求与跨账户资源访问复杂性的综合考量。

在此处的决策应始于评估全栈孤岛模型的初衷。您选择该模型是基于客户期望其全部基础设施与其他租户完全隔离的预期，还是更多出于规避邻居噪音问题和满足数据隔离需求？对这些问题的回答将显著影响您在此模型中如何共享基础设施的各个部分。

若您的代码需要访问账户外的资源，将面临全新挑战。任何外部访问的资源都需在其他账户范围内运行，而账户间通常存在明确且严格的边界以保障资源安全。因此您必须深入研究跨账户访问授权机制，才能使系统与租户账户外的资源进行交互。

通常我建议坚持全栈孤岛模型的核心假设：租户的所有资源应集中于同一账户。仅当存在符合全栈孤岛精神且具有充分理由的情况时，才应考虑如何支持集中化资源。

• 新租户的自动化接入。 租户独立账户隔离模型为新租户的接入流程增添了额外复杂性。如第四章将详细说明，每次接入新租户时，您需考虑如何自动化处理引入新租户时所需的所有资源预配置和配置。在租户独立账户模型中，我们的预配置不仅包括租户基础设施的创建，还涵盖新账户的创建。

  虽然账户创建确实存在自动化方案，但某些环节无法完全实现自动化。在云环境中，某些有意设置的限制可能阻碍您自动化配置或分配资源的能力——这些资源的配置可能超出其默认限制。例如，您的系统可能要求每个新租户账户配备特定数量的负载均衡器，但实际需求可能超出云服务商的默认配额。此时您需要通过人工流程（部分环节无法自动化）申请配额提升，以满足每个新租户账户的需求。这正是租户接入流程无法实现全自动化处理的关键环节。相反，您可能需要承受云服务商支持流程带来的部分摩擦。总体而言，许多资源的默认配额往往远低于有效扩展环境所需的实际需求。

  尽管团队会竭力建立清晰的新租户账户创建机制，但您仍需意识到：采用租户独立账户模式时，必须考量这些潜在限制问题可能对入驻体验造成的影响。这可能意味着需要调整入驻服务等级协议（SLA）的预期，并更好地管理租户对此流程的期望值。

• 扩展性考虑。 我已经提到了与全栈孤岛模型相关的典型扩展挑战。然而，在账户-租户模型中，全栈孤岛的扩展故事又增添了一层复杂性。

  总体而言，将账户映射到租户可被视为一种反模式。对于许多云服务提供商而言，账户最初并非专门设计为多租户SaaS环境中的租户容器。相反，SaaS提供商倾向于采用账户模型，因为它与他们的目标高度契合。从某种程度上说，这种设计确实合理。

  现在，如果你有一个拥有数十个租户的环境，你可能不会在基于租户的账户模型中感受到太多痛点。然而，如果你计划扩展到大量租户，你可能会开始遇到这个模型的瓶颈。你在这里面临的最基本问题是，你可能会超过云服务提供商支持的最大账户数量。更微妙的挑战会随着时间的推移逐渐显现。账户的激增最终可能削弱你的SaaS业务的敏捷性和效率。想象一下，在这个模型下运行数百或数千个租户。这将转化为一个庞大的基础设施足迹，你需要管理。虽然你可以采取措施尝试简化和自动化所有这些账户的管理和运营，但可能存在某个点，此时这已不再可行。

  那么，何时会达到临界点？我无法给出一个确切的数据点，因为这取决于租户基础设施的具体情况。我提到这一点主要是为了确保你在采用“每个租户一个账户”模型时，已将这一因素纳入考量。

租户独立虚拟私有云模型

租户独立租户模型依赖于一个相当粗粒度的边界。让我们将关注点转移到能够在单个账户范围内实现完整堆栈隔离的构造上。这将帮助我们克服为每个租户创建账户所面临的挑战。我们接下来要探讨的模型——租户虚拟私有云（VPC）模型——更依赖于网络构造来承载每个隔离租户的基础设施。

在大多数云环境中，您可访问丰富的虚拟化网络构造，用于构建、控制和保护应用环境的资源足迹。这些网络构造提供了实现全栈隔离的天然机制。网络的本质及其描述和控制资源访问的能力，为SaaS构建者提供了强大的工具集，可用于隔离租户资源。

让我们通过一个示例来看看如何利用一个网络构造实现全栈隔离模型。图3-6展示了一个使用亚马逊VPC隔离租户环境的网络环境示例。

图3-6

乍一看，这张图中有很多组件。虽然有点复杂，但我希望引入足够的网络基础设施，以便您更好地理解该模型包含的元素。

在图3-6中，我们有两个租户正在访问运行在不同VPC中的隔离应用服务。VPC是位于租户环境外层的边界。我还通过包含两个独立的可用区（AZ）来展示VPC的高可用性架构。我们不会深入探讨AZ，但需了解AZ是AWS区域内独立的物理位置，设计上可隔离其他AZ的故障。此外，我们通过独立的子网将解决方案的公共子网与私有子网进行隔离。最后，您会看到我们的应用服务部署在两个可用区内的私有子网中。这些服务被AWS称为自动扩展组所包围，该组可根据租户负载动态调整服务规模。

我详细说明了这些网络细节，旨在强调我们通过网络隔离模型运行租户，为每个租户提供独立且高可用性的网络环境，充分利用了基于租户独立虚拟私有云隔离模型构建和部署解决方案时所带来的虚拟化网络优势。

尽管该模型相较于“每个租户一个账户”模型看似更灵活，但其实它提供了一套强大的构造，可有效防止跨租户访问。这些网络工具的本质特性允许您对租户环境的入站和出站流量进行精细控制。我们在此不深入探讨具体实现，但可用的访问和流量控制机制列表非常丰富。

另一种偶尔出现的模型是“每个租户一个子网”模型。虽然我很少见到这种模型，但有些团队会将每个租户的隔离环境放置在特定子网中。当然，随着规模扩大，这种架构也可能变得难以管理。

值得注意的是，租户级VPC模型并不适用于所有AWS技术栈。例如，无服务器环境并不使用VPC来分组计算服务。事实上，在无服务器架构中，全栈隔离模型通常会部署一组完全独立的函数。我们在第11章探讨无服务器SaaS架构模式时，将进一步详细介绍这种方法。

• 入驻自动化。 在采用“每个租户一个账户”的模型时，我深入研究了其在自动化入驻流程中可能带来的挑战。而采用“每个租户一个VPC”的模型后，入驻流程会有所变化。好消息是，由于无需为每个租户单独创建账户，您将不会遇到相同的账户限制自动化问题。相反，假设运行我们VPC的单一账户已预留足够资源以支持新增租户。这仍可能需要一些专用流程，但这些流程可应用于入驻流程之外。

  在租户独立私有网络模型中，重点更多放在预配置VPC结构和部署应用程序服务上。这仍可能是一个繁重的过程，但您需要创建和配置的大部分内容都可以通过完全自动化的流程实现。

• 扩展性考虑。 与账户类似，VPC也会面临一些扩展性问题。正如账户数量存在限制一样，VPC的数量也可能受到限制。随着VPC数量的增加，其管理和运维复杂性也会随之提升。如果租户基础设施分散在数百个VPC中，可能会影响SaaS服务的敏捷性和效率。因此，尽管VPC具有一些优势，但您需要考虑将支持多少租户，以及租户每VPC模型是否适合您的环境。

保持全栈孤岛思维的一致性

在探讨新的部署模型之前，我们必须明确全栈孤岛模式中的核心原则。对于部分人而言，全栈孤岛模式看似能为SaaS提供商重新开启为租户提供一次性定制化的可能性。虽然全栈孤岛模型确实提供了专用资源，但这绝不应被视为回归按租户定制的借口。全栈孤岛仅用于满足领域、合规性、分层或其他业务需求，这些需求可能需要采用全栈孤岛模型。

在所有方面，全栈孤岛环境与共享环境均被视为等同。新功能发布时，将部署给所有客户。若需更改基础设施配置，该变更应应用于所有孤岛环境。若存在扩展策略或其他运行时行为规则，则根据租户层级进行应用。绝不应存在针对单个租户的策略。SaaS的核心价值在于通过集中管理和运营租户来实现敏捷性、创新性、可扩展性和效率。任何向一次性定制模型偏移的趋势都会使您偏离这些SaaS目标。在某些情况下，组织为追求效率而迁移到SaaS，最终却因一次性定制化而退化，这会削弱他们原本期望从真正SaaS模型中获得的大部分价值。

我始终强调的指导原则是，如何从全栈孤岛模型过渡到全栈池模型。我告诉团队，即使全栈孤岛是你的起点，也应以全栈池模型为目标构建解决方案。然后，将每个全栈孤岛视为池化环境中的一个实例，该实例恰好只有一个租户。这作为一种强制机制，使全栈孤岛环境能够继承应用于全栈池的相同价值。

全栈池模型

全栈池模型，顾名思义，标志着我们对全栈孤岛思维和机制的彻底转变。在全栈池模型中，我们将关注SaaS环境，其中所有租户的应用层资源均运行在共享基础设施模型中。

对于许多人来说，完全池化的环境与他们对多租户的传统认知相吻合。在此，重点在于实现规模经济、运营效率、成本优势以及更简单的管理模式，这些都是共享基础设施模型的自然副产品。我们共享的基础设施资源越多，就越能将这些资源的消耗与租户的活动相匹配。同时，这些新增的效率也带来了各种新的挑战。

图3-7展示了全栈孤岛模型的概念视图。我仍保留了控制平面，以明确其在任何SaaS模型中都是恒定的。图左侧为应用程序平面，其中包含所有租户共享的应用程序服务集合。应用程序平面顶部的租户均可访问并调用应用程序微服务及基础设施的操作。

在这种池模型中，租户上下文扮演了更为关键的角色。在全栈孤岛模型中，租户上下文主要用于将租户路由到其专属栈。一旦租户进入某个孤岛，该孤岛便知晓其内部所有操作均与单一租户相关联。然而，在全栈池模型中，这种上下文对每项操作的执行都至关重要。访问数据、记录日志、采集指标——所有这些操作在运行时都需要解析当前租户上下文才能成功完成任务。

图3-7

图3-8更直观地展示了租户上下文如何影响我们基础设施、运维及实现的各个维度，尤其是在池化模型中。该概念图强调了每个微服务在与数据、控制平面及其他微服务交互时，必须获取租户上下文并将其应用于相关操作。您将看到租户上下文在发送计费事件和指标数据到控制平面时被获取和应用。您将在调用下游微服务时看到它被注入。它还出现在我们与数据的交互中。

核心思想是：当存在共享资源时，该资源属于多个租户。因此，租户上下文在运行时用于为每个操作应用作用域和上下文。

公平地说，租户上下文在所有SaaS部署模型中都是有效的。孤岛模型同样需要租户上下文。这里的不同之处在于，孤岛模型在预配置和部署时就已知其与租户的绑定关系。例如，我可以将环境变量作为孤岛资源的租户上下文（因为其与租户的关系在运行时不会改变）。然而，共享资源在预配置和部署时是为所有租户准备的，必须根据处理的每个请求的性质来解析其租户上下文。

图3-8

随着我们深入探讨更多多租户实现细节，我们将发现隔离模型与池化模型之间的差异会对我们设计、部署、管理和构建SaaS环境的各个组件产生深远影响。

全栈池模型考虑因素

全栈池模型还带来了一系列可能影响您选择该模型的考虑因素。在许多方面，全栈池模型的考虑因素是全栈孤岛模型的自然对立面。全栈池模型无疑具有许多吸引SaaS提供商的优势。它同时也带来了共享基础设施带来的挑战。以下各节将重点阐述这些考虑因素。

规模

在多租户环境中，我们的目标是尽可能将基础设施资源消耗与租户活动相匹配。在理想情况下，系统在任意时刻仅分配足够的资源以满足当前租户施加的负载需求。不会存在任何过剩资源，这将使业务能够优化利润率，并确保新增租户不会导致成本激增，从而影响业务的盈利能力。

这是全栈资源池模型的理想状态。如果您的设计能够在全栈资源池中完全优化底层基础设施的扩展策略，您就实现了多租户的理想状态。这在实际中并不现实，但它是围绕全栈资源池模型的一种常见思维方式。现实是，为全栈资源池环境制定一个稳健的扩展策略非常具有挑战性。租户的负载往往在不断变化，新租户可能每天都在加入，因此昨天有效的扩展策略今天可能不再适用。通常发生的情况是，团队会接受一定程度的过度配置以应对这个不断变化的目标。

您选择的技术栈也会对全栈池环境的扩展动态产生重大影响。在第11章中，我们将探讨无服务器SaaS架构，并深入了解如何通过采用无服务器技术简化扩展流程，实现基础设施消耗与租户活动之间的更好对齐。

尽管全栈池模型在扩展方面具有显著优势，但将这种扩展能力真正落地实现的难度不容小觑。您需要付出大量努力，制定一套既能优化资源利用率又不影响租户体验的扩展策略。

隔离

在全栈孤岛模型中，隔离是一个非常直观的过程。当资源以专用模式运行时，您自然会有一套构造，可确保一个租户无法访问另一个租户的资源。然而，当您开始使用共享资源时，隔离的实现会变得更加复杂。如何隔离被多个租户共享的资源？隔离如何在多租户架构中的不同资源类型和基础设施服务之间实现并应用？在第9章中，我们将深入探讨用于解决这些隔离细节的策略。然而，需要注意的是，采用全栈池化模型时，您将面临一系列新的隔离考量，这些考量可能影响您的设计和架构。假设池化模型的规模经济和效率可以抵消隔离池化资源带来的额外开销和复杂性。

可用性和影响范围

在许多方面，全栈池化模型代表了对一种模型的全面承诺，即将您业务中的所有租户置于一个共享环境中。在全栈池化环境中出现的任何故障或问题都可能影响所有客户，并可能对您的SaaS业务声誉造成潜在损害。行业内已有SaaS服务中断案例，引发社交媒体舆论风暴和负面报道，对相关企业造成长期影响。

在考虑采用全栈池模型时，您需要明确，这意味着您将承诺达到更高的DevOps、测试和可用性标准，以确保系统能够预防、检测并快速恢复任何潜在的系统中断。确实，每个团队都应设定较高的可用性标准。然而，全栈池环境中任何故障的风险和影响要求您更加关注确保团队能够提供零停机时间的体验。这包括采用最佳的持续集成/持续部署（CI/CD）策略，使您能够定期发布和回滚新功能，而不会影响解决方案的稳定性。

通常，全栈池团队会倾向于采用容错策略，使微服务和组件能够限制局部问题的影响范围。在此过程中，服务间异步交互、回退策略和隔离模式会被更广泛应用，以局部化并管理潜在的微服务故障。在全栈池环境中，能够主动识别并应用策略的运维工具也至关重要。值得注意的是，这些策略适用于所有SaaS部署模型。然而，在全栈池环境中，如果这些策略实施不当，对SaaS业务的影响可能更为显著。

噪音邻居

全栈池环境依赖于精心协调的扩展策略，以确保系统能根据租户的资源消耗活动有效地添加或移除容量。租户需求的动态变化以及潜在新租户的涌入意味着，当前的扩展策略可能无法适应未来需求。虽然团队可以采取措施尝试预测租户活动趋势，但许多团队发现自己不得不过度配置资源以创建缓冲区，以应对可能无法通过扩展策略有效处理的峰值。

每个多租户系统都必须采用能够预判峰值并处理所谓“噪声邻居”状况的策略。然而，在全栈池环境中，“噪声邻居”问题显得尤为突出。由于所有资源均被共享，这种状况发生的概率显著增加。您必须特别注意资源的规模和扩展配置，因为所有资源都必须能够成功应对租户消费活动变化。这意味着要考虑并采用防御性策略，确保单个租户不会占用系统资源导致其他租户的体验受到影响。

成本归因

在全栈池环境中，将成本与租户关联并进行跟踪是一项更为复杂的任务。虽然许多环境提供了将租户映射到特定基础设施资源的工具，但通常不支持将资源消耗归因于使用共享资源的具体租户的机制。例如，在多租户环境中，如果三个租户正在使用一个计算资源，我通常无法访问工具或机制来确定在特定时间点每个租户消耗了该资源的百分比。

我们将在第14章中详细探讨这一挑战在第14章中。全栈池化模型的效率也带来了理解单个租户成本足迹的新挑战。

运营简化

我之前提过，需要一个统一的操作和管理视图，以提供对多租户环境的整体视图。构建这种操作体验需要团队收集指标、日志和其他数据，并在集中式界面中展示这些信息。在全栈池环境中创建这些运营体验通常更为简便。在此环境中，所有租户运行在共享基础设施上，我可以更轻松地构建多租户环境的聚合视图。无需连接每个租户的独立基础设施，也无需为每个租户的特定资源创建数据发布路径到聚合机制。在全栈池环境中，部署也更为简便。发布微服务的新版本只需将该服务的实例部署到池环境中。部署完成后，所有租户均运行在新版本上。

示例架构

全栈池环境的架构相当简单明了。事实上，从表面上看，它与经典应用程序架构并没有太大区别。图3-9展示了一个在AWS架构中部署的完整池化架构示例。

我保留了全栈孤岛环境中许多相同的组件。环境网络中包含一个VPC，其中包含两个可用区以实现高可用性。在VPC内部，私有子网和公共子网分离了资源的外部和内部视图。最后，在私有子网中，您会看到各种微服务占位符，这些微服务负责应用程序的服务器端功能。这些服务采用池化模型部署存储，其计算资源通过自动缩放组实现水平扩展。当然，在顶层，我们还展示了该环境被多个租户使用的场景。

在这种细节级别下，您很难找到该架构中多租户的独特特征。实际上，这可能是几乎任何类型应用程序的架构。多租户并非以具体构造形式出现在全栈池化模型中，它仅在该环境中运行的运行时活动内部可见。通过此架构发送的每个请求都附带租户上下文。基础设施和服务必须在处理每个请求时获取并应用此上下文。

图3-9

例如，假设租户1发起一个请求，从存储中获取一个项。为了处理此请求，您的多租户服务需要提取租户上下文，并使用它来确定存储池中与租户1关联的项。在接下来的章节中，您将看到这种上下文如何对这些服务的实现和部署产生深远影响。不过，目前关键在于理解 全栈池模型更依赖于其运行时共享资源并按需应用租户上下文的能力。

这种架构只是全栈池模型的一种实现方式。每个技术栈（容器、无服务器、关系型存储、NoSQL存储、队列）都会影响全栈池环境的资源占用。全栈池的核心理念在大多数场景中保持一致。无论是在Kubernetes集群还是VPC环境中，该环境中的资源都会被池化，并需根据所有租户的总负载进行扩展。

混合全栈部署模型

到目前为止，我主要介绍了全栈孤岛和全栈池部署模型作为解决全栈问题的两种独立方法。可以将这两种模型视为解决一组相互对立的需求，几乎可以视为相互排斥的。然而，如果退一步考虑市场和业务现实，您会发现一些组织可能认为支持这两种模型都有价值。图3-10展示了一个混合全栈部署模型的示例。在此模型中，全栈孤岛和全栈池部署模型中的核心概念并列呈现。

图3-10

那么，为什么需要两种模型？采用这种方法的动机是什么？想象一下，你已经建立了自己的SaaS业务，并最初为所有客户提供全栈共享池模型（如左侧所示）。随后，在业务发展过程中，你遇到了一位对共享池模型感到不适的客户。他们可能担心邻居噪音问题，或对合规性问题感到担忧。此时，你并不一定需要屈从于每位提出异议的客户。这将削弱你作为SaaS企业所追求的核心价值。相反，你会努力帮助客户理解你所采用的安全性、隔离机制及策略，以满足他们的需求。这始终是销售SaaS解决方案的一部分。同时，也可能存在极少数特殊情况，你愿意为客户提供独立的全栈隔离环境。这可能是出于战略机会，也可能是某些客户愿意支付大额费用以证明提供全栈隔离选项的合理性。

在图3-10中，你可以看到混合全栈部署模型如何让你以混合方式解决这个问题。该图左侧是一个全栈池环境的实例。该环境支持大多数客户，我们在此示例中将这些租户标记为属于基础层体验。

对于要求更孤岛化体验的租户，我创建了一个新的高级层，允许租户拥有全栈孤岛环境。这里有两个运行自己栈的孤岛租户。假设这些租户连接到一个具有独立定价模型的高级层策略。

要使该模型可行，必须对允许在全栈隔离模型中运行的租户数量施加限制。如果隔离租户的比例过高，这将破坏整个SaaS体验。

混合模式部署模型

到目前为止，我主要关注的是全栈模型。虽然通过这些更粗粒度的模型来查看多租户部署具有吸引力，但现实是，许多系统依赖于一种更加细粒度的多租户方法，在整个SaaS环境的各个层面进行隔离和资源池化。这就是我们开始关注我所说的混合模式部署模型的地方。

混合模式部署避免了全栈模型带来的僵化的，不灵活的绝对性。相反，混合模式允许我们分析SaaS环境中的工作负载，并根据特定用例的需求，确定不同服务和资源应如何部署以满足具体要求。

让我们以一个简单的例子来说明。假设我在电子商务解决方案中有两个服务。其中一个是订单服务，它面临严苛的吞吐量要求且容易受到“噪音邻居”问题的影响。该服务同时存储数据，这些数据将显着增长并有严格的合规要求，这些要求在池化模型中难以支持。我还有一个用于管理产品评分的评分服务。它不面临显着的吞吐量挑战，可轻松扩展以满足租户需求——即使单个租户可能对服务施加不均衡的负载。其存储规模相对较小，且包含的数据不属于系统合规性配置文件范围。

在此情境下，我可以退一步，考量这些特定参数，以制定最符合这些服务需求的部署策略。在此，我可能选择将订单服务的运算资源与储存资源均进行孤立部署，并将评分服务的运算资源与储存资源进行整合。甚至可能出现服务的各个层级采用不同的孤立/整合策略。这正是我最初提出「孤立」与「整合」概念时所强调的核心要点。

计算和存储进行池化。甚至可能存在服务内部各层采用独立的隔离/池化策略的情况。这就是我在本章开头首次引入“隔离”和“池化”概念时所强调的核心要点。借助这种更细粒度的隔离与池化策略，您可以想象这将如何产生更加多样化的部署模型。考虑一个场景，您可能将此策略与分层模型结合使用，以定义多租户部署的足迹。

图3-11展示了在SaaS环境中如何采用混合模式部署模型。我展示了跨越基础层和高级层租户的多种不同部署体验。

图3-11

在该图的左侧，我们有基础层服务。这些服务涵盖了SaaS环境所需的所有功能。然而，您会注意到它们部署在不同的孤岛/池配置中。例如，服务1具有孤岛计算和池化存储。同时，服务2采用隔离计算和隔离存储。服务3至6均为池化计算和池化存储。我的思路是，根据池化租户的需求，以服务为单位，确定哪种隔离/池化策略最适合该服务的需求。

分层机制的实际应用体现在对高级租户的处理上。您会发现服务5和6在基础层部署，同时为高级租户单独部署。这是因为业务部门认为，对于这些服务，采用专用部署模式能为高级租户提供差异化价值，从而提升其系统体验。因此，对于每个高级层级租户，我们将创建服务5和6的新部署，以满足租户的分层要求。在此示例中，租户3是高级层级租户，其使用左侧的混合服务以及右侧的专用实例服务5和6。

以这种更细粒度的部署模型进行设计，能够为作为架构师的您以及业务部门提供极高的灵活性。通过在所有层级支持孤岛模型和池化模型，您可以灵活组合最适合的体验组合，以满足租户需求、运营需求以及解决方案生命周期中可能出现的其他需求。如果您有一个池化微服务存在性能问题，导致邻居噪声挑战，您可以将该服务的计算和/或存储进行孤岛化以解决此问题。如果您的业务希望以专用模式提供系统的一部分以支持新的分层策略，您将更容易实现这一转变。

这种混合部署模式通常是许多多租户构建者的理想选择。它使他们能够摆脱仅通过全栈解决方案视角解决问题的局限性，而全栈解决方案并不总是与业务需求完全契合。当然，始终存在采用全栈模型的解决方案。对于部分SaaS提供商而言，这可能是满足市场和客户需求的唯一途径。然而，也有案例可通过混合部署模式的优势解决这一需求，而无需将所有服务迁移至全栈孤岛。若仅将特定服务迁移至孤岛，同时保留部分低优先级服务在共享池中，仍可为业务带来显著价值。

Pod部署模型

到目前为止，我主要从如何通过孤岛和池化概念来表示应用程序的角度，探讨了部署模型。我们已经探索了在SaaS环境中以粗粒度和细粒度方式应用孤岛和池化模型的各种方法。我还需要跳出孤岛/池化的视角，思考应用程序可能需要支持的部署变体，这种变体更多地由其部署位置、如何处理环境约束，以及如何适应SaaS业务的规模和覆盖范围来决定。这就是pod部署模型发挥作用的地方。值得注意的是，Kubernetes也有自己对pod的定义，与本概念完全独立。

当我在此处提及“pod”时，指的是如何将一组租户划分为某个部署单元。我可能出于技术、运营、合规、扩展性或业务需求等原因，选择将租户部署到独立的pod中，这些pod进而成为我SaaS业务的部署、管理和运维单元。图3-12展示了pod部署的概念视图。

图3-12

在此pod部署模型中，您会注意到左侧存在相同的集中式控制平面。右侧包含用于表示支持一个或多个租户工作负载的独立环境的独立pod。在此示例中，租户1–3位于pod1，租户4–6位于pod2。

这些独立的Pod为SaaS环境带来了一定复杂性，需要您构建支持此分布式模型的控制机制。例如，租户接入流程必须考虑特定租户将落入哪个Pod。您的管理和运维也必须具备Pod感知能力，以便洞察每个Pod的健康状况和活动状态。

多种因素可能推动基于Pod的交付模式采用。设想在云端运行全栈池模型时，当租户数量达到特定阈值，某些服务的基础设施承载力将面临突破极限的风险。此时，突破限制的唯一途径可能是创建独立云账户来承载不同租户群体。这种需求也可能源于将SaaS产品部署至多地域的业务需求——地域限制或性能考量将促使企业采用基于Pod的部署模式，不同地域可能运行不同Pod。

某些团队可能还将Pod作为隔离策略，以减少跨租户影响。此举可能是出于对噪音邻居状况更强保护的需求，也可能在SaaS供应商的安全性和可用性方案中发挥作用。

若选择采用Pod模型，需考量其对业务敏捷性的影响。采用Pod模型意味着必须承担额外的复杂性与自动化需求——通过统一机制支持管理所有Pod，而非为每个Pod单独配置机制。要实现成功扩展，这些Pod的配置与部署必须通过控制平面实现全面自动化。若需变更，则该变更将统一应用于所有Pod。这与我之前阐述的全栈孤岛环境思维形成镜像——Pod不能被视为针对单个租户进行定制化的机会。

Pod带来的一个动态特性在于，将Pod内的成员关系视为可在租户生命周期内动态调整的要素。某些组织可能针对租户特征配置了专属的Pod方案，当租户特征发生变化，其规模或消耗模式与现有Pod不匹配时，即可考虑将其迁移至其他Pod。然而，将租户的全部资源占用迁移至新Pod需要大量工作。这并非日常操作，但某些SaaS团队会提供此类支持——尤其是那些针对特定体验进行精细调优的Pod。

尽管Pod在部署模型讨论中占据重要地位，但切勿将其视为应对多租户挑战的捷径。诚然，Pod模型能简化扩展、部署和隔离等方面的操作，但它同时引入的复杂性和低效性可能削弱SaaS的整体价值主张。例如，在此模型下您可能无法实现租户资源消耗与基础设施资源配置的最优匹配。相反，您可能会在系统支持的Pod集合中出现更多闲置或过度配置的资源实例，这将对SaaS业务的整体基础设施成本结构和利润率产生重大影响。