适用于 AWS 上 SaaS 应用程序的多租户架构

SaaS 应用程序是当今的新常态，软件提供商正在寻求将其应用程序转换为软件即服务应用程序。为此，唯一的解决方案是构建多租户架构 SaaS 应用程序。你有没有想过Slack，Salesforce，AWS（亚马逊网络服务）和Zendesk如何为多个组织提供服务？每个客户是否有其独特的自定义云软件？例如，你有没有注意到，在Slack上，你有自己的网址“yourcompanyname.slack.com”？

大多数人认为，在后台，他们为每个组织创建了一个特定的环境（应用程序或代码库），并认为 Slack 客户拥有自己的服务器/应用程序环境。如果是你，你可能认为他们有一个可重复的过程来跨所有客户运行数千个应用程序。嗯，没有。真正的解决方案是 AWS 上用于 SaaS 应用程序的多租户架构。

让我们从这个令人印象深刻的事实开始：根据 IDC Research 的数据，70% 的 Web 应用程序被视为 SaaS 应用程序。因此，如果您了解 SaaS 架构和多租户，您可能会涵盖未来可用的 70% 的 Web 应用程序架构环境。

“70% 的 Web 应用程序是 SaaS，但其中只有少数是多租户的。

本研究旨在概述 DevOps 和软件开发人员在构建 SaaS 多租户应用程序时可能面临的策略、挑战和约束。

在开始之前，有两个概念对我们来说很重要：

接下来的几点是我们将在 SaaS 应用程序的多租户架构中探索的内容，我的贡献将是：

什么是多租户体系结构？

首先，您需要了解什么是单租户和多租户架构：

• 单租户体系结构（孤立模型）：是每个组织的单个体系结构，其中应用程序具有自己的基础结构、硬件和软件生态系统。假设您有十个组织;在这种情况下，您需要创建十个独立环境，您的 SaaS 应用程序或公司将作为单租户体系结构运行。此外，它还意味着更多的成本、维护和跨环境更新的难度。

• 多租户体系结构：是一个生态系统或模型，其中单个环境可以利用可缩放、可用且可复原的体系结构为多个租户提供服务。底层基础架构是完全共享的，逻辑隔离，并且具有完全集中的服务。多租户架构根据登录到 SaaS 应用程序的组织或子域 （organization.saas.com） 而发展;并且对最终用户完全透明。

请记住，在本文中，我们将讨论两个多租户架构模型，一个用于应用层，一个用于数据库层。

多租户优势

采用多租户架构方法将为您的 SaaS 应用程序带来广泛的宝贵优势。

让我们来看看下一个贡献：

• 利用多租户架构策略降低服务器基础架构成本：

• 您无需为每个客户创建一个 SaaS 环境，而是为所有客户包含一个应用程序环境。这使您的 AWS 托管成本从数百台服务器大幅降低到一台服务器。

• 单一信任来源：

• 再假设您有一个客户使用您的 SaaS。想象一下，每个客户将有多少代码存储库。每个客户至少有 3-4 个分支，这将产生大量开销和代码发布。更糟糕的是，可视化将代码部署到整个租户场的过程;这是极其复杂的。这是不可行的，而且很耗时。使用多租户 SaaS 体系结构，可以避免这种类型的冲突，其中你将拥有一个代码库（信任源）和一个包含几个分支的代码存储库（开发/测试/生产）。通过遵循以下做法（使用单个命令（一键式部署），您将在几秒钟内快速执行部署过程。

• 降低开发成本并缩短上市时间：

• 成本降低考虑要做出的一系列决策，例如拥有单个代码库、SaaS 平台环境、多租户数据库架构、集中式存储、API 以及遵循十二因素方法。所有这些都将使您能够降低开发劳动力成本、上市时间和运营效率。

适用于 AWS 架构的 SaaS 技术堆栈

要构建多租户架构，您需要将正确的 AWS Web 堆栈（包括操作系统、语言、库和服务）集成到 AWS 技术中。这只是创建下一代多租户体系结构的第一步。

尽管我们将介绍其他一些多租户架构最佳实践，但本文将主要面向此 AWS SaaS Web 堆栈。

让我们深入了解 AWS 上的 SaaS 技术堆栈：

程序设计语言

选择哪种语言平台并不重要。至关重要的是，您的应用程序可以扩展、利用多租户架构最佳实践、云原生原则和开源社区的知名语言。构建SaaS应用程序的最新趋势是Python + React + AWS。另一个“变体”是 Node.js + React + AWS，但最终，共同点始终是 AWS 和 React。如果你是一家金融公司，ML或AI，有复杂的算法或后端工作，我会说你应该选择Python。

另一方面，如果您使用的是实时聊天、迷你提要、流媒体等现代技术。然后转到节点.js。银行业有一个利用Java的市场，但这是针对成熟企业的。任何新的SaaS应用程序都更适合上述Web堆栈。同样，这只是我注意到的趋势，也是社区所要求的。

注意：此数据来自我们几个月前为金融服务和 SaaS 公司进行的一项调查。

理想语言

云提供商

作为一个DevOps专家团队，我注意到过去两年的云变化，这与这些百分比相对应：我们70%的DevOps实施基于AWS，25%基于Azure，5%用于GCP和数字海洋。每年的趋势都是相似的，只是Azure随着时间的推移而逐渐增长。这些不仅是我的话，也是多个 DevOps 合作伙伴支持的想法。因此，我强烈建议在 AWS 下部署您的 SaaS 应用程序。它有许多好处;每天都有一项新服务可供您使用，以及一项有助于开发和部署的新功能。完全建议在AWS上部署SaaS。

微服务

如果计划利用云，则必须利用云原生原则。其中一个原则是将微服务与 Docker 合并。确保您的 SaaS 应用程序处于微服务下，这会带来多种好处，包括灵活性和标准化、更易于故障排除、问题隔离和可移植性。就像云一样，Docker和微服务已经改变了IT生态系统，并将持续很长时间。

容器编排平台

这是一个复杂而抽象的决定;AWS 中有三个选项可用于管理、编排和创建微服务集群环境：

1. Amazon ECS：它是 AWS 生态系统中天然的 Amazon 容器编排系统。（强烈推荐给初创公司、小型 SaaS 和中型 SaaS）。

2. Amazon Fargate：几乎无服务器，价格和管理是按任务进行的。与 ECS 相比，操作工作量最小。我们的 DevOps 团队进行了一些研究;在性能方面。Fargate 可能比 ECS 慢，因此对于这种特殊情况，我会推荐 Amazon ECS，而不是 Fargate。另一个想法是，如果你的团队是纯粹的开发人员，不打算聘请DevOps工程师，也许Fargate是你要走的路。

3. Amazon EKS：这是一项托管服务，使 AWS 上的 Kubernetes 易于管理。使用 Amazon EKS 而不是在 EC2 实例上部署 Kubernetes 集群，而是设置 Kubernetes 联网和工作节点。（推荐用于大型 SaaS 应用以及复杂的 DevOps 和 Web 开发团队）。

数据库

固有的数据库将是带有Amazon RDS的PostgreSQL。但是，我强烈建议，如果您有一个高级开发团队，并且正在为您的 SaaS 应用程序（甚至数百个租户）预测高流量，您最好使用 MongoDB 构建您的数据库。除此之外，还要利用下面将提到的有关多租户数据库的最佳做法。在这种情况下，我会选择带有PostgreSQL或DynamoDB（MongoDB）的Amazon RDS。

“如果你正在为你的SaaS应用程序预测一个高流量，你最好用MongoDB构建你的数据库。

GraphQL 或 Amazon AppSync

GraphQL 是一种查询语言，是数据库服务的 RESTful API 的替代方案。这个新的现代生态系统被采用为客户端和数据库服务器之间的中间人。它允许您更快地检索数据库数据，减少数据库中的过度提取，从 GraphQL 模式中检索所需的准确数据，并通过比 RESTful 服务更快的迭代来保持开发速度。将整体式后端应用程序采用到多租户微服务架构中是利用 GraphQL 或 AppSync 的最佳时机。因此，在转换您的 SaaS 应用程序时，不要忘记包含 GraphQL！

注： 我没有在 AWS SaaS 架构图中包含此服务，因为它以多种方式实现，并且需要对此主题进行深入解释。

自动化

您需要一种机制来触发或启动新租户/组织，并将其附加到多租户 SaaS 体系结构。假设您有一个刚刚订阅 SaaS 应用程序的新客户端，您如何将这个新组织包含在您的环境、数据库和业务逻辑中？

需要一个自动化过程来启动新租户;这称为基础结构即代码 （IaC）。此脚本/过程应位于 git/bitbucket 存储库中，这是 DevOps 的基本原则之一。利用自动化和 IaC 的一个有力论据是，您需要一种机制来自动化代码部署的 SaaS 应用程序。同样，自动为开发/测试环境预配新基础结构。

基础架构即代码和自动化工具

使用哪种基础设施即代码工具并不重要，它们都很有用（Terraform 和 CloudFormation）;他们做同样的工作，并且被DevOps社区所高度认可。我没有赢家，他们都很好。

• Terraform（来自Hashicorp）：一种流行的与云无关的工具。广泛用于所有 DevOps 社区。使用此技能更容易找到DevOps。

• Amazon CloudFormation：更容易与 Amazon Web Services（AWS 内置自动化工具）集成。每当有新的Amazon技术刚刚发布时，与AWS和CloudFormation的兼容性都会比Terraform更早发布。信任 AWS CloudFormation 专家，以安全的方式实现自动化和发布。

消息队列系统 （MQS）

常见的 MQS 是 Amazon SQS、RabbitMQ 或 Celery。我在这里建议的是利用需要较少操作的服务，在这种情况下，是 Amazon SQS。多次需要异步通信。从延迟或安排任务，到提高关键 Web 事务的可靠性和持久性，分离您的整体式或微服务应用程序，最重要的是：使用队列系统来通信事件驱动的无服务器应用程序（Amazon Lambda 函数）。

缓存系统

AWS ElastiCache 是一个完全可扩展、可用且可管理的缓存和数据存储系统。它旨在提高分布式缓存数据和内存中数据结构存储的应用程序性能。它是 Memcached 和 Redis 引擎的内存中键值存储。只需单击几下，您就可以完全自行管理地运行此 AWS 组件。为您的 SaaS 应用程序包含一个缓存系统至关重要。

云存储系统

Amazon S3 和 Amazon CloudFront CDN 用于您的静态内容。所有静态内容（包括图像、媒体和 HTML）都将托管在 Amazon S3 上，这是一个具有无限存储和弹性的云系统。在Amazon S3之前，我们将包括AWS CloudFront，集成这对元素至关重要，以便缓存整个静态内容并降低带宽成本。

SaaS Web 堆栈：AWS 上的多租户 SaaS 架构示例

多租户 SaaS 架构的类型

多租户采用中最重要的问题之一是哪种多租户架构更适合您在 AWS 上的 SaaS 应用程序。我们将探讨使您的应用程序充当真正的 SaaS 平台所需的两层，因为决定您将在 SaaS 平台、应用程序和数据库层中合并哪个多租户架构至关重要。这两种类型的多租户体系结构是：

1. 应用层多租户。

2. 数据库层多租户。

应用层多租户

应用程序层是一种体系结构设计，可为租户提供托管，主要用于软件即服务应用程序（SaaS 应用）。在第一种模型中，应用层通常在多个客户之间共享。

适用于 SaaS 的整体式架构

如果您以前没有看过这篇文章，或者您已经开发和构建了自己的 SaaS 应用程序，我相信您已经陷入了这种方法。整体式组件包括 Web 层中的 EC2 实例、应用程序层和适用于您的数据库的带有 MySQL 的 Amazon RDS。整体式体系结构不是一种坏方法，除了您在上述层中大量浪费资源。由于单片（云）架构的性质，至少浪费了大约 50% 和 70% 的 CPU/RAM 使用量。

单片架构图

适用于具有容器和 Amazon ECS 的 SaaS 的微服务架构

微服务是推荐的架构类型，因为它们在现代化和最大限度地利用可用云资源（EC2 实例和计算单元）之间实现了平衡。此外，它还引入了具有更精细服务（微服务）的分解系统。我们不会过多地谈论微服务的好处，因为它在社区中得到了广泛的表达。但是，我建议您使用多租户架构 + AWS 服务 + 微服务 + Amazon ECS 的公式作为容器编排器;它们可以是完美的匹配。主要是，考虑到 Amazon ECS 配置集群的工作量更少，而您的开发运营团队的 NoOps 更多。

“到2022年，90%的新应用程序将采用微服务架构，提高设计、调试、更新和利用第三方代码的能力;35%的生产应用程序将是云原生的。 —来源：福布斯，2019 年

拥有才华横溢的团队，最好的多租户 SaaS 架构方法是此用例场景。同样，它涵盖了 SaaS 软件和架构的主要属性，包括敏捷性、创新、可重复性、缩短周期时间、成本效率和可管理性。

完美搭配

多租户架构 + AWS 服务 + 微服务 + Amazon ECS（作为容器编排器）。

微服务架构图

Kubernetes Architecture for SaaS With Amazon EKS

您可能想知道：Kubernetes 或 Amazon EKS 呢？好吧，Kubernetes 是微服务架构的另一种选择，它在 SaaS 等式中增加了一层额外的复杂性。但是，您可以通过利用 Amazon EKS（适用于 Kubernetes 的 Amazon Elastic Container Service）来克服这种复杂性;来自亚马逊的托管 Kubernetes 服务，这是 Kubernetes 社区事实上的服务。

与其他体系结构相比，此组件的亮点在于它提供了命名空间的使用。此属性有助于隔离相应 Kubernetes 群集中的每个租户及其自己的环境。从这个意义上说，您不必为每个租户创建不同的集群（您可以，但为了满足不同的方法）。通过使用 ResourceQuota，可以限制每个命名空间使用的资源，并避免对其他租户产生干扰。要考虑的另一点是，如果要隔离命名空间，则需要包含 Kubernetes 网络策略，因为默认情况下，网络是开放的，可以跨命名空间和容器进行通信。

以下是 Amazon ECS 与 Kubernetes 的比较。如果你有一个 SaaS 企业，我会建议最好通过 Amazon EKS 或 Kubernetes 来控制你的微服务，因为它允许你进行更精细的更改。

那么，Kubernetes 多租户架构会是什么样子呢？这是一个简单的 Kubernetes 多租户架构，并按其各自的命名空间孤立。

Kubernetes 架构图

一个简单的多租户架构，包含 Kubernetes，由 Kubernetes 命名空间孤立。

适用于 AWS 上的 SaaS 的无服务器架构

任何 AWS 架构师的梦想都是使用无服务器方法创建多租户 SaaS 架构。作为DevOps或SaaS架构师，这是一个可以实现的梦想，但它特别增加了相当多的复杂性作为权衡。此外，它还需要与开发团队进行合理的协作时间、代码应用程序的广泛更改以及变革性的无服务器思维方式。鉴于几年后，它将成为最终的解决方案，而这一切都取决于人才、能力和用例。

无服务器 SaaS 架构使应用程序能够获得更高的敏捷性、弹性和更少的开发工作，从而形成真正的 NoOps 生态系统。

在高级别上，这种下一代无服务器 SaaS 架构的新部分是什么？每个调用都将成为独立的租户调用，要么转到逻辑服务（Lambda 函数），要么转到来自 Amazon API 网关的数据库数据，作为无服务器 SaaS 应用程序中的入口点。

现在，您已经分离了每个逻辑服务，身份验证和授权模块需要由第三方服务（如 Amazon Cognito）处理，该服务将负责识别租户、用户、层、IAM 租户角色，并带回具有这些方面的 STS 令牌。具体而言，API 网关会将所有租户函数路由到与 STS 令牌匹配的正确 Lambda 函数。

下面是使用无服务器的 AWS SaaS 应用程序的多租户架构示例图。

无服务器体系结构图

数据库层多租户

多租户概念带有不同的架构层。我们已经提倡多租户应用层及其变体。现在，是时候探索数据库层中的多租户了，这是另一个需要发现的方面。矛盾的是，最简单且具有成本效益的多租户数据库架构是纯数据库多租户。

数据库层与以前的模型（应用程序层）正好相反。在这里，数据库层在租户之间保持通用，应用程序层是隔离的。下一步，您需要评估对表、架构或孤立数据库采用的多租户数据库体系结构。

选择数据库体系结构时，需要评估多个标准：

• 可伸缩性：租户数、每个租户的存储数、工作负载。

• 租户隔离

• 数据库成本：每个租户成本。

• 开发复杂性：架构、查询等的更改。

• 操作复杂性：数据库群集、更新租户数据、数据库管理和维护。

单一数据库：每个租户一个表

每个租户单一数据库的表是指纯数据库多租户和池模型。此数据库体系结构是 DevOps 或软件架构师的常见默认解决方案。当拥有小型初创公司或几十个组织时，这是非常划算的。它包括利用数据库架构中每个组织一个表。此体系结构存在特定的权衡，包括牺牲数据隔离、租户之间的噪音和性能下降，这意味着一个租户可能会过度使用另一个租户的计算和 RAM 资源。最后，每个表名都有自己的 tenantID，这在设计和架构方面非常简单。

关于数据隔离和合规性，假设您的某个开发人员犯了一个错误，并将错误的租户信息带给了您的客户。想象一下数据泄露 - 请确保永远不要公开来自多个租户的信息。这就是为什么不建议使用兼容的SaaS应用程序，但是由于其成本效益而广泛使用此体系结构模型的原因。

替代单租户数据库体系结构

单个数据库中单个架构中的共享表。非常适合 DynamoDB。（我们没有介绍这种方法 - 仅供参考）。

单一数据库：每个租户的架构

每个租户单一数据库的架构（也称为桥接模型）是一种多租户数据库方法，它仍然比纯租户（数据库池模型）非常经济高效且更安全，因为您使用的是单个数据库，但每个租户的数据库架构隔离除外。如果担心数据分区，此解决方案比前一个解决方案（每个租户一个表）略好。同样，在应用程序代码配置中跨多个架构进行管理也很简单。

需要注意的一个重要区别是，如果数据库中的架构或租户超过 100 个，则可能会导致数据库性能滞后。因此，建议将数据库一分为二（将第二个数据库添加为副本）。但是，这种方法的最佳数据库工具是PostgreSQL，它支持多种模式而不会太复杂。最后，此策略（每个租户的架构）在其所有租户之间共享资源、计算和存储。因此，它会引起嘈杂的租户，这些租户使用的资源比预期的要多。

每个租户的数据库服务器

还可以调用孤立模型，其中每个客户需要一个数据库实例。价格昂贵，但最适合隔离和安全合规性。此技术比其他多租户数据库体系结构的成本高得多，但它符合安全法规;性能、可扩展性和数据隔离的最佳选择。此模式对每个租户使用一个数据库服务器，这意味着如果 SaaS 应用有 100 个租户，则会有 100 个数据库服务器，这非常昂贵。

当需要 PCI、HIPAA 或 SOC2 时，利用数据库孤立模型至关重要，或者至少找到具有正确 IAM 角色和最佳容器编排（Kubernetes 或 Amazon ECS 命名空间）、每个租户一个 VPC 并在任何地方进行加密的解决方法。

多租户数据库架构工具

• Amazon RDS with PostgreSQL（最佳选择）。

• DynamoDB（对于具有单个共享表的单租户数据库来说，这是一个不错的选择）。

• Amazon RDS with MySQL。

• 如前所述，GraphQL 在任何这些数据库的前面使用它来提高数据检索速度、开发速度和 RESTful API 的替代方案，这有助于减轻从支持的服务器到客户端的请求。

应用程序代码更改

在每个层中选择多租户策略后，让我们开始考虑代码级别需要更改的代码更改。如果您决定为您的 SaaS 应用程序采用 Django（来自 Python），则需要进行一些调整更改，以使当前应用程序与数据库和应用程序层的多租户架构保持一致。

幸运的是，Web 应用程序语言和框架能够捕获来自请求的 URL 或子域。在运行时获取此信息（子域）的能力对于处理多租户体系结构的动态子域至关重要。我们不会深入介绍我们需要在你的 Django 应用程序或任何其他框架中包含哪些代码行，但至少，我会让你知道本节应该考虑哪些项目。

Python Django Multi-Tenancy in a 簡而言之

• 添加一个名为 tenant.py 的应用：具有多个池类的类。tenantAwareModel

• 如何识别租户：需要为每个租户提供一个子域;为此，您需要修改一些DNS更改，Nginx / Apache调整，并添加实用程序方法（utils.py）。现在，只要有请求，就可以使用此方法获取租户。

• 确定如何使用主机标头提取租户：（子域）。

• 管理员隔离

注意： 以前的代码建议可能会根据体系结构而更改。

通配符 DNS 子域：基于 URL 的 SaaS 平台

基本上，每个组织都必须有自己的子域，它们对于识别组织非常有用。每个租户，它是一个独特的专用空间、环境和自定义应用程序（至少在逻辑上）;例如，“org1.saas.com”、“org2.saas.com”等。此 URL 结构将动态预配 SaaS 多租户应用程序，此 DNS 更改将有助于每个租户的标识、身份验证和授权。但是，另一种解决方法称为基于每个租户的路径，不建议这样做，例如“app.saas.com/org1/...”、“app.saas.com/org2\...”等。

因此，此特定部分中需要以下内容：

• DNS 管理记录中应有通配符记录。

• 此通配符子域将所有路由重定向到您的多租户架构（负载均衡器、应用程序服务器或集群端点）。

• 同样，标有 （*） 的 CNAME 记录指向您的“app.saas.com”或“saas.com/login”。星号 （*） 表示应用域的通配符。

• 最后一步，另一 （A） 条记录将您的“app.saas.com”域指向您的 Amazon ECS 集群、ALB 或 IP。

DNS 记录条目

• “*.saas.com” 别名 “app.saas.com”

• “app.saas.com”A 1.2.3.4 或“app.saas.com”A（别名）balancer.us-east-1.elb.amazonaws.co

注意：（A） 别名记录是指当您使用 AWS 中的 ALB/ELB（负载均衡器）时。

使用 NGINX 配置进行 Web 服务器设置

让我们转到您的Web服务器，特别是Nginx。在此阶段，您需要配置服务器块（虚拟主机）。为您的 Nginx Web 服务器设置通配符虚拟主机。确保它是别名（服务器别名）和捕获通配符站点。您不必为每个租户在 Nginx 中创建子域 VirtualHost;相反，您需要为所有租户设置一个通配符 VirtualHost。当然，通配符模式将匹配您的子域，并相应地路由到 SaaS 应用程序文档根的正确且唯一的补丁。Nginx.conf

SSL证书

只是不要忘记处理租户子域下的证书。您需要在 Cloudfront CDN、负载均衡器或 Web 服务器中添加它们。

注意：此解决方案可以使用 Apache Web 服务器完成。

遵循 12 因素方法论框架

遵循 12 因素方法代表了纯粹的 DevOps 和云原生原则，包括不可变的基础架构、与 Docker 的开发/测试和产品奇偶校验、CI/CD 原则、无状态 SaaS 应用程序等。

多租户 SaaS 架构最佳实践

您的 SaaS 平台将如何扩展？

多租户 SaaS 体系结构最佳做法包括：

• Amazon AutoScaling，使用 EC2 实例或微服务。

• 使用 Amazon RDS、Amazon Aurora 或 DynamoDB 进行数据库复制。

• 应用程序负载均衡器。

• 包括用于静态内容的 CloudFront CDN。

• 适用于所有静态/媒体内容的 Amazon S3。

• 缓存系统，包括 Redis/Memcached 或 AWS 云中的等效系统 — Amazon ElastiCache。

• 为冗余和可用性设置多可用区。

使用 CI/CD 进行代码部署

要考虑的另一个关键方面是如何跨租户和多个环境（开发、测试和生产）部署代码发布。你将需要一个持续集成和持续交付 （CI/CD） 过程来简化所有环境和租户的代码发布。如果您跟进我以前的最佳实践，那将不难。

采用 CI/CD 的工具

CI/CD 工具：Jenkins、CircleCi 或 AWS Code 管道（以及 Codebuild 和 CodeDeploy）。

我的建议：如果你想要一个复杂的DevOps团队和一个广为人知的工具，那就选择Jenkins;否则，请选择CircleCI。如果您想继续独家利用 AWS 技术，请选择 AWS 代码管道。但是，如果您正在寻找合规性、银行或受监管的环境，请选择 Gitlab。

DevOps 自动化：自动执行新租户创建过程

如何为每个订阅创建新租户？确定将新租户启动到 SaaS 环境中的过程。需要触发脚本来启动新的多租户环境或将新的多租户环境附加到现有的多租户体系结构，这意味着自动设置新租户。请考虑它可以是在您的客户在您的入职页面中注册之后，或者您需要手动触发脚本。

自动化工具

• 地形（推荐）

• Amazon CloudFormation （Trust on a AWS CloudFormation certified team） Ansible。

注意：确保在这方面使用基础结构即代码原则。

孤立的计算和孤立的存储

如何将体系结构与其他租户隔离？您只需要确定下一个：SaaS 应用程序的每一层都需要隔离。客户工作流涉及多个层、页面、后端、网络、前端、存储等多个位，因此...您的隔离策略如何？

请记住下一个方面：

• 每个函数或微服务的 IAM 角色。

• Amazon S3 安全策略。

• 专有网络隔离。

• Amazon ECS/Kubernetes 命名空间隔离。

• 数据库隔离（每个表/架构/思洛存储器数据库的租户）。

租户计算容量

您是否考虑过每个环境可以支持多少个 SaaS 租户？试想一下，您有 99 个租户，计算/数据库负载几乎达到极限，您是否有现成的环境来支持新租户？数据库呢？您有一个特定的客户，该客户希望为其 SaaS 应用程序提供隔离的租户环境。如何支持与多租户体系结构的其余部分分离的额外租户环境？你会这样做吗？有什么影响？只需考虑这方面的场景。

租户清理

如何处理空闲或不再使用的租户？对于长时间处于非活动状态的任何租户，或者手动删除未使用的资源和租户，这可能是清理过程，但你需要一个过程或自动化脚本。

结语

AWS 下的多租户架构和 SaaS 应用程序。我们刚刚发现了什么话题！现在，您了解了从端到端的整个多租户 SaaS 架构周期，包括服务器配置、代码以及每个 IT 层追求的架构。正如您所注意到的，这个生态系统没有全球解决方案。每个 IT 层有多个变体，要么是完全多租户，要么是部分租户，要么只是筒仓租户。它更多地取决于你需要什么、预算、复杂性和你的 DevOps 团队的专业知识。

我强烈建议使用微服务 （ECS/EKS）、应用程序中的部分多租户 SaaS 和数据库层。此外，还包括云原生原则，最后，采用本文中所述的多租户体系结构最佳做法和注意事项。话虽如此，首先要考虑如何获得敏捷性、成本效益、IT 劳动力成本，并利用近岸协作模型来集思广益您的 AWS SaaS 架构，从而节省另一层成本。

在这方面，使用Terraform和CloudFormation实现自动化是我们的最佳选择。更好的是，我们的大多数 AWS/DevOps 项目都遵循 PCI、HIPAA 和 SOC2 法规。如果您是金融科技，医疗保健或SaaS公司，那么您知道此类要求应包含在您的流程中。