SaaS组织的动力来自于跨租户共享基础设施资源带来的规模经济。同时，现实世界中的一些因素可能会导致SaaS架构，其中环境中的一些或所有租户都需要专用的（孤立的）基础设施。法规遵从性、嘈杂的邻居、分层策略、遗留技术，这些都是您为租户提供自己的基础设施的首要考虑因素。这被称为孤立或全栈隔离SaaS。

这种方法经常被误认为是托管服务提供商（MSP），即公司的产品是为单个客户一次性安装和管理的。这种方法虽然有效，但并不符合SaaS原则。SaaS模式的关键是采用价值体系，所有租户都通过单一、统一的体验进行管理和运营。这意味着每个租户都在运行同一版本的软件，他们都在同一时间进行部署，他们都是通过同一流程登录的，他们都通过适用于所有租户的单一操作体验进行管理。

这种方法不能提供共享基础架构模型（池）的成本效率。它的分布式特性也会使操作和部署更加复杂。尽管如此，如果做得好，全栈模型仍然可以实现敏捷性、创新性和运营效率目标，这是SaaS思维的核心。

图7中的图表提供了完整堆栈隔离（筒仓）模型的更清晰视图。该模型中的每个租户环境都很简单。您将看到，我们为每个租户提供了一个单独的VPC。这些VPC包含每个租户将使用的完全隔离堆栈。计算和存储结构可以由AWS服务的任何组合组成。关键是每个租户环境都具有相同的基础结构配置和相同版本的产品。因此，添加新租户就像为每个租户提供具有相同基础设施占地面积的另一个VPC一样简单。

您还将注意到，该模型使用Amazon Route 53将传入流量路由到适当的VPC。路由依赖于将子域分配给每个租户的模型。这是SaaS环境中非常常见的模式。这种路由也可以通过检查租户JWT令牌的内容、确定其租户上下文以及通过注入的租户标头触发路由规则来实现。然而，这种方法可能会推高帐户限制，并且可能需要调整以解决租户身份的运行时解析的延迟问题。尽管如此，对于某些SaaS环境来说，它仍然是一个有效的选项。

图7：全堆（筒仓）隔离

虽然本示例说明了VPC每租户模型，但也有其他架构可用于实现全栈模型。一些组织可能选择使用每个租户的帐户模型，其中每个租户环境都部署在单独的配置帐户中。您选择的选项将根据您需要支持的租户数量和您所针对的总体管理经验而有所不同。在某些情况下，您需要支持的租户数量可能超过AWS帐户中可以创建的VPC数量。

统一的入职、管理和运营

当我们研究这种体验的入职、管理和运营时，全栈隔离（筒仓）模型的真正SaaS元素就出现了。为了实现SaaS的全部价值主张，该模型必须引入一组可用于管理和操作所有租户环境的服务。

图8中的图表提供了这些额外服务层的视图。我们在这里介绍的是一组完全独立的服务，这些服务是围绕SaaS提供商的管理和管理经验需求构建的。

图8：管理全栈隔离环境

虽然租户环境的堆栈是由域、遗留和其他需求形成的，但我们的管理经验的堆栈完全由目标和使用模式驱动，这些目标和使用方式可能与租户的目标和使用情况截然不同。

这种管理非常符合经典的无服务器SaaS应用程序模型。您将看到，我们的管理环境有两个切入点。一个是Admin应用程序，它使用AmazonCloudFront和AmazonS3来提供SaaS管理员用来管理和配置租户环境的应用程序体验。您还将看到这里突出显示的注册和API体验。这表示通过公共API请求触发租户登录的能力。该API也可以是SaaS提供商的开发者API体验的一部分。

最后，我们还强调了一组微服务，它们代表了用于协调入职、管理和运营体验的共享服务。基于Lambda的管理、规模和成本效率模型，我们选择Lambda作为微服务的模型。这些服务可以与其他AWS计算服务一起实现。

在图的右侧，您将看到代表每个租户环境的各个VPC。在这个VPC每租户模型中，您需要为管理平面打开一个有效路径，以便能够配置和访问这些租户环境的资源。AWS为此提供了许多选项，包括AWS PrivateLink、VPC对等和Amazon EventBridge。您选择的选项将取决于您正在建立的管理经验的性质。

架构良好的框架确定了一组通用设计原则，以促进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基础架构的成本状况之间的更紧密的协调。

限制开发人员对多租户概念的了解：

限制开发人员对多租户概念的了解：虽然租户将在架构的各个层中流动，但您的目标应该是限制开发人员接触租户的程度。根据经验，开发人员编写多租户服务的经验不应与编写没有租户概念的服务有任何不同。如果开发人员需要在其代码中引入租户，这将使管理和强制遵守应用程序的多租户策略和机制变得困难。这意味着向开发人员提供隐藏租赁细节的库和可重用构造。

SaaS是一种业务战略，而不是技术实现：

SaaS是一种业务战略，而不是技术实现：SaaS环境及其底层技术选择直接取决于业务的灵活性、创新和竞争需求。这里的重点和思维集中在为客户创造服务体验上，该服务体验注重零停机、定期更新和与客户的紧密联系。这意味着设计一个架构和运营足迹，以促进持续发展和快速响应市场需求。一个无法实现敏捷性、创新性和运营效率的技术上可靠的架构不太可能跟上市场的竞争格局，尤其是如果您与其他SaaS提供商竞争的话。

创建租户感知的运营视图：

创建租户感知的运营视图：在多租户环境中，运营团队面临一系列新的挑战。尽管在SaaS环境中，对系统的运行状况和活动进行全局查看仍然很重要，但稳健的SaaS运营足迹还将包括对特定租户或租户层如何运行系统的深入了解。SaaS运营团队应构建仪表板和视图，使其能够分析和描述单个租户的活动和负载。能够通过单个租户的视角查看和排除使用情况，对于构建主动、高效的多租户运营体验至关重要。

衡量单个租户的成本影响：

衡量单个租户的成本影响：SaaS公司的业务、架构师和运营团队通常需要清楚了解租户如何影响SaaS环境的成本足迹。例如，基本层租户的成本是否高于高级层租户？租户的消费模式或功能是否会改变您环境的成本状况？这些问题最好通过清晰了解租户成本概况来回答。在租户资源由多个租户共享的环境中，这一点尤其重要。收集和呈现这些数据通常为SaaS业务提供有价值的见解，这些见解可以塑造SaaS公司的架构和业务模型。

对于许多SaaS提供商来说，Amazon Elastic Kubernetes Service（Amazon EKS）的简介非常符合他们的微服务开发和架构目标。它提供了一种构建和部署多租户微服务的方法，可以帮助他们实现其灵活性、规模、成本和运营目标，而不需要完全改变开发工具和思维方式。丰富的Kubernetes工具和解决方案社区还为SaaS开发人员提供了一系列不同的选择，用于构建、管理、保护和操作其SaaS环境。

对于基于容器的环境，架构的大部分重点是如何成功地确保我们防止跨租户访问。虽然允许租户共享集装箱是一种诱惑，但这意味着租户可以接受软多租户的概念。然而，对于大多数SaaS环境，隔离需求需要更健壮的隔离实现。

这些隔离因素可能会对亚马逊EKS构建的架构模型产生重大影响。使用亚马逊EKS建立SaaS架构的一般指南是防止租户之间共享容器。虽然这增加了架构占地面积的复杂性，但它解决了确保我们创建了一个隔离模型以满足多租户客户的领域、法规遵从性和监管需求的基本需求。

让我们看一个示例架构，以了解SaaS Amazon EKS环境的基本元素。由于这个解决方案有很多移动的部分，让我们先来看看用于支持跨越所有租户的核心水平概念的共享服务（如图4所示）。

首先，您会注意到，我们拥有任何高度可用、高度可扩展的AWS架构的基础元素。该环境包括一个由三个可用区域组成的VPC。来自租户的入站流量路由由Amazon Route 53管理，该路由被配置为将传入的应用程序请求引导到NGINX入口控制器定义的端点。控制器在我们的AmazonEKS集群中启用所选路由，这对于您将在下面看到的多租户路由至关重要。

图4：Amazon EKS SaaS共享服务架构

AmazonEKS集群中运行的服务代表了一些常见服务的示例，这些服务通常是SaaS环境的一部分。注册用于协调新租户的入职。租户管理管理系统中所有租户的状态和属性，并将这些数据存储在AmazonDynamoDB表中。用户管理提供了添加、删除、启用、禁用和更新租户的基本操作。它管理的身份存储在Amazon Cognito中。还包括AWS CodePipeline，以表示用于为系统上的每个新租户提供服务的工具。

此架构仅代表SaaS环境的基本元素。我们现在需要看看将租户引入这一环境意味着什么。考虑到前面描述的隔离考虑，我们的AmazonEKS环境将为每个租户创建单独的命名空间，并保护这些命名空间，以确保我们拥有一个健壮的租户隔离模型。

图5：在Amazon EKS中部署租户环境

图5中的图表提供了SaaS架构中这些名称空间的视图。从表面上看，这个架构与之前的基线图非常相似。关键区别在于，我们将作为应用程序一部分的服务部署到了单独的命名空间中。在本例中，有两个租户具有不同的名称空间。在每项服务中，我们都部署了一些示例服务（订单和产品）。

每个租户名称空间都由上面显示的注册服务提供。这将使用连续交付服务（如AWS CodePipeline）启动创建命名空间、部署服务、创建租户资源（数据库等）和配置路由的管道。这就是入口控制器发挥作用的地方。每个配置的命名空间为该命名空间中的每个微服务创建一个单独的入口资源。这使租户流量能够路由到适当的租户命名空间。

虽然名称空间允许您在AmazonEKS集群中的租户资源之间有清晰的边界，但这些名称空间更多的是一种分组构造。仅使用命名空间无法确保租户负载免受跨租户访问。

为了增强AmazonEKS环境的隔离性，我们需要引入不同的安全构造，以限制在给定命名空间中运行的任何租户的访问。图6中的图表提供了控制每个租户体验的方法的高级说明。

图6：隔离租户资源

这里介绍了两种特定的构造。在命名空间级别，您将看到我们创建了单独的pod安全策略。这些是可以附加到策略的本地Kubernetes网络安全策略。在本例中，这些策略用于限制租户命名空间之间的网络流量。这表示一种粗粒度的方式，以防止一个租户访问另一个租户的计算资源。

除了保护命名空间之外，还必须确保命名空间中运行的服务访问的资源受到限制。在这个例子中，我们有两个隔离的例子。Order微服务使用每个租户的表模型（思洛存储器），并具有限制特定租户访问的IAM策略。Product微服务使用混合租户数据的池模型，并依赖于应用于每个项目的IAM策略来限制租户访问。

在多租户环境中运行的微服务必须解决其他问题。这些微服务必须能够在每个服务中引用和应用租户上下文。同时，我们的目标也是限制开发人员在代码中引入租户意识的程度。

为了实现这一目标，SaaS微服务无论其计算模型如何，都应该引入库、模块和共享结构，以将租户特定的处理推送到代码中。这些构造隐藏了解析和应用租户上下文所需的策略和机制。

图10中的图表展示了如何简化微服务的多租户开发。这里的关键思想是，我们采取了任何依赖租户上下文的方法，并使用了库来应用多租户策略。

这个示例说明了SaaS微服务可能需要访问租户上下文的许多场景。流程从调用微服务开始，请求获取产品列表。在我们服务的代码中，您的服务会记录一条消息。微服务开发人员只需将消息记录到日志包装器中。这个包装器从令牌管理器获取租户上下文，并将该上下文注入到我们的消息中，在本例中，该消息发布到AmazonS3。我们的日志策略以及租户数据在日志中的登录方式由我们选择包含在日志助手中的任何策略管理。

这一主题在这里的其他体验中继续。我们对getProducts（）的调用首先从令牌管理器获取租户标识符。然后，它使用此上下文从隔离管理器获取租户范围的凭据，然后使用这些凭据从DynamoDB获取产品数据。

图10：开发多租户微服务

最后，我们的服务使用解析租户标识符和将租户上下文注入度量消息的相同机制来记录度量（可能是执行时间）。

这里概述的实践并不是要将重量级的构造引入到微服务中。这种租赁的抽象遵循将公共概念推入共享代码的一般设计实践。需要注意的是，图中表示的所有概念都在单个微服务的上下文中运行。这些块中的每一个都简单地表示微服务重用的代码。将这些概念分解为单独的服务会增加延迟和复杂性，这通常是不合理的。

向SaaS交付模式的转变伴随着最大化成本和运营效率的愿望。在租户活动难以预测的多租户环境中，这尤其具有挑战性。找到一种将租户活动与实际资源消耗相结合的扩展策略是很难的。今天有效的策略明天可能行不通。

这些特性使SaaS非常适合无服务器模式。通过从SaaS架构中删除服务器的概念，组织能够依靠托管服务来扩展和交付应用程序所消耗的精确数量的资源。这简化了应用程序的体系结构和操作足迹，无需继续跟踪和管理扩展策略。这也降低了运营开销和复杂性，将更多的运营责任推给了托管服务。

AWS提供了一系列可用于实现无服务器SaaS解决方案的服务。图1中的图表提供了一个无服务器体系结构的示例。

图1：无服务器SaaS架构

在这里，您将看到无服务器SaaS体系结构的移动部分与经典的无服务器web应用程序体系结构没有什么不同。在这个图的左侧，您可以看到我们的web应用程序是由AmazonS3存储桶托管和提供服务的（可能使用了React、Angular等现代客户端框架之一）。

在此架构中，应用程序利用Amazon Cognito作为我们的SaaS身份提供商。这里的身份验证体验产生了一个令牌，其中包括通过JSON Web令牌（JWT）传递的SaaS上下文。然后将此令牌注入到我们与所有下游应用程序服务的交互中。

与我们的无服务器应用程序微服务的交互是由AmazonAPI网关协调的。网关在这里扮演多个角色。它验证传入的租户令牌（通过Lambda授权器），将每个租户的请求映射到微服务，并可用于管理不同租户层的SLA（通过使用计划）。

您还将看到，我们在这里表示了一系列微服务，它们是实现SaaS应用程序的多租户IP的各种服务的占位符。这里的每个微服务都是由一个或多个实现微服务契约的Lambda函数组成的。根据微服务的最佳实践，这些服务还封装了它们管理的数据。这些服务依赖于传入的JWT令牌来获取和应用租户上下文。

我们还展示了每个微服务的存储。为了符合微服务最佳实践，每个微服务都拥有其管理的资源。例如，一个数据库不能由两个微服务共享。SaaS在这里也增加了一个问题，因为数据的多租户表示可以根据服务的不同而变化。一个服务可以为每个租户（思洛存储器）提供单独的数据库，而另一个服务可能将数据合并到同一个表（池）中。您在这里所做的存储选择是由法规遵从性、噪声邻居、隔离和性能考虑因素决定的。

最后，在图的右侧，您将看到一系列共享服务。这些服务提供了图左侧运行的所有租户共享的所有功能。这些服务代表通常作为独立的微服务构建的公共服务，这些服务是机载、管理和运营租户所需的。

有关一般无服务器良好架构的最佳实践的更多信息，请参阅无服务器应用程序镜头白皮书。

每个SaaS架构还必须考虑如何防止租户访问另一个租户的资源。有些人怀疑是否需要使用AWS Lambda隔离租户，因为根据设计，在给定的时间内，只有一个租户可以运行Lambda功能。虽然这是正确的，但我们的隔离还必须考虑确保运行函数的租户不访问可能属于另一个租户的其他资源。

对于SaaS提供商，在无服务器SaaS环境中实现隔离有两种基本方法。第一个选项遵循筒仓模式，为每个租户部署一组单独的Lambda函数。使用此模型，您将为每个租户定义一个执行角色，并为每个租户部署单独的功能及其执行角色。此执行角色将定义给定租户可以访问哪些资源。例如，您可以在此模型中部署一组高级租户。然而，这可能很难管理，并且可能会遇到帐户限制（取决于系统支持的租户数量）。

这里的另一个选项更符合池模型。在这里，函数部署了一个执行角色，该角色的范围足够大，可以接受来自所有租户的调用。在此模式下，您必须在运行时在多租户函数的实现中应用隔离范围。图2中的图表提供了如何解决这一问题的示例。

图2：无服务器环境中的隔离

在本例中，您将看到我们有三个租户访问一组Lambda函数。因为这些功能是共享的，所以部署它们的执行角色覆盖所有租户。在这些功能的实现中，我们的代码将使用当前租户的上下文（通过JWT提供）从AWS安全令牌服务（AWS STS）获取一组新的租户范围的凭据。一旦我们有了这些凭据，就可以使用它们访问具有租户上下文的资源。在本例中，我们使用这些作用域凭据来访问存储。

需要注意的是，这个模型确实将隔离模型的一部分推到了Lambda函数的代码中。有一些技术（例如函数包装器）可以将这个概念引入开发人员的视野之外。获取这些证书的细节也可以转移到Lambda层，以使其成为一个更无缝的、集中管理的构造。

任何SaaS架构的目标之一都是限制开发人员对租户细节的了解。在无服务器SaaS环境中，您可以使用Lambda层作为创建共享代码的一种方式，该代码可以在开发人员的视野之外实现多租户策略。

图3中的图表提供了如何使用Lambda层来解决这些多租户概念的示例。在这里，您将看到我们有两个单独的微服务（Product和Order），它们需要发布日志和度量数据。这里的关键细节是，这两个服务都需要将租户上下文注入其日志消息和度量事件中。然而，让每个服务自己实现这些策略并不理想。相反，我们引入了一个层，其中包含管理数据发布的代码。

图3：Lambda层隐藏租户细节

您将注意到，我们的层包括接受JWT令牌的日志记录和度量帮助器。这使得每个微服务都可以简单地调用这些函数并提供令牌，而不必担心与哪个租户合作。然后，在该层中，代码使用JWT令牌解析租户上下文，并将其注入日志消息和度量事件中。

这只是如何应用层来隐藏租户上下文的一个片段。真正的价值是，注入租户上下文的策略和机制从开发人员体验中完全删除。它们还分别更新、版本化和部署。这允许在您的环境中更集中地管理这些策略，而无需引入可能增加延迟并造成瓶颈的单独微服务。

SaaS环境中客户的需求可能因企业而异。虽然构建一个所有客户都在共享基础架构模型（池）中运行的SaaS解决方案具有显著的成本和运营优势，但有时客户可能不愿意与其他租户共享基础架构资源。

对于SaaS提供商来说，一次性客户拥有自己的环境可能是一个挑战。虽然SaaS提供商感到支持这种模式的业务压力，但他们也知道支持这种性质的变化会破坏业务的总体SaaS目标。每个新的一次性客户都会增加运营开销和复杂性。随着每个新客户都加入到这个模型中，您很快就会发现自己离共享基础架构模型带来的创新、灵活性和成本效益越来越远。

然而，有一些架构和运营策略可以在不完全损害您的SaaS愿景的情况下采用这种模式。图9中的图表提供了一个概念视图，说明了如何应对这一挑战。

图9：混合部署模型

在这个图中，您将注意到我们的SaaS环境有两个单独的部署。左侧部署在具有共享基础结构的池模型中。我们的大多数租户都在这样的环境中运营。然而，在右侧，我们部署了托管一个租户（租户4）的多租户环境的单独副本。

该策略的关键在于，两个环境（左侧和右侧）都运行相同版本的SaaS应用程序。任何新的更改或更新都将同时应用于两个环境。更重要的是，您将看到我们拥有跨越这两种环境的单一、统一的管理经验。登录、身份、计量和计费对两种环境都是共享的。

这种共享的经验允许SaaS组织通过一块玻璃来管理和操作这些环境。通过将这些一次性租户纳入此模型，您可以将对SaaS环境的整体灵活性和运营效率的影响降至最低。该模型影响了成本效率并增加了运营复杂性。然而，对于许多SaaS公司来说，这可能是一种合理的妥协。

随着公司进入多租户模式，捕获和呈现租户如何使用应用程序的洞察变得越来越具有挑战性。租户共享的SaaS环境资源尤其如此。

同时，由于您的所有租户都可能在一个共享环境中运行，因此能够清晰地了解租户的活动和消费情况对于构建强大的SaaS产品至关重要。了解租户正在使用的产品的哪些功能，了解租户如何推动您的环境的架构，以及了解租户的不同层是如何扩展的，这些都是SaaS公司能够有效运营健康SaaS业务所需的见解。

SaaS度量的范围有意宽泛。这是因为SaaS组织中的不同角色在多个上下文中使用度量。这意味着您需要考虑基础设施健康之外的问题。SaaS指标通常包括业务敏捷性、功能消耗、微服务活动、扩展趋势等。其目的是捕获租户和层使用趋势并将其与应用程序和消费活动相关联。

您可以想象为使用这些数据的不同角色设置各种仪表板。例如，产品经理可能希望深入了解面向功能的度量。同时，运营人员可能会使用这些数据来评估各个租户和层的健康和消费趋势。

图11：摄取和可视化SaaS指标

捕获和显示这些数据的架构相对简单。它包括传达、发布、摄取、聚合和可视化这些SaaS度量所需的所有机制。图11中的图表提供了可用于在AWS上构建SaaS度量环境的架构视图。

您要捕获的度量数据的来源可能有些不同。如图所示，您的解决方案可能需要从本地AWS源（例如CloudWatch）捕获一些度量。然而，这些数据的很大一部分将来自您在SaaS应用程序中插入的代码。正是在这里，您希望投资于发布最能捕捉洞察的指标，以最大化域数据的业务和运营价值。

这些来源的数据通常用一个通用模式表示，该模式可以表示应用程序中的不同消费类型（计数、持续时间、功能等）。在本例中，这些数据由Amazon Kinesis data Firehose获取，后者将数据发布到Amazon Redshift。最后，AmazonQuickSight用于构建不同的仪表板，这些仪表板用于整个组织，以查看租户和层的趋势。

AWS良好架构框架基于六大支柱：卓越运营、安全性、可靠性、性能效率、成本优化和可持续性。SaaS为这些支柱中的每一个增加了新的考虑因素。SaaS应用程序的多租户性质要求架构师重新考虑如何解决其SaaS环境的安全性、运营效率、稳定性和灵活性。在本节中，我们将概述本文档中使用的SaaS概念。在构建SaaS架构时，您应该考虑10个方面。

话题

• 租户
• 筒仓、水池和桥梁模型
• SaaS身份
• 租户隔离
• 数据分区
• 吵闹的邻居
• 租户入职
• 租户层级
• 租户活动和消费
• 租户感知操作

租户

租户是SaaS环境的最基本结构。作为构建应用程序的SaaS提供商，您正在向客户提供此应用程序。注册使用环境的客户表示为系统的租户。例如，假设您的组织创建了一个会计服务，您希望其他公司可以使用您的服务来管理其业务。这些公司中的每一家都将被视为系统的租户。

注册后，租户通常会为租户管理员提供用户信息。然后，租户管理员可以登录到系统，并根据其业务需求进行配置。这包括能够将用户添加到给定的租户环境。

该模型中提供的软件被称为多租户SaaS系统，因为服务的每个租户都使用一个单一的共享系统，该系统通过统一的体验支持这些租户的需求。例如，系统的更新通常应用于该系统的所有租户。

筒仓、水池和桥梁模型

SaaS应用程序可以使用各种不同的架构模型构建。监管、竞争、战略、成本效率和市场考虑因素都会对SaaS架构的形状产生一定影响。同时，在定义SaaS应用程序的足迹时，会应用一些策略和模式。这些模式分为三类：筒仓、桥梁和水池。

筒仓模型

筒仓模型是指为租户提供专用资源的体系结构。例如，设想一个SaaS环境，系统的每个租户都有一个完全独立的基础架构堆栈。或者，也许系统的每个租户都有一个单独的数据库。当租户的部分或全部资源以这种专用方式部署时，我们将其称为筒仓模型。需要注意的是，即使筒仓拥有专用资源，筒仓环境仍然依赖于共享身份、入职和运营经验，所有租户都通过共享结构进行管理和部署。这将SaaS与托管服务模式区分开来，在托管服务模式中，客户可能运行不同版本的产品，并具有不同的入职、管理和运营经验。

水池

相比之下，SaaS的池模型是指租户共享资源的场景。这是更经典的多租户概念，租户依靠共享的、可扩展的基础设施来实现规模经济、可管理性、灵活性等。这些共享资源可以应用于SaaS架构的一些或所有元素，包括计算、存储、消息传递等。

桥梁模型

最后的模式是桥梁模型。Bridge旨在承认SaaS业务并不总是完全孤立或集中的现实。相反，许多系统具有混合模式，其中一些系统在筒仓模型中实现，一些系统在池模型中实现。例如，您的体系结构中的一些微服务可能使用思洛存储器实现，而其他微服务可能会使用池。服务数据的监管配置文件及其噪声邻居属性可能会将微服务导向筒仓模型。同时，另一个微服务的灵活性、访问模式和成本概况可能会使其倾向于池模型。

SaaS身份

大多数系统已经依赖身份提供者进行身份验证。在SaaS的世界中，我们需要扩展身份的概念，将租赁纳入我们的身份定义中。这意味着，在验证用户之后，我们需要知道用户是谁以及该用户与哪个租户关联。用户身份与租户身份的合并被称为SaaS身份。这个概念是SaaS架构的一个基本元素，它提供了租户上下文，用于实现SaaS应用程序中的底层多租户策略和策略。

租户隔离

租户隔离是每个SaaS提供商必须解决的基本问题之一。随着独立软件供应商（ISV）转向SaaS并采用共享基础架构模型以实现成本和运营效率，他们还必须承担确定其多租户环境如何确保每个租户无法访问另一个租户的资源的挑战。对于SaaS业务来说，以任何形式跨越这一边界都将是一个重大且可能无法恢复的事件。

尽管租户隔离的需求被视为SaaS提供商的基本需求，但实现这种隔离的策略和方法并不普遍。有很多因素可以影响租户隔离在任何SaaS环境中的实现方式。域、遵从性、部署模型和AWS服务的选择都为租户隔离带来了自己独特的考虑因素。

无论隔离是如何实现的，每个SaaS架构都需要确保其已将确保每个租户的资源已有效隔离所需的构造放置到位。

数据分区

当您查看表示多租户数据的不同体系结构模式时，必须选择如何组织数据。例如，数据是存储在单独的数据库中，还是混合在一个共享结构中？这些多租户存储机制和模式通常称为数据分区。

吵闹的邻居

噪声邻居是一个常用于一般架构模式和策略的术语。噪声邻居背后的想法是，系统的用户可能会对系统的资源施加负载，这可能会对该系统的其他用户产生不利影响。最终结果可能是一个用户会降低另一个用户的体验。

这一概念在多租户环境中扩展了相关性，租户可能正在使用共享资源。更为复杂的是，多租户环境中的工作负载可能是不可预测的。这种组合提高了SaaS架构使用自己的策略的需求，这些策略可以管理和最小化嘈杂租户的潜在影响。

租户入职

SaaS应用程序依赖于一个无摩擦的模型来将新租户引入其环境。这通常需要协调多个组件，以成功地调配和配置创建新租户所需的所有元素。在SaaS架构中，这个过程被称为租户入职。需要注意的是，租户登录可以由租户直接启动，也可以作为提供商管理流程的一部分。

租户层级

SaaS应用程序通常被设计为支持一系列细分市场，为一系列客户提供单独的定价和体验。这些配置文件通常称为层。支持这些不同层的不同需求意味着引入可以塑造每个层体验的体系结构。这些分层模型可以影响SaaS解决方案的成本、运营、管理和可靠性足迹。

租户活动和消费

在多租户SaaS环境中，了解租户如何使用您的应用程序并对系统架构施加负载非常重要。通过在租户级别跟踪这些信息，您可以评估系统有效扩展和支持环境中不断变化的工作负载的能力。从SaaS系统收集的度量和见解通常被称为租户活动和消费。

计量和计费

SaaS产品通常以现收现付模式销售，其中产品的成本是根据客户的消费情况确定的。该模型允许客户拥有一个定价模型，该模型与他们在SaaS系统上的价值和负载更加紧密地耦合。在这种模式下，SaaS提供商将定义并引入计量机制来衡量消费。该计量数据通常被发送到计费系统，该计费系统汇总计费信息并生成账单。基于消费的定价代表了一种定价模型，可以与其他定价策略（例如订阅）相结合。

租户感知操作

SaaS环境的运营经验引入了对附加机制和工具的需求，这些机制和工具可用于创建租户感知洞察，了解各个租户和层的活动和消费模式。这里的想法是，SaaS提供商需要能够通过单个租户和租户层的视角来查看系统活动和健康状况。这对于诊断和评估个体租户的活动和消费趋势和模式至关重要。

可靠性支柱包括系统从基础设施或服务中断中恢复的能力，动态获取计算资源以满足需求的能力，以及减轻诸如错误配置或瞬时网络问题等中断的能力。

设计原则

在云计算中，有许多原则可以帮助您提高可靠性。

释义

云计算中的可靠性有三个最佳实践领域：

• 基础
• 变更管理
• 故障管理

为了实现可靠性，系统必须有一个规划良好的基础和适当的监控，以及处理需求或需求变化的机制。系统应设计为检测故障并自动修复。

最佳实践

话题

基础

SaaS REL 1：如何限制单个租户施加可能影响系统其他租户可用性的负载的能力？

多租户环境中租户的工作量可能会不断变化。租户可能会对系统施加不同类型的负载。具有新工作负载配置文件的新租户也可能会不断添加到系统中。这些因素可能使SaaS公司创建一个具有足够弹性的架构来应对和响应这些不断变化的需求变得非常具有挑战性。

这些负载变化可能会对租户的体验产生不利影响。设想一个场景，其中一个租户最终在系统的某个方面承受了极大的负载。如果它们可以通过API与您的系统交互，这一点尤其明显。在这种情况下，该租户的负载最终可能会消耗不成比例的系统资源，进而影响整个系统的可靠性或其他租户的体验。

对于具有分层服务的系统，一个租户影响另一个租户的能力可能会变得更加复杂。例如，系统可能具有基本、高级和高级层。如果允许这些层中的每一层对系统施加任何级别的负载，我们可能会发现基本层正在影响高级层租户的可靠性。

在多租户环境中，您需要特别主动地识别可能影响系统可靠性的工作负载和消耗模式。多租户环境中的可靠性问题很容易在您的系统中级联，并可能影响所有客户的体验。

为了解决这些工作负载问题，您的系统必须引入能够检测和解决工作负载问题的机制，才能影响应用程序的可靠性。

应用程序的架构和应用程序堆栈将影响您应用的策略，以防止租户影响系统的可靠性和其他租户的体验。一种常见的方法是使用节流来防止租户消耗多余的资源。图21中的图表提供了使用AmazonAPI网关实现这一点的示例。

在本例中，您将看到我们利用API网关的使用计划为系统的每个租户定义了单独的使用体验。这种方法为系统的基本层和高级层使用单独的API密钥，这些密钥与具有不同SLA的使用计划相连接。这种方法实现了两种不同级别的控制。首先，它可以确保通过配置使用计划，防止所有租户在我们的系统中充满请求。另一个好处是，我们可以使用这些使用计划配置来防止较低层租户影响较高层租户的体验。

虽然此模型依赖于API网关来实现节流策略，但此核心概念可以应用于其他基础结构构造。这种方法的基本目标是能够在应用程序的入口点监控和管理访问，检测并限制可能会影响环境整体可靠性的任何租户。

图21：按层级限制租户

SaaS REL 2：如何主动检测和维护租户健康？

SaaS环境中的可靠性通常在很大程度上受到供应商在问题影响租户之前主动识别和补救问题的能力的影响。在多租户环境中构建一个主动的健康视图需要您提供额外的可靠性数据，这些数据可以提供租户工作负载健康趋势的更详细、租户感知的见解。

这些租户感知洞察用于识别租户特定的趋势、活动或洞察，这些趋势、活动和洞察可以有效捕获可能影响租户或整个系统可靠性的情况。拥有这些数据并主动将其呈现出来，允许您构建警报、策略和自动化，以尝试修复系统而不会导致停机。

为了实现这一点，您需要在应用程序中引入代码，以通过租户上下文发布健康洞察。这首先要确定体系结构中表示有用健康数据的工作流和事件。这可能是消费数据、缩放洞察、延迟度量等。这些洞察中的每一个都将通过日志文件或数据仓库发布，以汇总数据。

一旦在存储库中聚合了这些健康数据，就可以引入工具，根据对聚合的健康数据的分析来显示警报或触发策略。

SaaS REL 3：您如何测试SaaS应用程序的多租户功能？

多租户环境的测试模型不仅仅是确保应用程序的功能按预期工作。SaaS提供商还必须创建测试，以验证您的系统是否能够有效解决与多租户解决方案相关的常见可靠性问题。

作为多租户测试策略的一部分，您需要包含许多不同的维度。在许多情况下，这些测试旨在验证您现有的结构，以解决SaaS产品的规模、操作和可靠性问题。

需要注意的是，SaaS测试通常是模拟应用程序可能遇到的极端情况。您应该专注于构建一套测试，这些测试可以有效地建模和评估您的系统将如何响应预期和意外情况。除了确保客户拥有积极的体验外，您的测试还必须考虑实现规模的成本效益。如果您为响应活动而过度分配资源，则可能会影响业务的底线。

您可以在SaaS环境中增强负载和性能测试策略的一些特定领域是：

• 跨租户影响测试–创建模拟场景的测试，其中租户的子集对系统造成不成比例的负载。这将允许您确定当负载未在租户之间均匀分布时系统如何响应，并评估这可能会如何影响租户的整体体验。如果您的系统被分解为单独的可扩展服务，那么您需要创建测试来验证每个服务的扩展策略，以确保它们按照正确的标准进行扩展。
• 租户消耗测试–创建一系列负载配置文件（例如，扁平、尖峰和随机），跟踪资源和租户活动度量，并确定消耗和租户活动之间的增量。您最终可以将此增量作为监控策略的一部分，以确定次优资源消耗。您还可以将此数据与其他测试数据一起使用，以确定是否正确调整了实例的大小，是否正确配置了IOPS，以及是否优化了AWS占用空间。
• 租户工作流测试–使用这些测试来评估SaaS应用程序的不同工作流如何响应多租户环境中的负载。其想法是选择您的解决方案中众所周知的工作流，并将负载集中在具有多个租户的工作流上，以确定这些工作流是否会在多租户环境中造成瓶颈或资源过度分配。
• 租户入职测试–当租户注册您的系统时，您希望确保他们拥有积极的体验，并且您的入职流程具有弹性、可扩展性和高效性。如果您的SaaS解决方案在入职过程中提供了基础设施，则情况尤其如此。您需要确定活动的激增不会影响入职流程。这也是一个您可能依赖第三方集成（例如计费）的领域。您可能希望验证这些集成是否支持其SLA。在某些情况下，您可以实施回退策略来处理这些集成的潜在中断。在这些情况下，您需要引入测试来验证这些容错机制是否按预期执行。
• API节流测试–API节流的概念并非SaaS解决方案独有。通常，您发布的任何API都应该包含节流的概念。对于SaaS，您还需要考虑不同层的租户如何通过您的API施加负载。例如，免费层的租户可能不被允许施加与黄金层租户相同的负载。这使您能够验证与每个层关联的限制策略是否已成功应用和实施。
• 数据分布测试–在大多数情况下，SaaS租户数据不会被统一分布。租户数据配置文件中的这些变化可能会导致总体数据占用量失衡，并可能影响解决方案的性能和成本。为了抵消这种动态，SaaS团队通常会引入分片策略来解释和管理这些变化。共享策略对您的解决方案的性能和成本状况至关重要，因此，它们是测试的首选。数据分发测试允许您验证所采用的分片策略是否能够成功分发系统可能遇到的租户数据的不同模式。在存储了大量客户数据之后，尽早进行这些测试可能有助于避免迁移到新分区模型的高昂成本。
• 租户隔离测试–SaaS客户希望采取一切措施确保其环境安全，其他租户无法访问。为了支持这一需求，SaaS提供商构建了许多策略和机制来保护每个租户的数据和基础设施。引入不断验证这些策略实施的测试对任何SaaS提供商都至关重要。

正如您所看到的，这个测试列表的重点是确保您的SaaS解决方案能够在多租户环境中处理负载。SaaS的负载通常是不可预测的，您会发现这些测试通常是在关键负载和性能问题影响到一个或所有租户之前发现它们的最佳机会。在某些情况下，这些测试还可能出现新的拐点，这些拐点可能值得包含在系统的操作视图中。

变更管理

• SaaS应用程序没有独特的可靠性实践。

故障管理

• SaaS应用程序没有独特的可靠性实践。

资源

请参阅以下资源以了解有关可靠性的最佳实践的更多信息。

文档和博客

• Monolith to serverless SaaS: Migrating to multi-tenant architecture

• Testing SaaS Solutions on AWS

• Importance of Service Level Agreement for SaaS Providers

• Using Amazon SQS in a Multi-Tenant SaaS Solution

• Partitioning Pooled Multi-Tenant SaaS Data with Amazon DynamoDB

• Architecting Successful SaaS: Interacting with Your SaaS Customer’s Cloud Accounts

• AWS Auto Scaling

• Creating and using usage plans with API keys

• Managing Concurrency for a Lambda Function

• Amazon API Gateway: Throttle API requests for better throughput

• Amazon CloudWatch Observability of your AWS resources and applications on AWS and on-premises

• Amazon CloudWatch Publishing Custom Metrics

视频

• AWS re:Invent 2017: SaaS Monitoring - Creating a Unified View of Multi-tenant Health featuring New Relic

• AWS re:Invent 2019: Building serverless SaaS on AWS

• AWS re:Invent 2019: Serverless SaaS deep dive: Building serverless SaaS on AWS (ARC410-R)

请参阅以下资源以了解有关我们的安全最佳做法的更多信息。

文档和博客

• Isolating SaaS Tenants with Dynamically Generated IAM Policies

• Partitioning Pooled Multi-Tenant SaaS Data with Amazon DynamoDB

• Multi-tenant data isolation with PostgreSQL Row Level Security

• Identity Federation and SSO for SaaS on AWS

• Managing SaaS Identity Through Custom Attributes and Amazon Cognito

• Onboarding and Managing Agents in a SaaS Solution

• Amazon Cognito API Reference

• Building Serverless SaaS with Lambda layers

• Modeling SaaS Tenant Profiles on AWS

白皮书

• SaaS Tenant Isolation Strategies Isolating Resources in a Multi-Tenant Environment Whitepaper

• SaaS Storage Strategies whitepaper

视频

• AWS re:Invent 2017: SaaS and OpenID Connect: The Secret Sauce of Multi-Tenant Identity

• AWS re:Invent 2016: The Secret to SaaS (Hint: It's Identity)

• AWS re:Invent 2019: SaaS tenant isolation patterns

安全支柱包括帮助保护信息、系统和资产的能力，同时通过风险评估和缓解策略实现业务价值。

设计计原则

在云中，有许多原则可以帮助您加强系统安全性。

定义

云安全有五个最佳实践领域：

• 身份和访问管理
• 侦探控件
• 基础设施保护
• 数据保护
• 事件响应

多租户为您的SaaS架构增加了一层额外的考虑因素。使用SaaS，您的用户现在可以在给定租户的上下文中访问共享环境。必须在应用程序体系结构的所有层中捕获和传递此上下文，并在确保环境的总体占地面积方面发挥基本作用。

从安全角度来看，您需要了解租赁是如何引入您的环境的，以及如何使用它来保护租户资源。总的来说，您需要确保每个租户都有一个谨慎约束的体验，防止他们访问任何其他租户的资源。

最佳实践

话题

• 身份和访问管理
• 检测控制
• 基础设施保护
• 数据保护
• 事件响应

基础设施保护

SaaS SEC 2：您如何确保租户资源免受跨租户访问？

租户隔离是每个SaaS提供商必须解决的基本问题之一。随着独立软件供应商（ISV）转向SaaS并采用共享基础架构模型以实现成本和运营效率，他们还面临着确定其多租户环境如何确保租户无法访问另一租户资源的挑战。对于SaaS业务来说，以任何形式跨越这一边界都将是一个重大且可能无法恢复的事件。

尽管租户隔离的需求被视为SaaS提供商的基本需求，但实现这种隔离的策略和方法并不普遍。有很多因素可以影响租户隔离在任何SaaS环境中的实现方式。域、遵从性、部署模型和AWS服务的选择都为租户隔离带来了自己独特的考虑因素。

隔离心态

在概念层面，许多SaaS提供商都同意保护和隔离租户资源的重要性和价值。然而，当您深入了解实施隔离策略的细节时，您通常会发现，每个SaaS ISV都有自己的隔离定义。

鉴于这些不同的观点，我们在下面概述了一些原则，这些原则将有助于指导租户隔离的整体价值体系。每个SaaS提供商都应该建立一套清晰的高级隔离要求，以指导其团队定义其SaaS环境的隔离足迹。以下是通常形成整个SaaS租户隔离模型的一些关键原则：

隔离不是可选的–隔离是SaaS的一个基本要素，以多租户模式提供解决方案的每个系统都应确保其系统采取措施确保租户资源被隔离。

身份验证和授权不等于隔离–虽然您可以通过身份验证和权限控制对SaaS环境的访问，但超越登录屏幕或API的入口并不意味着您已经实现了隔离。这只是隔离难题的一部分，单靠它本身是不够的。

隔离执行不应留给服务开发人员——尽管开发人员永远不会引入可能违反隔离的代码，但期望他们永远不会无意中跨越租户边界是不现实的。为了缓解这种情况，应该通过一些共享机制来控制对资源的访问范围，该机制负责应用隔离规则（在开发人员的视野之外）。

如果没有现成的隔离解决方案，您可能必须自己构建它——有许多安全机制，如AWS身份和访问管理（IAM），可以帮助您简化租户隔离的路径。将这些工具与更广泛的安全方案相结合，有助于简化隔离过程。。然而，在某些情况下，您的隔离模型可能没有通过相应的工具或技术直接解决。没有一个明确的解决方案不应该是降低隔离要求的机会，即使这意味着要建立自己的解决方案。

隔离不是资源级别的构造——在多租户和隔离的世界中，有些人会将隔离视为在具体基础设施资源之间划出硬边界的一种方式。这通常转化为隔离模型，在该模型中，您可能为每个租户拥有单独的数据库、计算实例、帐户或虚拟私有云（VPC）。虽然这些是常见的隔离形式，但并不是隔离租户的唯一方式。即使在实际上共享资源的场景中，特别是在共享资源的环境中，也有实现隔离的方法。在这个共享资源模型中，隔离可以是由运行时应用的策略强制执行的逻辑构造。这里的关键点是，隔离不应等同于拥有孤立的资源。

域可能会施加特定的隔离要求——虽然实现租户隔离的方法很多，但给定域的现实可能会施加限制，需要特定的隔离风格。例如，一些高合规性行业可能要求每个租户都有自己的数据库。在这些情况下，共享的、基于政策的隔离方法可能不够。

核心隔离概念

隔离的部分挑战是租户隔离有多种定义。对一些人来说，隔离几乎是一种业务结构，他们认为整个客户都需要自己的环境。对于其他人来说，隔离更多的是一种架构构造，它覆盖了多租户环境的服务和构造。以下各节将探讨不同类型的隔离，并将特定术语与不同的隔离结构相关联。

筒仓隔离（Silo Isolation）

尽管SaaS提供商通常专注于共享资源的价值，但在某些情况下，SaaS提供商可能会选择将其部分（或全部）租户部署在一个模型中，每个租户都在运行一个完全孤立的资源堆栈。有人会说，这种全栈模型并不代表SaaS环境。然而，如果您已经用共享身份、入职、计量、度量、部署、分析和运营来围绕这些独立的堆栈，那么这是一种有效的SaaS变体，它以规模经济和运营效率换取法规遵从性、业务或域考虑。使用这种方法，隔离是一种跨整个客户堆栈的端到端构造。图16中的图表提供了这种隔离视图的概念视图。

图16：筒仓隔离模型

此图突出显示了孤立部署模型的基本占地面积。用于运行这些堆栈的技术在这里大多无关紧要。这可以是一个整体，可以是无服务器的，也可以是各种应用程序架构模型的任意组合。关键的概念是获取租户拥有的任何堆栈，并用一些构造将其包围，以封装该堆栈的所有活动部分。这成为隔离的边界。只要您能够防止租户逃离其完全封装的环境，就已经实现了隔离。

通常，这种隔离模型的实施要简单得多。通常有定义良好的构造，使您能够实现健壮的隔离模型。虽然该模型对SaaS环境的成本和敏捷性目标提出了一些实际挑战，但它对那些有非常严格隔离要求的人来说可能很有吸引力。

筒仓模型优点和缺点

每个SaaS环境和业务领域都有自己独特的需求集，这可能会使思洛存储器更适合。然而，如果您正朝着这个方向倾斜，您肯定希望考虑到与筒仓模型相关的一些挑战和开销。如果您正在探索SaaS解决方案的筒仓模型，则需要考虑以下利弊：

优点

• 支持具有挑战性的法规遵从性模型–一些SaaS提供商正在向实施严格隔离要求的受监管环境销售产品。筒仓模型为这些ISV提供了一个选项，使他们能够向部分或所有租户提供在专用模型中部署的选项。
• 无噪音邻居问题–尽管所有SaaS提供商都应尝试限制噪音邻居条件的影响，但一些客户仍会对使用系统的其他租户的活动影响其工作负载的可能性表示保留。筒仓模型通过提供一个专用环境来解决这一问题，该环境不可能出现嘈杂的邻居场景。
• 租户成本跟踪–SaaS提供商通常高度关注了解每个租户如何影响其基础设施成本。在某些SaaS模型中，计算每个租户的成本可能是一项挑战。然而，筒仓模型的粗粒度特性为您提供了一种更简单的方法来捕获和关联每个租户的基础设施成本。
• 减少影响范围–当SaaS解决方案中可能出现停机或事件时，筒仓模型通常会减少您的风险敞口。由于每个SaaS提供商都在其自己的环境中运行，因此在给定租户的环境中发生的任何故障都可能受限于该环境。虽然一个租户可能会遇到停机，但该错误不会在使用系统的其他租户之间级联。

缺点

• 扩展问题–可以调配的帐户数量有限制。此限制可能会阻止您选择基于帐户的模型。还有一个普遍的问题是，快速增长的客户数量可能会破坏您的SaaS环境的管理和运营体验。例如，每个租户拥有20个单独的账户可能是可以管理的。然而，如果您有1000个租户，那么这个数字可能会开始影响运营效率和灵活性。
• 成本–由于每个租户都在自己的环境中运行，传统上与SaaS解决方案相关的大部分成本效率都没有实现。即使这些环境是动态扩展的，您也可能会有一天中闲置资源未被使用的时间。虽然这是一个完全可以接受的模型，但它会破坏您的组织实现规模经济和利润效益的能力，而这些效益对SaaS模型至关重要。
• 敏捷性——向SaaS的转变通常是由以更快的速度进行创新的愿望直接推动的。这意味着采用一种模式，使组织能够快速响应市场动态。其中的一个关键部分是能够统一客户体验并快速部署新功能和功能。尽管筒仓模型可以采取一些措施来限制其对敏捷性的影响，但筒仓模型高度分散的特性增加了复杂性，影响了您轻松管理、运营和支持租户的能力。
• 入职自动化–SaaS环境重视自动化引入新租户。无论这些租户是以自助服务模式还是使用内部管理的资源调配流程进行入职，您仍需要自动化入职。而且，当您为每个租户设置了单独的siloe时，这通常会成为一个更重要的过程。提供新租户将需要提供新的基础设施，并可能需要配置新的帐户限制。这些增加的移动部件引入了额外的开销，从而为整个入职自动化带来了额外的复杂性，使您能够将更少的时间集中在客户身上。
• 去中心化管理和监控——SaaS的目标是拥有一块玻璃，使您能够管理和监控所有租户活动。当您拥有孤立的租户环境时，这一要求尤为重要。这里的挑战是，您现在必须从更分散的租户足迹中聚合数据。虽然有一些机制可以让您创建租户的聚合视图，但在孤立的模型中，构建和管理这种体验所需的努力和精力更为复杂。

池隔离（Pool Isolation）

您可以看到隔离的筒仓模型如何很好地映射到许多SaaS公司。许多正在转向SaaS的公司都在寻求让租户共享部分或全部底层基础设施的效率、灵活性和成本效益。这种共享基础设施方法（称为池模型）为隔离故事增加了一定程度的复杂性。图17中的图表说明了与在池模型中实现隔离相关的挑战。

图17：池隔离模型

在这个模型中，您会注意到我们的租户正在使用所有租户共享的基础设施。这使得资源能够与租户施加的实际负载成正比地扩展。图的右侧缩小了其中一个服务的计算方面，突出了租户1-N在任何给定时间都可能在共享计算中并行运行的事实。本例中的存储也是共享的，并表示为由单个租户标识符索引的表。

这种模式可以很好地适用于SaaS提供商，但是，它有可能使整个隔离过程复杂化。在共享资源的情况下，实现隔离并不是那么清晰和典型的网络，IAM结构不能用来在租户之间创建边界。

这里的关键是，即使这是一个更具挑战性的隔离环境，您也不能将其作为放松环境隔离要求的理由。共享模式增加了跨租户访问的机会，因此，它代表了一个需要您特别注意确保资源隔离的领域。

当我们深入研究池隔离模型时，您将看到这个体系结构足迹如何引入独特的挑战组合，每个挑战都需要自己类型的隔离构造来成功隔离租户的资源。

池模型的优点和缺点

尽管共享所有内容可以提高效率和优化，但这也需要SaaS提供商权衡采用该模型所带来的一些权衡。在许多情况下，水池模型的优点和缺点最终表现为筒仓模型的优点与缺点的反面。这些是通常与池隔离模型相关的主要优点和缺点。

优点

• 敏捷性–当您将租户迁移到共享基础架构模型中时，您可以利用自然的效率和简单性，帮助简化SaaS产品的敏捷性。池模式的核心是使SaaS提供商能够以统一的体验管理、扩展和运营所有租户。集中化和标准化体验是使SaaS提供商能够更轻松地管理所有租户并将更改应用于所有租户的基础，而无需逐个租户执行一次性任务。这种运营效率是SaaS环境整体敏捷性的关键。
• 成本效率——许多公司都因其成本效率而被SaaS所吸引。这种成本效率的很大一部分通常与隔离池模型有关。在共享环境中，您的系统将根据所有租户的实际负载和活动进行扩展。如果所有租户都处于离线状态，您的基础设施成本应该是最低的。这里的关键概念是，池化环境可以动态调整租户负载，并使您能够更好地调整租户活动与资源消耗。
• 简化了管理和操作–隔离池模型为您提供了一个系统中所有租户的视图。您可以通过触及系统中所有租户的单一体验来管理、更新和部署所有租户。这使得管理和操作的大部分方面更加简单。
• 创新–集合隔离模型所带来的灵活性也往往是SaaS提供商更快创新的核心。您越是远离分布式管理和筒仓模型的复杂性，就越能自由地关注产品的特性和功能。

缺点

• 吵闹的邻居——共享的资源越多，一个租户影响另一个租户体验的机会就越大。例如，一个租户的任何活动都会给系统带来沉重的负载，这可能会影响其他租户。一个好的多租户体系结构和设计将试图限制这些影响，但在共享隔离模型中，噪声邻居条件总是有可能影响一个或多个租户。
• 租户成本跟踪–在筒仓模型中，将资源消耗归因于特定租户要容易得多。然而，在集合模型中，资源消耗的归属变得更具挑战性。每一个SaaS提供商都应该寻找方法来检测他们的系统，并提供所需的粒度数据，以有效地将消费与单个租户关联起来。
• 减少影响范围–共享所有共享资源也会带来一些运营风险。在思洛存储器模型中，当一个租户发生故障时，该故障的影响可能仅限于该租户。然而，在共享环境中，停机可能会影响系统中的所有租户，这可能会对您的业务产生重大影响。这通常需要更深入地致力于建立一个有弹性的环境，以识别故障、浮出水面并从故障中优雅地恢复。
• 合规性阻碍——尽管您可以采取一些措施来隔离池模式中的租户，但共享基础设施的概念可能会造成您不愿意在这种模式中运行的情况。在域的法规遵从性或管理规则对资源的可访问性和隔离性施加严格限制的环境中尤其如此。尽管如此，即使在这些情况下，这也可能意味着系统的某些部分需要被孤立。

桥梁模型

尽管筒仓和池模型有非常不同的隔离方法，但许多SaaS提供商的隔离环境并不绝对。当您查看实际的应用程序问题并将系统分解为较小的服务时，您通常会发现您的解决方案需要混合使用思洛存储器和池模型。这种混合模型就是我们所说的隔离桥模型。图18中的图表提供了如何在SaaS解决方案中实现桥接模型的示例。

图18：桥梁隔离模型

此图突出显示了网桥模型如何使您能够组合思洛存储器和池模型。这里我们有一个具有经典web和应用程序层的整体架构。对于此解决方案，web层部署在所有租户共享的池模型中。虽然web层是共享的，但我们应用程序的底层业务逻辑和存储实际上部署在一个筒仓模型中，每个租户都有自己的应用程序层和存储。

如果单片被分解为微服务，那么系统中的每个微服务都可以利用筒仓和池模型的组合。关于这种方法的更多细节，将在使用不同AWS构造应用筒仓和池模型的细节描述中介绍。这里的关键信息是，对于分解为具有不同隔离要求的服务集合的环境，您对思洛存储器和池模型的看法将更加精细。

基于层的隔离

虽然我们对隔离的大部分讨论都集中在防止跨租户访问的机制上，但在某些情况下，您的产品的分层可能会影响您的隔离策略。在这种情况下，与其说是如何隔离租户，不如说是如何打包并为具有不同配置文件的不同租户提供不同风格的隔离。然而，这是另一个考虑因素，它可以决定您需要支持哪些隔离模式，以满足您想要接触的所有客户。图19中的图表提供了隔离如何在不同层之间变化的示例。

下面的示例使用了筒仓和池隔离模型的组合，这些模型已作为层提供给租户。Silver层的租户在共享环境中运行。尽管这些租户在共享基础架构模型中运行，但他们仍然完全希望自己的资源不会受到跨租户访问的保护。右边的租户要求提供一个完全专用的（筒仓）环境。为了支持这一点，SaaS提供商创建了一个高级层模型，使租户能够以更高的价格在这种专用模型中运行。

虽然SaaS提供商通常试图限制向其客户提供筒仓模型，但许多SaaS企业都有这种私有定价的概念，即这些租户提供在这种模型中部署的溢价。事实上，SaaS公司不会将其作为一个选项发布，也不会将其确定为一个层来限制选择此选项的客户数量。如果您的租户中有太多人陷入这种模式，您将开始回到完全孤立的模式，并继承前面概述的许多挑战。

图19：基于层的隔离

为了限制这些一次性环境的影响，SaaS提供商通常会要求这些高级客户运行部署到池环境的相同版本的产品。这使ISV能够通过一块玻璃继续管理和操作这两个环境。从本质上讲，思洛存储器环境变成了恰好支持一个租户的池环境的克隆。

目标的隔离

需要注意的是，系统中的隔离选择可能非常精细。系统中的每个微服务和这些服务接触的每个资源都可以选择配置不同的隔离模型。让我们来看看一些微服务示例，以更好地理解如何在不同的微服务之间改变隔离模型。图20中的图表提供了使用筒仓和池隔离模型的微服务视图。

在这个图中，您将看到一个系统实现了三种不同的微服务：产品、订单和帐户。每种微服务的部署和存储模型都突出了隔离（对于安全或嘈杂的邻居）如何在SaaS环境中实现。

让我们回顾一下这些服务的隔离模型。右上角的Product微服务部署在一个完整的池模型中，所有租户共享计算和存储。这里的表反映了租户在这里的所有土地作为单独的项目，在同一个表中进行索引。假设数据将与可以限制访问此表中租户项的策略隔离。Order微服务仅适用于租户1到租户3，并且也以池模式实现。这里唯一的区别是它支持一部分租户。本质上，任何没有得到Order微服务专用（筒仓）部署的租户都将在这个池部署中运行（将其视为租户1..N，只有少数租户作为筒仓微服务退出）。

出于本讨论的目的，让我们关注由专用订单微服务（右上）和Account微服务（下）表示的孤立服务。您会注意到，我们已经为租户4和5部署了Order微服务的独立实例。这里的想法是，这些租户对订单处理有一些要求（合规性、嘈杂的邻居等），要求在筒仓模型中部署此服务。这里的计算和存储都完全专用于这些租户。

最后，底部是Account微服务，它代表了筒仓模型，但仅在存储级别。微服务的计算由所有租户共享，但每个租户都有一个保存其帐户数据的专用数据库。在这种情况下，隔离问题只关注于分离数据。计算仍然可以共享。

图20：目标隔离

该模型显示了筒仓讨论如何变得更加精细。安全性、嘈杂的邻居以及各种因素将决定如何以及何时为服务采用筒仓隔离模型。这里的关键是，筒仓模型不是一个要么全有要么全无的决定。您可以考虑将思洛存储器模型应用于应用程序的特定组件，并仅在实际需要时（例如当潜在客户要求使用时）吸收该模型的挑战。在本例中，通过与客户进行更详细的讨论，您会发现只有几个特定的存储和处理领域值得关注。这样做将使您能够为系统中那些不需要思洛存储器隔离的部分获得池模型的效率，并为您提供灵活的分层结构，以支持单个服务的思洛存储器和池模型的混合。

安全支柱包括帮助保护信息、系统和资产的能力，同时通过风险评估和缓解策略实现业务价值。

设计计原则

在云中，有许多原则可以帮助您加强系统安全性。

定义

云安全有五个最佳实践领域：

• 身份和访问管理
• 侦探控件
• 基础设施保护
• 数据保护
• 事件响应

多租户为您的SaaS架构增加了一层额外的考虑因素。使用SaaS，您的用户现在可以在给定租户的上下文中访问共享环境。必须在应用程序体系结构的所有层中捕获和传递此上下文，并在确保环境的总体占地面积方面发挥基本作用。

从安全角度来看，您需要了解租赁是如何引入您的环境的，以及如何使用它来保护租户资源。总的来说，您需要确保每个租户都有一个谨慎约束的体验，防止他们访问任何其他租户的资源。

最佳实践

话题

• 身份和访问管理
• 检测控制
• 基础设施保护
• 数据保护
• 事件响应

身份和访问管理

SaaS SEC 1：您如何将租户上下文与用户关联，并在SaaS架构中应用该上下文？

向多租户体系结构的转变通常从身份开始。访问应用程序的每个用户都必须与租户连接。用户身份与租户的这种绑定被非正式地称为SaaS身份。SaaS身份的关键属性是它将租户上下文提升为一个一流的构造，将其直接连接到SaaS应用程序的整体身份验证和授权模型。

这种方法允许租户上下文使用用于传递和访问用户身份的相同体系结构构造流经体系结构的所有层。例如，如果您的应用程序中有100个微服务，您希望这些服务中的每一个都能够获取和应用租户上下文，而不需要往返于另一个服务。通过另一个服务管理此上下文会增加延迟，并经常在架构中造成瓶颈。

将租户上下文注入您的身份可以通过多种模式实现。您为应用程序选择的身份提供商和技术将直接影响您最终应用的方法和策略，以将这种背景引入您的体验。虽然工具可能会发生变化，但最基本的需要是在用户进入应用程序时注入租约的环境的整体身份验证体验中引入租约。

图15中的图表提供了一个使用AWS服务通常如何实现这一点的示例。此示例包括用于将租户上下文注入SaaS环境的常见组件和技术。这在图的左侧进行了说明，租户填写了一个注册表单，并触发对应用程序注册服务的调用。

图15：注入租户内容

该注册服务创建租户，然后在AmazonCognito中创建用户。作为此过程的一部分，您将自定义声明引入用户属性，这些属性包含有关用户与租户关系的信息。这些自定义声明成为用户身份签名的一部分，将它们作为一级构造直接连接到租户。

登录完成后，您可以查看在用户登录时如何应用这些用户和租户属性（图的右侧）。在这里，您将看到用户针对Amazon Cognito进行身份验证，并作为该过程的一部分，返回一个JSON web令牌（JWT），其中包含在入职过程中创建的自定义声明。

现在，您有了一个令牌，它包含了将租户上下文注入到与多租户应用程序服务的交互中所需的所有信息。在本例中，我们将JWT作为承载令牌传递到Product微服务的每个请求的头中。该服务现在可以从该令牌获取并应用上下文，而无需调用其他服务。

最后，这个Product微服务调用Order微服务，在请求的头中传递JWT。这说明了租户上下文如何在所有微服务调用中流动，而无需添加任何额外的查找或延迟。

这个例子恰好依赖于AmazonCognito来连接用户和租户身份。然而，这个相同的模型可以与其他身份提供者或替代身份验证方案一起实现。这里的关键是，您正在构建一种身份验证体验，它可以产生连接租户和用户的表示。然后，该表示应可用于解决方案的所有层。

性能效率支柱侧重于有效利用计算资源来满足需求，并随着需求的变化和技术的发展而保持这种效率。

释义

云计算中的性能效率有四个最佳实践领域：

• 选择（计算、存储、数据库、网络）
• 回顾
• 监测
• 权衡取舍

采用数据驱动方法选择高性能架构。从高层设计到资源类型的选择和配置，收集架构各个方面的数据。通过周期性地审查您的选择，您将确保您正在利用不断发展的AWS云。

监控将确保您意识到与预期性能的任何偏差，并可以对此采取行动。最后，您的体系结构可以进行权衡以提高性能，例如使用压缩或缓存，或放宽一致性要求。

最佳实践

话题

选择

SaaS性能1：如何防止一个租户对另一个租户的体验产生负面影响？

在多租户环境中，租户可能具有对系统施加显著不同负载的配置文件和用例。具有新工作负载配置文件的新租户也可能会不断添加到系统中。这些因素使得SaaS公司构建一个能够满足这些租户快速发展的性能需求的架构非常具有挑战性。

处理和管理租户负载的这些变化是SaaS环境性能概要的关键。SaaS架构必须能够成功检测这些租户消费趋势，并应用能够有效扩展以满足租户需求或限制单个租户活动的策略。

有多种策略可用于管理租户可能对系统造成不成比例负载的情况。这可以通过隔离高需求资源、引入扩展策略或应用节流策略来实现。

在最简单和最极端的情况下，您可以考虑为应用程序的部分创建租户特定的部署。图22中的图表说明了一种分解系统以解决性能挑战的方法。

图22：使用孤立服务解决性能问题

在本例中，您将注意到我们有两个不同的部署足迹（一些在思洛存储器模型中，一些在池模型中）。在图的左侧，您将看到为每个租户部署了Product、Order和Cart微服务的单独实例。同时，在图的右侧，您将看到所有租户共享的微服务集合。

该方法背后的基本思想是开发特定的服务，这些服务被视为对应用程序的性能概要至关重要。通过将它们分开，您的系统可以确保任何一个租户的负载不会影响其他租户的性能（对于这组服务）。此策略可能会增加成本并降低环境的操作灵活性，但仍然是实现性能目标的有效方法。同样的方法也可用于解决合规性和隔离要求。

例如，您可以为每个租户部署一个订单管理微服务，以限制一个租户对另一个租户的订单处理体验产生不利影响的能力。这增加了操作复杂性并降低了成本效率，但可以作为一种暴力手段，有选择地针对应用程序关键领域的跨租户性能问题。

理想情况下，您应该尝试通过构造来解决这些性能需求，这些构造可以解决租户负载问题，而不会吸收单独部署服务的开销和成本。在这里，您将专注于创建一个扩展配置文件，使您的共享基础架构能够有效地响应租户负载和活动的变化。

基于容器的架构（如AmazonEKS或AmazonECS）可以配置为基于租户需求扩展服务，而不需要任何过度资源调配。容器快速扩展的能力增强了系统对急剧租户负载的有效响应能力。将容器的扩展速度与AWS Fargate的成本概况相结合，通常是弹性、运营灵活性和成本效率的完美结合，可以帮助组织解决租户的巨大负载，而不会过度配置环境。

使用AWS Lambda构建的无服务器SaaS架构也可能非常适合解决租户负载过高的问题。AWS Lambda的管理特性允许您的应用程序服务快速扩展，以解决租户负载的峰值问题。这种方法可能需要考虑并发性和冷启动因素。然而，它可以代表限制跨租户性能影响的有效策略。

虽然响应式扩展策略可以帮助解决这个问题，但您可能需要采取其他措施，以简单地防止租户施加可能会造成跨租户影响的负载。在这些场景中，您可以选择通过设置限制（可能按层）来检测和约束租户的活动，这些限制将应用节流来控制系统上的负载级别。这将通过引入节流政策来实现，该政策将检查租户的负载，识别超出限制的活动，并限制他们的体验。

SaaS性能2：您如何确保基础设施资源的消耗与租户的活动和工作负载保持一致？

SaaS公司的商业模式通常严重依赖于一种策略，该策略允许他们将基础设施的成本与租户的实际活动相一致。由于SaaS系统中租户的负载和组成不断变化，因此您需要一种架构策略，该策略可以有效地以一种模式来扩展资源的消耗，这种模式非常反映SaaS体验中的这些实时、不可预测的消耗模式。

图23中的图表提供了一个环境的假设示例，该环境已协调了基础设施消耗和租户活动。这里蓝色实线表示租户在一段时间内的实际活动趋势。红色虚线表示为解决租户负载而配置的实际基础设施。

图23：调整租户活动和消费

在理想的环境中，我们的策略是尽量缩小红线和蓝线之间的差距。在这里，您总是有一定的误差余量，因为您有一些缓冲，以确保不会影响系统的可用性或性能。同时，您希望能够提供足够的基础设施，以支持租户当前的性能需求。

这里的关键挑战是，图中显示的负载通常是不可预测的。虽然可能存在一些一般趋势，但您的架构和扩展策略不能假设今天的负载明天甚至未来一小时都会相同。

调整消费与活动的最简单方法是使用提供无服务器体验的AWS服务。这方面的经典例子是AWS Lambda。使用AWS Lambda，您可以构建一个服务器和扩展策略不再由您负责的模型。使用无服务器，您的SaaS应用程序只会产生与租户消费直接相关的费用。如果您的SaaS系统没有负载，那么AWS Lambda将不会产生任何成本。

AWS Fargate还支持基于容器的版本，这是一种无服务器的心态。通过将Fargate与AmazonEKS或AmazonECS一起使用，您只需支付应用程序实际消耗的容器计算成本。

这种使用无服务器模型的能力超出了计算构造。例如，您的解决方案的存储部分也可以依赖于无服务器技术。AmazonAuroraServerless允许您存储关系数据，而无需调整运行数据库的实例的大小。相反，AmazonAuroraServerless将根据实际负载来调整您的环境大小，并且只对您的应用程序消耗的内容收费。

任何让您不再需要创建扩展策略的模型都将简化您的运营和成本体验。您可以将更多的时间和精力集中在应用程序的特性和功能上，而不是继续追求难以捉摸的完美自动缩放配置。这也使该公司能够发展并接受新租户，而不必担心AWS账单的意外增长。

对于无服务器可能不是一个选项的场景，您需要回到传统的扩展策略。在这些场景中，您需要捕获和发布租户消费指标，并根据这些指标定义扩展策略。

回顾

SaaS应用程序没有独特的性能实践。

监测

SaaS性能3：如何为不同的租户层和计划实现不同级别的性能？

SaaS解决方案通常以分层模式提供，租户可以获得不同的体验。性能通常是一个用于区分SaaS环境的层的领域，使用性能作为一种创建价值边界的方式，迫使租户转移到更高级别的层。

在此模型中，您的体系结构将引入用于监视和控制每个层的体验的构造。这不仅仅是为了最大限度地提高性能，还在于限制低层租户的消费。即使您的系统可以容纳这些租户的负载，您也可以纯粹基于成本或业务考虑来限制负载。这通常是确保租户的成本足迹与租户为业务贡献的收入相关的一部分。

解决此问题最简单的方法是引入与单个租户层相关联的限制策略。当租户达到限制时，您将应用限制并限制其消费。

在某些情况下，您可以使用特定的AWS配置来配置租户层的消费配置文件。例如，在AWS Lambda中，可以使用保留并发来限制给定租户层的消耗。图24中的图表提供了如何实现这一点的示例。

图24：使用保留并发控制租户性能

在本例中，我们创建了三个独立的租户层，并为每个层部署了三个不同的SaaS应用程序微服务集合。这些集合还配置有单独的保留并发设置，这些设置用于确定可以为该组函数运行多少个并发函数调用。基本层的保留并发数为100，高级层为300。这里的想法是，我的低端层的消耗将受到限制，将所有剩余的并发留给高级层。

这种方法很好地符合我们的目标，即为我们的首选层提供最佳体验，同时限制较低层消耗多余资源的能力，并影响较高层租户的绩效。

容器还具有解决性能分层问题的独特策略。例如，在AmazonEKS中，您可以配置单独的ResourceQuotas和LimitRanges来控制命名空间中可用的资源量。

虽然这些约束有助于配置租户的性能体验，但一些SaaS应用程序实际上会通过应用程序设计和分解策略来解决性能问题。这可以通过为更高层租户部署孤立的微服务来实现，消除这些特定服务的任何噪音邻居考虑。事实上，您可能会发现，将系统分解为微服务可能会直接受到目标分层和性能配置文件的影响。

在某些情况下，您的SaaS应用程序还可能引入架构结构，以优化更高层租户的体验。例如，想象一下，为高级租户提供关键数据的缓存。通过将缓存仅限于这些用户，可以避免必须支持所有用户的缓存的开销。引入这些优化的努力应该用对客户和业务的足够价值来抵消，以保证投资。

权衡取舍

SaaS应用程序没有独特的性能实践。

资源

请参阅以下资源，以了解有关性能效率的最佳实践的更多信息。

文档和博客

• Optimizing SaaS Tenant Workflows and Costs Blog

• Using Amazon SQS in a Multi-Tenant SaaS Solution

• Importance of Service Level Agreement for SaaS Providers

• Amazon API Gateway: Throttle API requests for better throughput

• Creating and using usage plans with API keys

• Monitoring CloudWatch metrics for your Auto Scaling groups and instances

• Dynamic scaling for Amazon EC2 Auto Scaling

白皮书

• SaaS Storage Strategies Building a Multi-tenant Storage Model on AWS

• Whitepaper: SaaS Solutions on AWS Tenant Isolation Architectures

视频

• AWS re:Invent 2018: SaaS Reference: Review of Real-World Patterns & Strategies

• AWS re:Invent 2016: Optimizing SaaS Solutions for AWS

• SaaS Metrics: The Ultimate View of Tenant Consumption

• Microservices decomposition for SaaS environments (ARC210)

• SaaS tenant isolation patterns

成本优化支柱包括系统在其整个生命周期内的不断完善和改进过程。从最初的概念验证设计到生产工作负载的持续运行，采用本文中的实践将使您能够构建和运行具有成本意识的系统，从而实现业务成果并最大限度地降低成本，从而使您的企业实现投资回报最大化。

释义

云计算中的成本优化有四个最佳实践领域：

• 具有成本效益的资源
• 供需匹配
• 支出意识
• 随时间优化

与其他支柱一样，需要考虑权衡。例如，您希望优化上市速度还是成本？在某些情况下，最好优化快速上市、发布新功能，或者只是满足最后期限，而不是投资于前期成本优化。

与经验数据相比，设计决策有时受到匆忙的指导，因为总是存在着过度补偿“以防万一”的诱惑，而不是花时间进行基准测试以获得最具成本效益的部署。

这通常会导致资源调配过度和部署不足。以下各节为部署的初始和持续成本优化提供了技术和战略指导

最佳实践

话题

具有成本效益的资源

• SaaS应用程序没有独特的成本做法。

供需匹配

• SaaS应用程序没有独特的成本做法。

支出意识

SaaS成本1：如何衡量单个租户的资源消耗？

衡量和归因于多租户环境中的成本首先要有一个将消费归因于租户的可靠策略。这将需要团队设计和开发一个消费映射模型，该模型清晰地显示租户如何使用系统资源。最终目标是获得一系列见解，使您能够为系统的每个租户分配一定比例的消费。

在租户可能共享部分或全部系统资源的多租户环境中，组装这种消费视图可能特别具有挑战性。这种更细粒度的消费模型删除了许多选项和工具策略，这些选项和策略通常用于在AWS环境中定义消费（例如标记）。

虽然没有单一的模型来定义如何在SaaS架构中捕获租户消费，但在为应用程序选择策略时，应该考虑一些常见的策略。首先，您需要查看SaaS环境的总体成本概况，并确定应用程序如何影响AWS账单中的成本。对于某些环境，您的成本可能主要集中在应用程序的几个方面。在这些场景中，您可能会在收集对账单贡献最大的领域的消费数据方面获得更好的ROI。例如，如果Amazon S3占您账单的1%，那么计算租户的Amazon S3消费可能没有什么价值。

这里您要考虑的另一个因素是粒度。有一些侵入性较小的方法可以近似租户的消费量，这可能适合您的环境。这实际上可以归结为在您所追求的消费细节水平与检测和捕获数据的复杂性之间取得平衡，而这些数据需要对消费进行属性化。

让我们从最简单的租户消费近似模型开始。图25中的图表提供了一个概念视图，展示了在微创模型中捕获租户活动的一种方法。这里的基本方法是使用AWS Lambda授权器检查对API的每个调用。授权者将从传入的JWT中提取租户上下文，并发布一个事件，为租户记录此活动。另一种方法是使用AWS X射线来捕获这些数据（而不是亚马逊API网关）。

图25：租户消费的微创捕获

图上还有一个占位符，用于聚合和计算租户消费。您选择的填补这一空白的战略和工具将取决于数据的性质、其生命周期，以及它如何适合您更广泛的SaaS度量和分析故事。您可以选择将此数据作为SaaS环境的一般度量足迹的一部分，从而得出对租户分配消费至关重要的见解。

这种特定的方法依赖于跟踪每个租户的呼叫频率，以此推断每个租户的消费水平。虽然对服务的调用次数可能与消耗量不完全相关，但对于某些环境来说，这可能是一种合理的折衷。

通过在应用程序的细节中引入更专门的工具，可以创建更精细的消费视图。图26中的图表展示了如何将度量工具引入SaaS应用程序的微服务。

图26：用租户消费事件检测微服务

在本例中，我们将度量工具引入到应用程序的每个微服务中。这些微服务将捕获租户如何使用该服务及其相关资源的更详细数据。此详细数据将作为事件发布并聚合。在这里，我们展示了用于发布和接收数据的Amazon CloudWatch、AWS Lambda、Amazon Kinesis Data Firehose和Amazon S3。然后将分析这些数据，并根据您自己的建模得出租户之间的消费分布。

当您超越应用程序的微服务时，归因于租户消费变得更具挑战性。您可能需要在逐个服务的基础上制定特定的、有针对性的策略。例如，存储服务可能需要一个单独的服务来分析存储消耗。这可能需要查看IOPS、数据占用和其他因素，以分析租户的消费。

SaaS成本2：您如何将租户消费与基础设施成本联系起来？

SaaS环境的动态特性可能会使理解系统基础架构的成本状况可能会如何变化变得很困难。系统中租户的需求和组合的变化可能会导致SaaS环境运营成本的大幅波动。同时，SaaS业务需要清楚地了解租户如何影响成本，以做出关于如何构建、销售和运营其SaaS应用程序的战略决策。

为了了解更好地了解租户如何影响业务成本的商业价值，让我们看一个如何在SaaS环境中应用成本数据的示例。图27中的图表提供了一个场景的示例，其中SaaS环境的成本与这些租户的收入以及这些租户管理的电子商务目录的大小相关。

图27：每层租户的成本

该图说明了SaaS产品各层的成本分布。在这里，您将看到基本层和高级层租户的基础设施成本之间的巨大差异。关键的观察是，产生最小收入的基本层承担了系统基础设施成本的最大部分。同时，产生最多收入的高级层的成本足迹要小得多。这种不平衡可能意味着我们的模型有问题。

这只是一个示例，说明如何获取按租户和层划分的成本对SaaS提供商至关重要。通过访问此租户成本数据，SaaS组织可以评估可能影响环境成本状况的各种架构考虑因素。它还可以帮助指导定价和分层策略。

与汇编每个租户的成本数据相关的两个基本方面。首先，您需要一些方法来确定和计算租户消费，以得出每个租户的消费百分比（有关如何收集该消费数据的详细信息，请参见上文）。获得消费数据后，您需要将该数据与AWS账单中的成本信息相关联，以得出每个租户的成本计算结果。

有许多选项可用于访问收款账单数据。AWS提供了API，可用于获取和聚合这些计费数据，或者您可以探索一系列APN合作伙伴解决方案来获取这些数据并通过这些解决方案获取成本。这里最短的路径通常是与APN合作伙伴合作，处理吸收和汇总AWS成本的细微差别。

该体验的高级视图如图28所示。您将看到我们需要收集两组不同的数据。一个过程将汇总并摄取AWS账单中汇总成本的数据，其方式与与您的每租户成本模型相关的成本粒度一致。接下来，您将看到租户消费聚合，该聚合分析租户活动并为每个租户分配一个消费百分比。最后，将这些消耗百分比应用于基础设施成本，得出每个租户的成本。

图28：计算每个租户的成本

获得这些数据后，您可以选择如何最好地表示由此产生的成本。通常，在业务核心的一系列服务中，每个租户的成本似乎很有价值。但是，您可以使用权重并计算每个租户的总体成本，以便进行其他分析。

随时间优化

SaaS应用程序没有独特的成本做法。

资源

请参阅以下资源以了解有关AWS成本优化最佳实践的更多信息。

文档和博客

• 计算SaaS环境中的租户成本
• 计算每个租户的SaaS成本：AWS Kubernetes环境中的PoC实现
• SaaS指标深度挖掘：多租户分析
• SaaS分析和度量：捕获和处理对您成功至关重要的数据
• AWS中的监控工具

视频

• SaaS指标：租户消费的终极视角

卓越运营支柱包括运行和监控系统以实现业务价值并持续改进支持流程和程序的能力。

卓越运营支柱概述了设计原则、最佳实践和问题。您可以在卓越运营支柱白皮书中找到有关实施的规定性指南。

设计原则

在云计算中，有许多原则可以推动卓越的运营。

定义

云计算中有三个最佳实践领域可实现卓越运营：

• 准备
• 运转
• 发展

运营团队需要了解他们的业务和客户需求，以便他们能够有效地支持业务成果。运营部创建并使用程序来响应运营事件，并验证其有效性以支持业务需求。运营部门收集用于衡量预期业务成果实现情况的指标。一切都在不断改变您的业务环境、业务优先级、客户需求等。重要的是，设计运营以支持随着时间的推移而发生的变化，以应对变化，并将从其绩效中吸取的经验教训纳入其中。

最佳实践

话题

准备（Prepare）

SaaS应用程序没有独特的操作实践。

运转（Operate）

SaaS OPS 1：如何有效地监控和管理多租户环境的运行状况？

在多租户环境中，一个组织的所有客户都可能部署在一个共享的基础架构模型中，需要更详细的运行状况视图，这对于SaaS业务的成功和增长至关重要。任何停机或运行状况问题都有可能在系统的所有租户之间级联，并导致所有客户的SaaS服务中断。这意味着SaaS组织必须重视创建运营体验，使运营团队能够有效地分析和响应SaaS环境不断变化的工作负载。

构建强大的多租户运营体验需要SaaS公司创建或定制工具，以引入SaaS环境中所需的更精细的健康和活动视图。这通常意味着使用现有工具和定制解决方案的组合来创建一种支持租赁和租户层作为运营体验中的一流概念的体验。

例如，SaaS运营仪表板应包括通过租户和租户层的视角呈现的健康状况视图。虽然查看全球健康状况仍然是这种体验的一部分，但SaaS运营团队也需要能够查看租户的健康状况和活动。图12中的图表提供了SaaS提供商将租户活动作为一级结构呈现的一种方式的概念视图。

该图中的简化视图突出显示了一些操作视图的示例，这些示例将在多租户环境中增加价值。在页面的左上方，您将看到最活跃租户的健康状况视图。所显示的颜色指示器可以将注意力集中在租户身上，这些租户可能遇到的问题在从全球健康角度来看时尚未浮出水面。这使得运营部门能够对租户可能不太明显的任何问题做出反应和主动响应。

图12：租户感知操作视图

在该视图的右上方，您将看到租户资源消耗的数据。这里的想法是逐个租户查看AWS资源的使用情况，允许您查看特定租户是如何使用特定服务的。在底部，您将看到一个消费视图，说明租户如何消费应用程序的各种微服务。通过这里的数据，操作人员可以了解租户如何使用系统的各种服务，并确定特定租户或层是否正在饱和特定的微服务。

除了提供租户活动的一般视图外，您的运营经验还应包括深入了解各个租户和层的运营数据的能力。设想特定租户或租户层遇到问题的支持场景。在这些情况下，您希望能够访问运营数据，并通过特定租户或层的视角查看数据。这对于能够在多租户环境中解决和诊断问题至关重要。

创建这些操作视图依赖于能够访问操作数据，其中包括租户和分层上下文，而创建操作视图需要这些上下文来分析租户或租户层的见解。这需要SaaS架构师仔细考虑如何以及在何处将租户上下文注入用于记录健康和活动事件的各种机制。例如，日志应包含确保租户上下文（如租户标识符和层）注入系统日志数据的机制。

然而，您选择构建的视图将根据应用程序设计和架构的性质而有所不同。通常，团队应该考虑运营视图，这些视图将使运营团队能够有效地监控租户趋势，并从一开始就将工具构建到他们的环境中。在稍后的开发过程中将这些概念添加到应用程序中更具挑战性，并且可能会破坏开发和操作体验。

笔记

本白皮书中的问题编号已更改，以符合AWS良好架构工具的SaaS镜头中的顺序。SaaS OPS 2在以下最佳实践Evolve中进行了描述。

SaaS OPS 3：新租户如何加入您的系统？

SaaS解决方案高度关注最大化灵活性和创新。租户入职在这个敏捷故事中扮演着关键角色。通过创建一个促进无摩擦、可重复的入职流程的架构，SaaS组织能够简化、优化和扩展其能力，将新租户引入其SaaS环境。这使SaaS公司能够支持快速增长，并为客户提供加速其整体价值实现时间的体验。

需要注意的是，自动入职适用于B2C和B2B SaaS环境。虽然一些SaaS产品可能不包括自助入职体验，但这并不能减少对无摩擦入职体验的需求。即使当入职是一个内部执行的过程时，它仍然应该自动化租户创建的所有元素。减少摩擦的需求是创建符合SaaS最佳实践的解决方案的基础。

通常，SaaS应用程序的入职流程需要协调一系列共享服务，这些服务可以配置和提供引入新租户所需的所有资源。图13中的图表提供了如何通过一系列微服务实现这种入职的高级视图。

本图所示的入职体验流程涵盖了引入租户并让他们开始使用SaaS系统所需的所有步骤。在这个过程的前端，租户调用我们的注册服务，请求创建一个新租户。从这一点开始，注册服务将位于入职流程的中间，协调创建新租户环境所需的所有服务。

此过程的下一步是创建新用户。此新用户将代表此新租户的管理员。为了支持这个过程，我们提供了一个用户管理服务。该服务不保存用户的数据，但它在身份提供者中创建用户（在本例中是AmazonCognito）。它还创建支持此租户的隔离要求所需的任何IAM策略。

图13：无摩擦租户入职

在这个模型中，我们还依赖于为每个租户使用单独的Amazon Cognito用户池的策略。这允许我们为系统的每个租户定制身份体验（密码策略、多因素身份验证等）。通过选择此方法，我们必须将每个用户ID映射到相应的用户池。此映射由用户管理服务管理。

创建用户后，我们的流程现在创建一个租户。租户作为一种独特服务的这种分离对于SaaS环境至关重要。它提供了一种集中的方式来管理租户的状态和属性，与租户关联的用户完全分离。例如，租户的层或状态将由租户管理服务控制。

作为入职培训的一部分，SaaS系统通常必须在计费系统中建立足迹。在本例中，您将看到我们通知计费集成服务，我们正在创建一个新租户。然后，该服务负责向计费提供商创建新帐户。这包括为租户配置计划或层（免费、青铜、白金等）。

图中所示流程的最后一步与租户基础设施的配置有关。一些SaaS架构将包括专用租户资源。在这些情况下，我们的入职流程必须在激活租户之前提供这些新资源。

虽然此处所表示的流程可能会因环境的性质而有所不同，但此处所示的概念对于入职流程来说是通用的。自动化租户资源的创建、配置和供应是创建丰富、可扩展的多租户体验的基础。

SaaS OPS 4：您如何支持租户特定定制的需求？

SaaS架构师面临的一个重大挑战是，需要确保所有租户都运行相同版本的产品。对于已经迁移到SaaS并且已经习惯于通过一次性版本的产品支持独特客户需求的公司来说，这一点尤其如此。

尽管这看起来很诱人，但任何背离统一的客户管理、运营、支持和部署经验的做法都会直接损害SaaS组织的整体灵活性。随着每一个新的定制环境的引入，SaaS组织都会慢慢走向传统的软件模型。最终，这最终会侵蚀成本、运营效率和SaaS业务模式核心的一般创新目标。

因此，挑战是找到一种策略，使您能够满足这些偶尔的一次性需求，而不必创建产品的分叉版本。这里的妥协是通过引入添加到整体产品中的定制选项来实现的。因此，您可以投入额外的时间和精力来研究如何添加这些新功能，从而使所有客户都可以使用这些功能，而不是剥离单独的版本。然后，通过租户配置，您可以确定哪些租户将启用这些新功能。

解决这个问题的常见方法是使用功能标志。功能标志通常被应用程序开发人员用作在一个公共代码库中具有多个执行路径的一种方式，其中包含在运行时启用或禁用每个不同功能的标志。这种技术通常被用作通用开发策略，它提供了一种将定制引入SaaS环境的有效方法。每个功能标志将与租户配置选项相关。此配置将在运行时进行评估，并影响为每个租户启用的功能。

图14中的图表提供了如何应用这些标志的概念视图。将为单个租户打开和关闭一系列标志，以确定为租户启用了哪些功能。当租户注册SaaS产品的新功能时，将更改这些配置选项。在某些情况下，这些标志可以与层（而不是单个租户）相关联。

图14：使用功能标志管理租户需求

功能标志只是实现这一点的一种方式。这里的关键是，即使单个租户需要一个独特的功能，该功能也应该作为核心平台的定制而引入。根据系统的堆栈和设计，应用自定义的方式可能会有所不同。其目的是确保我们可以部署和管理产品的单一版本。

虽然这可能是一个强大的构造，但应谨慎应用。如果通过引入功能标志，您创建了一个复杂的选项迷宫，最终为每个租户提供了独特的体验，那么您的系统将很快变得无法管理。尝试选择如何以及何时引入这些标志。根据经验，企业不应将其视为一种销售工具，使组织能够为新客户提供一次性定制。

发展（Evolve）

SaaS OPS 2：您如何捕获和呈现可用于分析单个租户的使用和消费趋势的度量数据？

要不断发展您的SaaS运营体验，您需要访问丰富的运营数据集合，这些数据可用于分析您的多租户SaaS环境。这通常意味着从您的应用程序中检测和发布更丰富的租户指标集合，这些指标可以准确捕捉正在使用您的环境的租户的活动和消费模式。

SaaS指标超出了基础设施消耗（CPU、内存等）的基础，确定了对理解环境中多租户负载的操作至关重要的特定操作使用模式。对这些数据的分析将使SaaS组织能够评估其系统中正在发生的趋势，并确定对基础架构引入策略或更改的机会，从而不断提高SaaS产品的可靠性、可扩展性、成本效率和整体灵活性。

捕获和显示度量数据有两个不同的元素。首先，应用程序必须发布度量数据，这些数据可以为SaaS环境提供有用的运营见解。您需要确定应用程序中要捕获和发布这些度量的关键点。

这里的另一个难题是这些数据的摄取、聚合和呈现。您可以从AWS或AWS合作伙伴网络（APN）合作伙伴中选择多种工具。最终，这其中的摄取部分更像是一个数据仓库和商业智能问题。本文档前面列出的SaaS架构场景包括Tenant Insights场景。此场景概述了用于接收度量数据的体系结构。该体系结构代表了可以应用于解决这一需求的模式之一。

虽然我们这里的重点是这些租户指标的操作视图，但您可以想象这些指标在SaaS业务的多个上下文中都有使用。运营要求是您的体系结构，以确保组织积极收集和分析租户活动和消费趋势，以确定发展SaaS系统的机会。这符合构建基础工具的更广泛主题，该工具可用于评估租户和租户工作负载不断变化的组合。

Resources

Refer to the following resources to learn more about our best practices related to operational excellence.

Documentation & Blogs

• GPSTEC309-SaaS Monitoring Creating a Unified View of Multi-tenant Health featuring New Relic Slides

• Feature Toggles (aka Feature Flags)

Videos

• AWS re:Invent 2016: The Secret to SaaS (Hint: It's Identity) (GPSSI404)

• AWS re:Invent 2017: GPS: SaaS Monitoring - Creating a Unified View of Multi-tenant Health featuring New Relic (GPSTEC309)

本节描述了每一个支柱，并包括定义、最佳实践、问题、注意事项以及为多租户SaaS应用程序设计解决方案时相关的关键AWS服务。

为了简洁起见，我们只包含了SaaS工作负载特有的问题。在设计架构时，仍应考虑本文档中未包含的问题。我们建议您阅读AWS良好架构框架白皮书。

柱子

• Operational Excellence Pillar
• Security Pillar
• Reliability Pillar
• Performance Efficiency Pillar
• Cost Optimization Pillar
• Sustainability pillar

摘要

本文介绍了AWS良好架构框架的SaaS镜头，它使客户能够审查和改进其基于云的架构，并更好地理解其设计决策的业务影响。我们讨论了五个概念领域中的一般设计原则以及具体的最佳实践和指导，我们将其定义为良好架构框架的支柱。

介绍

AWS良好架构框架帮助您了解在AWS上构建系统时所做决策的利弊。通过使用该框架，您将学习在云中设计和运行可靠、安全、高效和经济高效的系统的架构最佳实践。它为您提供了一种方法，可以根据最佳实践一致地衡量您的体系结构，并确定需要改进的领域。我们相信，拥有良好的体系结构将大大增加业务成功的可能性。

在本“镜头”中，我们重点关注如何设计、部署和构建AWS云中的多租户软件即服务（SaaS）应用程序工作负载。为了简洁起见，我们只介绍了架构良好的框架中特定于SaaS工作负载的细节。在设计架构时，您仍应考虑本文档中未包含的最佳实践和问题。我们建议您阅读AWS良好架构框架白皮书。

本文档适用于担任技术职务的人员，如首席技术官（CTO）、架构师、开发人员和运营团队成员。阅读本文档后，您将了解在设计SaaS应用程序架构时要使用的AWS最佳实践和策略。