SaaS 应用程序是当今的新常态，软件提供商正在寻求将其应用程序转换为软件即服务应用程序。为此，唯一的解决方案是构建一个多租户架构的 SaaS 应用程序。您是否想过 Slack、Salesforce、AWS（亚马逊网络服务）和 Zendesk 如何为多个组织提供服务？每个客户是否都有其独特的定制云软件？例如，您是否注意到，在 Slack 上，您有自己的 URL“yourcompanyname.slack.com”？
大多数人认为，在后台，他们为每个组织创建了一个特定的环境——应用程序或代码库——并相信 Slack 客户拥有自己的服务器/应用程序环境。如果是您，您可能会假设他们有一个可重复的流程来为所有客户运行数以千计的应用程序。好吧，不。真正的解决方案是AWS 上用于 SaaS 应用程序的多租户架构。
让我们从这个令人印象深刻的事实开始：根据 IDC 研究，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。
另一方面，如果您正在使用实时聊天、迷你提要、流媒体等现代技术，那么请选择 Node.js。银行业有一个利用 Java 的市场，但那是针对成熟企业的。任何新的 SaaS 应用程序都可以更好地与提到的 Web 堆栈一起使用。同样，这正是我所注意到的趋势，也是社区的要求。
注意：此数据来自我们几个月前对金融服务和 SaaS 公司进行的一项调查。
理想的语言
云供应商
云供应商作为 DevOps 专家团队，我注意到过去两年中云的变化，这与这些百分比相对应：我们 70% 的 DevOps 实施基于 AWS，25% 使用 Azure，5% 使用 GCP 和数字海洋。每年的趋势都是相似的，除了 Azure 随着时间的推移逐渐增长。这些不仅是我的话，也是多个 DevOps 合作伙伴支持的想法。因此，我强烈建议在 AWS 下部署您的 SaaS 应用程序。它有很多好处；每天都有一项新服务可供您使用，以及一项有助于您开发和部署的新功能。完全推荐在 AWS 上部署您的 SaaS。
微服务
如果您打算利用云，则必须利用云原生原则。这些原则之一是将微服务与 Docker 相结合。确保您的 SaaS 应用程序处于微服务之下，这会带来多种好处，包括灵活性和标准化、更易于故障排除、问题隔离和可移植性。就像云一样，Docker 和微服务已经改变了 IT 生态系统，并将持续很长时间。
容器编排平台
这是一个复杂而抽象的决定； AWS 中提供了三个选项来管理、编排和创建微服务集群环境：
- Amazon ECS ：是AWS生态中天然的Amazon容器编排系统。 （强烈推荐给初创公司、小型 SaaS 和中型 SaaS）。
- Amazon Fargate ：几乎无服务器，价格和管理按任务计算。与 ECS 相比，操作工作量最少。我们的 DevOps 团队进行了一些研究；在性能方面。 Fargate 可能比 ECS 慢，因此对于这种特殊情况，我建议使用 Amazon ECS，而不是 Fargate。另一个想法是，如果您的团队是纯粹的开发人员并且不打算聘请 DevOps 工程师，那么 Fargate 可能是最佳选择。
- 亚马逊 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 ：更容易与 AWS 内置的自动化工具 Amazon Web Services 集成。每当有新的亚马逊技术发布时，与 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 平台、应用程序和数据库层中合并哪种多租户架构。这两种类型的多租户架构是：
- 应用层多租户。
- 数据库层多租户。
应用层多租户
应用程序层是一种架构设计，可为租户提供托管服务，主要用于软件即服务应用程序（SaaS 应用程序）。在第一个模型中，应用层通常由多个客户共享。
SaaS 的单体架构
如果您以前没有看过这篇文章——或者如果您已经开发和构建了自己的 SaaS 应用程序——我相信您已经采用了这种方法。单体组件包括 Web 层中的 EC2 实例、应用程序层以及用于数据库的带有 MySQL 的 Amazon RDS。单体架构不是一个坏方法，除了您在上述层中大量浪费资源。由于单体（云）架构的性质，至少有大约 50% 和 70% 的 CPU/RAM 使用被浪费了。
单体架构图
使用容器和 Amazon ECS 的 SaaS 微服务架构
微服务是一种推荐的架构类型，因为它们在现代化和最大限度地利用可用云资源（EC2 实例和计算单元）之间提供了平衡。它还引入了具有更细粒度服务（微服务）的分解系统。我们不会过多地谈论微服务的好处，因为它在社区中得到了广泛的表达。但是，我会建议您使用多租户架构 + AWS 服务 + 微服务 + Amazon ECS 的公式作为容器编排器；他们可以是绝配。主要考虑 Amazon ECS 为您的 DevOps 团队提供更少的集群配置工作和更多的 NoOps。
“到 2022 年，90% 的新应用程序将采用微服务架构，提高设计、调试、更新和利用第三方代码的能力； 35% 的生产应用程序将是云原生的。” —资料来源： 福布斯，2019 年
对于一个才华横溢的团队，最好的多租户 SaaS 架构方法就是这个用例场景。同样，它涵盖了 SaaS 软件和架构的主要属性，包括敏捷性、创新性、可重复性、缩短的周期时间、成本效率和可管理性。
绝配
多租户架构 + AWS 服务 + 微服务 + Amazon ECS（作为容器编排器）。
微服务架构图
使用 Amazon EKS 的 SaaS 的 Kubernetes 架构
您可能想知道：Kubernetes 或 Amazon EKS 怎么样？好吧，Kubernetes 是微服务架构的另一种选择，它在 SaaS 等式中增加了一层额外的复杂性。但是，您可以通过利用 Amazon EKS、Amazon Elastic Container Service for Kubernetes 来克服这种复杂性；来自 Amazon 的托管 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 Gateway 的数据库数据，作为无服务器 SaaS 应用程序的入口点。
现在您已经解耦了每个逻辑服务，身份验证和授权模块需要由第三方服务处理，例如 Amazon Cognito，它将负责识别租户、用户、层级、IAM 租户角色，并带来从这些方面支持 STS 代币。特别是，API 网关会将所有租户函数路由到与 STS 令牌匹配的正确 Lambda 函数。
下面是使用无服务器的 AWS SaaS 应用程序的多租户架构示例图。
无服务器架构图
数据库层多租户
多租户概念带有不同的架构层。我们已经提倡多租户应用层及其变体。现在，是时候探索数据库层的多租户了，这是另一个需要发现的方面。矛盾的是，最简单且具有成本效益的多租户数据库架构是纯粹且真实的数据库多租户。
数据库层正好与之前的模型应用层相反。在这里，DB层在租户之间保持公共，而应用层是隔离的。下一步，您需要评估采用何种多租户数据库架构来处理表、模式或孤立数据库。
选择数据库架构时，有多个评估标准：
- 可扩展性：租户数量、每个租户的存储、工作负载。
- 租户隔离
- 数据库成本：每个租户的成本。
- 开发复杂性：模式、查询等方面的变化。
- 操作复杂性：数据库集群、更新租户数据、数据库管理和维护。
单一数据库：每个租户一张表
每个租户单数据库一个表是指纯数据库多租户和池化模型。这种数据库架构是 DevOps 或软件架构师常用的默认解决方案。当拥有小型初创公司或几十个组织时，这是非常划算的。它包括在数据库模式中为每个组织利用一个表。这种架构有一些特定的权衡，包括牺牲数据隔离、租户之间的噪音和性能下降——这意味着一个租户可能会过度使用另一个租户的计算和 ram 资源。最后，每个表名都有自己的 tenantID，这对设计和架构师来说非常简单。
关于数据隔离和合规性，假设您的一位开发人员犯了一个错误，将错误的租户信息带给了您的客户。想象一下数据泄露——请确保永远不要公开来自多个租户的信息。这就是为什么兼容的 SaaS 应用程序不推荐这种架构模型，但是由于其成本效益而被广泛使用。
替代单租户数据库架构
单个数据库中单个模式中的单个模式中的共享表。非常适合 DynamoDB。 （我们没有介绍这种方法——仅供参考）。
单一数据库：每个租户一个模式
A schema per tenant single database，也称为桥接模型，是一种多租户数据库方式，它仍然比纯租户（DB pooled model）更划算和更安全，因为你是用一个单一的数据库，每个租户的数据库模式隔离除外。如果您担心数据分区，此解决方案比之前的解决方案（每个租户一张表）稍微好一些。同样，在应用程序代码配置中跨多个模式进行管理也很简单。
需要注意的一个重要区别是，如果一个数据库中有超过 100 个模式或租户，它可能会导致数据库性能滞后。因此，建议将数据库一分为二（将第二个数据库添加为副本）。但是，这种方法的最佳数据库工具是 PostgreSQL，它支持多种模式，而且不太复杂。最后，这种每个租户一个模式的策略在所有租户之间共享资源、计算和存储。结果，它激起了吵闹的租户，他们使用了比预期更多的资源。
每个租户的数据库服务器
也称为孤立模型，其中每个客户需要一个数据库实例。昂贵，但最适合隔离和安全合规性。这种技术比其他多租户数据库架构的成本要高得多，但它符合安全法规；性能、可伸缩性和数据隔离的最佳选择。此模式为每个租户使用一个数据库服务器，这意味着如果 SaaS 应用程序有 100 个租户，则将有 100 个数据库服务器，这非常昂贵。
当需要 PCI、HIPAA 或 SOC2 时，使用数据库孤立模型至关重要，或者至少找到具有正确 IAM 角色和最佳容器编排的解决方法——Kubernetes 或 Amazon ECS 命名空间——每个租户一个 VPC 和加密到处。
多租户数据库架构工具
- 带有 PostgreSQL 的 Amazon RDS（最佳选择）。
- DynamoDB（具有单个共享表的单租户数据库的绝佳选择）。
- 带有 MySQL 的亚马逊 RDS。
- 如前所述，GraphQL 在这些数据库中的任何一个前面使用它来提高数据检索速度、开发速度以及 RESTful API 的替代品，这有助于减轻从后备服务器到客户端的请求。
应用程序代码更改
一旦您在每一层都选择了多租户策略，让我们开始考虑代码级别需要更改的内容，即代码更改。如果您已决定为您的 SaaS 应用程序采用 Django（来自 Python），则需要进行一些调整以使您当前的应用程序与数据库和应用程序层的多租户架构保持一致。
幸运的是，Web 应用程序语言和框架能够捕获来自请求的 URL 或子域。在运行时获取此信息（子域）的能力对于处理多租户架构的动态子域至关重要。我们不会深入介绍我们需要在您的 Django 应用程序或任何其他框架中包含哪些代码行，但至少，我会让您知道本节中应考虑哪些项目。
简而言之，Python Django 多租户
- 添加一个名为 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 ” CNAME “ 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.conf和服务器块（虚拟主机）。为您的 Nginx Web 服务器设置通配符虚拟主机。确保它是一个别名 (ServerAlias) 和一个包罗万象的通配符站点。您不必为每个租户在 Nginx 中创建子域 VirtualHost；相反，您需要为所有租户设置一个通配符 VirtualHost。自然地，通配符模式将匹配您的子域并相应地路由到您的 SaaS 应用程序文档根目录的正确且唯一的补丁。
证书
只是不要忘记处理租户子域下的证书。您需要将它们添加到 Cloudfront CDN、负载均衡器或您的 Web 服务器中。
注意：此解决方案可以使用 Apache 网络服务器来完成。
遵循 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 环境的过程。您需要触发脚本来启动新的多租户环境或将其附加到现有的多租户架构，这意味着自动设置新租户。考虑可能是在您的客户在您的入职页面上注册之后，或者您需要手动触发脚本。
自动化工具
- Terraform（推荐）
- Amazon CloudFormation（信任 AWS CloudFormation 认证团队）Ansible。
注意：确保您在这方面使用基础架构即代码原则。
孤立的计算和孤立的存储
您的架构将如何与其他租户隔离？您只需要确定下一个：SaaS 应用程序的每一层都需要隔离。客户工作流程涉及多个层、页面、后端、网络、前端、存储等等，所以……您的隔离策略如何？
请记住下一个方面：
- 每个功能或微服务的 IAM 角色。
- 亚马逊 S3 安全政策。
- VPC隔离。
- Amazon ECS/Kubernetes 命名空间隔离。
- 数据库隔离（每个表/模式/筒仓数据库的租户）。
租户计算能力
您是否考虑过每个环境可以支持多少 SaaS 租户？试想一下，您有 99 个租户，计算/数据库负载几乎达到极限，您是否有支持新租户的现成环境？数据库呢？您有一个特定的客户，希望为其 SaaS 应用程序提供一个隔离的租户环境。 How would you support an extra tenant environment that is separated from the rest of the multi-tenant architecture? Would you do it? What are the implications? Just consider a scenario for this aspect.
Tenant Clean-Up
What are you doing with the tenants that are idle or not used anymore? Perhaps a clean-up process for any tenant that has been inactive for a prolonged period, or removes unused resources and tenants by hand, but you need a process or automation script.
最后的想法
Multi-tenant architecture and SaaS applications under AWS. What a topic that we just discovered! Now, you understand the whole multi-tenant SaaS architecture cycle from end-to-end, including server configuration, code, and what architecture pursues per every IT layer. As you can notice, there is no global solution for this ecosystem. There are multiple variants per each IT layer, either all fully multi-tenant, partially tenant, or just silo tenants. It falls more on what you need, budget, complexity, and the expertise of your DevOps team.
I strongly recommend going for microservices (ECS/EKS), partially multi-tenant SaaS in the app, and database layer. As well, include cloud-native principles, and finally, adopt the multi-tenant architecture best practices and considerations described in this article. That being said, brainstorm your AWS SaaS architecture firstly by thinking on how to gain agility, cost-efficiency, IT labor costs, and leveraging a nearshore collaboration model, which adds another layer of cost-savings.
In regard, automation with Terraform and CloudFormation is our best choice. Even better, most of our AWS/DevOps projects are following PCI, HIPAA, and SOC2 regulations. If you are a fintech, healthcare, or SaaS company, well, you know this type of requirement should be included in your processes.