基于AWS云SaaS多租户架构设计

基于AWS云SaaS多租户架构设计

租户与用户概念

单租户与多租户

多租户的好处
采用多租户架构方法将为你的SaaS应用程序带来广泛的有价值的好处。

让我们来看看下面的贡献。

a) 利用多租户架构策略，减少服务器基础设施成本。

与其为每个客户创建一个SaaS环境，不如为所有客户提供一个应用环境。这使你的AWS托管成本从数百台服务器大幅减少到一个。

b) 一个单一的信任来源。

让我们再次假设你有一个使用你的SaaS的客户，想象一下，你会为每个客户拥有多少个代码库？每个客户至少有3-4个分支，这将是大量的开销和错位的代码发布。更糟糕的是，想象一下将你的代码部署到整个租户农场的过程；这是很复杂的。这是不可行的，而且很费时间。有了多租户SaaS架构，你就可以避免这种类型的冲突，你会有一个代码库（信任源），和一个有几个分支的代码库（dev/test/prod）。通过下面的实践，--用一个命令（一键部署）--你将在几秒钟内迅速完成部署过程。

c) 降低开发成本，缩短上市时间。
降低成本需要考虑一连串的决定，例如拥有一个单一的代码库、SaaS平台环境、多租户数据库架构、集中存储、API，以及遵循 "十二要素法"；所有这些都将使你减少开发人力成本，缩短上市时间，并提高运营效率。

SaaS web stack:基于AWS云SaaS 多租户架构

       亚马逊S3和亚马逊CloudFront CDN为您提供静态内容。所有的静态内容，包括图片、媒体和HTML，将被托管在Amazon S3上，这是一个具有无限存储和弹性的云系统。在Amazon S3的前面，我们将包括AWS CloudFront，整合这一对元素是至关重要的，以便缓存整个静态内容并减少带宽成本。

消息队列系统（MQS）
常见的MQS是Amazon SQS、RabbitMQ或Celery。我在这里的建议是，利用需要你较少操作的服务，在这种情况下，就是Amazon SQS。有多种情况下，你需要异步通信。从延迟或调度任务，到提高关键网络事务的可靠性和持久性，解耦你的单体或微服务应用程序，以及最重要的是：使用队列系统来通信事件驱动的无服务器应用程序（Amazon Lambda函数）。

缓存系统
AWS ElastiCache是一个完全可扩展、可用和可管理的缓存和数据存储系统。它的目的是提高分布式缓存数据和内存数据结构存储的应用性能。它是一个用于Memcached和Redis引擎的内存键值存储。只需点击几下，你就可以完全自我管理地运行这个AWS组件。为你的SaaS应用程序包含一个缓存系统是非常必要的。

云存储系统
亚马逊S3和亚马逊CloudFront CDN为您提供静态内容。所有的静态内容，包括图片、媒体和HTML，将被托管在Amazon S3上，这是一个具有无限存储和弹性的云系统。在Amazon S3的前面，我们将包括AWS CloudFront，整合这一对元素是至关重要的，以便缓存整个静态内容并减少带宽成本。

微服务-多租户架构

多租户架构+AWS服务+微服务+Amazon ECS（作为容器协调器）

在K8S上

无服务器架构

基础设施即代码和自动化工具
使用哪种基础设施即代码工具并不重要，它们都很有用（Terraform和CloudFormation）；它们做同样的工作，并被DevOps社区高度认可。我没有一个赢家，它们都很好。然而，如果你想知道更多关于它们各自的优缺点，我推荐这篇关于Terraform vs Amazon CloudFormation的博客。

数据架构

数据库
       固有的数据库将是PostgreSQL和Amazon RDS。然而，我强烈建议，如果你有一个资深的开发团队，并且预测你的SaaS应用程序的高流量，甚至数百个租户，你最好用MongoDB构建你的数据库。除此之外，利用下面提到的关于多租户数据库的最佳实践。在这种情况下，我会选择亚马逊RDS与PostgreSQL或DynamoDB（Mongodb）。

"如果你的SaaS应用程序预计会有很高的流量，你最好用MongoDB来构建你的数据库"

GraphQL或Amazon AppSync
GraphQL是一种查询语言，也是你的数据库服务的RESTful API的替代品。这个新的和现代的生态系统被采纳为客户和数据库服务器之间的中间人。它允许你更快地检索数据库数据，减轻数据库中的过度检索，从GraphQL模式中检索所需的准确数据，主要是通过比RESTful服务更快的迭代来提高开发速度。在多租户微服务架构中采用单体后端应用是利用GraphQL或AppSync的最佳时机。因此，在改造你的SaaS应用程序时，不要忘记包括GraphQL!

单一数据库---每个租户一张表
      每租户一个表的单一数据库指的是纯数据库的多租户和池化模型。这种数据库架构是DevOps或软件架构师的常见和默认的解决方案。当有一个小的初创公司或几十个组织时，它是非常经济的。它包括利用数据库模式中每个组织的一个表。这种架构有特定的权衡，包括牺牲数据隔离、租户之间的噪音和性能下降--这意味着一个租户可以过度使用另一个租户的计算和内存资源。最后，每个表名都有自己的租户ID，这对于设计和架构来说是非常直接的。

关于数据隔离和合规性，假设你的一个开发人员犯了一个错误，把错误的租户信息带给了你的客户。想象一下数据泄露的情况吧! - 请确保永远不要暴露超过一个租户的信息。这就是为什么合规的SaaS应用程序，这种架构模型不被推荐，然而，因为其成本效益而被广泛使用。

另一种单租户数据库架构：在单一数据库的单一模式中的共享表。非常适合DynamoDB。(我们没有涉及这种方法--仅供参考)

单一数据库---每个租户的模式
        每租户一个模式的单一数据库，也被称为桥梁模型，是一种多租户的数据库方法，它仍然非常具有成本效益，比纯租户（DB池模型）更安全，因为你是用一个单一的数据库，除了每租户的数据库模式隔离。如果你担心数据分区，这个方案比之前的方案（每个租户一张表）略好。同样，在你的应用程序代码配置中跨多个模式的管理也很简单。

需要注意的一个重要区别是，在一个数据库内有超过100个模式或租户，会引起你的数据库性能的滞后。因此，建议将数据库一分为二（将第二个数据库作为一个副本添加）。然而，这种方法最好的数据库工具是PostgreSQL，它支持多个模式，没有太多的复杂性。最后，这种 "每个租户一个模式 "的策略在其所有租户之间共享资源、计算和存储。因此，它引起了嘈杂的租户，利用了比预期更多的资源。

每个租户的数据库服务器
       也叫孤岛模式，即每个客户需要一个数据库实例。昂贵，但对隔离和安全法规来说是最好的。这种技术比其他多租户数据库架构的成本要高得多，但它符合安全法规；在性能、可扩展性和数据隔离方面是最好的。这种模式为每个租户使用一个数据库服务器，这意味着如果SaaS应用程序有100个租户，因此将有100个数据库服务器，成本极其高昂。

当需要PCI、HIPAA或SOC2时，利用数据库孤岛模式是至关重要的，或者至少找到一种变通方法，使用正确的IAM角色和最好的容器编排--无论是Kubernetes还是Amazon ECS命名空间--每个租户一个VPC和到处加密。

AWS多租户数据库

亚马逊RDS与PostgreSQL（最佳选择）。
DynamoDB（对于具有单一共享表的单租户数据库来说是个不错的选择）
带有Mysql的亚马逊RDS
GraphQL如前所述，在这些数据库前面使用它，可以提高数据检索的速度、开发的速度和RESTful API的替代方案，这有助于减轻从被支持的服务器到客户端的请求。

应用程序代码的改变
      一旦你在每一层都选择了你的多租户策略，让我们开始考虑在代码层面需要改变什么，就代码变化而言。如果你已经决定采用Django（来自Python）作为你的SaaS应用程序。那么你需要做一些调整变化，以便从数据库和应用层使你目前的应用与你的多租户架构保持一致。幸运的是，网络应用语言和框架能够捕获来自请求的URL或子域。在运行时获取这些信息（子域）的能力对于处理多租户架构的动态子域至关重要。

通配符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 OR app.saas.com A（别名）balancer.us-east-1.elb.amazonaws.co

注意：（A）别名记录是当你利用AWS的ALB/ELB（负载平衡器）。

网络服务器设置与NGINX配置
       让我们转到网络服务器，特别是Nginx。在这个阶段，你将需要配置Nginx.conf和服务器块（虚拟主机）。为你的Nginx网站服务器设置一个通配符vhost。确保它是一个别名（ServerAlias）和一个全能的通配符网站。你不必在Nginx中为每个租户创建一个子域VirtualHost；相反，你需要为所有租户设置一个通配符VirtualHost。当然，通配符模式将匹配你的子域，并相应地路由到你的SaaS应用文档根的正确和独特的补丁。

关于进一步的信息，我强烈推荐这篇博客，它讲述了企业如何使用Apache多租户和Nginx多租户来支持SaaS应用。你会发现关于Nginx多租户和Apache多租户如何实现的宝贵信息，以及它们各自的DNS通配符记录。

遵循12要素方法论框架，否则就死路一条!
     遵循12要素方法论代表了纯粹的DevOps和云原生原则，包括不可变的基础设施、与Docker相同的开发/测试和prod、CI/CD原则、无状态SaaS应用等等。

多租户SaaS架构最佳实践
     SaaS平台将如何扩展？考虑遵循一个关于如何扩展你的SaaS应用的策略，这里有一个好的策略：

亚马逊自动扩展，可以使用ec2实例或微服务。
用亚马逊RDS、亚马逊Aurora或DynamoDB进行数据库复制。
应用负载平衡器。
包括一个CloudFront CDN用于你的静态内容。
亚马逊S3用于所有的静态/媒体内容。
缓存系统，包括Redis/Memcached或其在AWS云中的等同物 - Amazon ElastiCache。
为冗余和可用性而设置的多可用性区域。

使用CI/CD的代码部署
       另一个需要考虑的关键方面是如何在租户和多个环境（开发、测试和prod）中部署你的代码发布。你将需要一个持续集成和持续交付（CI/CD）流程来简化你在所有环境和租户之间的代码发布。如果你跟进我之前的最佳实践，这并不困难。CI/CD实践是你的DevOps团队需要熟悉的另一个世界，但与ClickIT这样的团队合作。CI/CD只是DevOps实践的五个原则之一，对我们来说，将其采用到你的SaaS应用中是相当精简的。

DevOps自动化--自动化你的新租户创建过程
     如何在每个订阅中创建新租户的？确定在你的SaaS环境中启动新租户的过程。你需要触发一个脚本来启动或附加新的多租户环境到你现有的多租户架构上，也就是说，要自动设置新的租户。考虑到这可能是在你的客户在你的入职页面上注册之后，或者你需要手动触发脚本。

自动化工具：
Terraform (推荐)
亚马逊CloudFormation（相信AWS CloudFormation认证团队） Ansible

注意：确保你在这方面利用基础设施即代码的原则。

租户计算能力
        你是否考虑过每个环境可以支持多少个SaaS租户？试想一下，你有99个租户，计算/数据库负载几乎到了极限，你是否有一个准备好的环境来支持新的租户？那数据库呢？你有一个特殊的客户，希望为其SaaS应用提供一个隔离的租户环境。你将如何支持一个与多租户架构的其他部分分离的额外租户环境？你会这样做吗？会有什么影响？只需考虑这方面的一个场景。

租户清理
       你如何处理那些闲置的或不再使用的租户？也许对任何长期不活动的租户进行清理，或者手工删除未使用的资源和租户......但你需要一个流程或自动化脚本。

最后

       AWS下的多租户架构和SaaS应用......现在可以了解到整个多租户SaaS架构周期从头到尾的情况，包括服务器配置、代码以及每个IT层所追求的架构。整个多租户SaaS架构的周期，从头到尾，包括服务器配置，代码，以及每一个IT层所追求的架构。正如你所注意到的，这个生态系统没有全球性的解决方案。每一个IT层都有多种变体，要么是完全多租户，要么是部分租户，要么只是筒仓租户。这主要取决于你的需求、预算、复杂性和你的DevOps团队的专业知识。强烈建议采用微服务（ECS/EKS），在应用和数据库层部分采用多租户SaaS。还有，包括云原生原则，最后，采用本文所述的多租户架构最佳实践和考虑。也就是说，通过思考如何获得敏捷性、成本效率、IT劳动力成本，首先对你的AWS SaaS架构进行头脑风暴。

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