SAAS 技术栈回顾

什么是SAAS

SAAS Software-as-a-Service的缩写名称，意思为软件即服务，即通过网络提供软件服务。
SaaS 代表软件即服务：一种软件许可模式，其中软件集中托管并通过订阅进行访问。
以上描述比较笼统模糊，用一幅图来说明。

上图第一列是传统的系统，第二列是Iaas, 第三列是Paas， 第四列就是我们说的SaaS。
关于云架构太大，本篇不做深入讨论。仅说明一点，从上图可以看出SaaS的定位，关注于应用服务和业务数据的处理。

---

技术栈

什么是技术栈

技术堆栈是用于开发 Web 或移动应用程序的编程语言、开发工具、库、框架和软件的组合。 它是开发过程的基本要素，也是创建应用程序的第一步。
技术堆栈分为两个不同的方面，即前端和后端。

为什么技术栈很重要

技术堆栈将决定应用程序的可扩展性、功能性和可行性。 因此，根据公司需求做出关于最佳技术堆栈的决策。

SaaS 技术栈选择原则

• 公司或者团队当前技术能力和熟悉的技术生态。
  - 选择的开发语言和开源社区尽量有一定规模和广泛使用程度。
  - 学习曲线要低。
  Python 比其他编程语言更容易学习，从语法简单、用途广泛、阅读 Python 代码非常直观。
  Java技术应用系统比较成熟，历史上开源社区广泛采用java。
  如果没有历史负担，个人推荐使用python。python除了学习成本低，在AI和基础研究领域被广泛采用，将来相当长的时间内会越来越重要并成为主流语言。
  - 市场上能够相对容易的找到技术栈的人才。如果选了一个小众的技术栈，无论技术多牛，但人员离职更替是必须考虑的因素，职位挂出去两个月，能找来面试的都没几个。尽量不要去选。
  - 技术栈的长期价值。要对采用技术栈的生命周期有个判断。尽量选取大厂，大基金的热度较高的，近几年开源且有一定成熟度的技术栈。避免选用过气的开源框架，无论曾经多么辉煌。
  - 此外，SaaS 技术堆栈要能够适用敏捷化、简化开发、简化维护等能够节约成本的要求。

SaaS 技术栈能力等级

定制开发 --> 可配置 --> 多租户 --> 高性能 --> 可伸缩

• LEVEL1 定制开发
  软硬件都由SAAS服务商提供，软件的使用者只需要按时间、用户数、空间等逐步支付租赁使用费用即可。
• LEVEL2 可配置
  通过不同的配置满足不同用户的需求，而不需要为每个用户进行特定定制，以降低定制开发的成本。
• LEVEL3 高性能的多租户架构
  多租户：通过一定的策略来保证不同租户间的数据隔离，确保不同租户即能共享同一个应用的运行实例，又能为用户提供独立的应用体验和数据空间。实现方案有独立数据库、共享数据库独立数据架构、共享数据库共享数据架构。
  高性能：满足多租户并发访问的性能挑战。
• LEVEL4 可伸缩性的多租户架构
  解决租户数量增加因集中式数据库带来的性能瓶颈。
  SAAS实现阶段性成熟度推进

---

SaaS多租户架构综述

如图，单租户模式和多租户模式

多租户要解决的问题

• 利用多租户架构策略降低服务器基础设施成本。
• 单一的信任来源。
• 降低开发成本和缩短产品交付时间。
  直接的说单租户是资源独享，优势是资源隔离，安全性高；
  多租户是资源共享，优势是快速交付，硬件成本低；

开发语言

前面的原则已经提到，这里不做过多的赘述。建议选择主流语言，如
python；
Java；
Node.js;
Rect;
Go;
等等

云服务商

选择一个云服务商。不做广告，不种草。
但是有一点要注意，每个云厂商都有自己的技术生态圈。除了性价比，稳定性，可用性等因素，还要考虑自己的团队或者自己的产品方向，是否和该云服务厂商的技术生态切合，也是一个重要考虑的因素。

微服务

这是一个比较大的话题，本篇不过多阐述，后面有时间会有专门的文章探讨。这里只做简单说明，后面多租户的会举例说明一下。
架构经历了从经典的分层架构，面向服务的架构，到微服务架构，无服务架构也正在来得路上。
这里推荐比较成熟的微服务架构。从理论到实践已经被证明了。

容器&编排

管理、编排和创建微服务集群环境。
没有什么纠结和犹豫的，Docker + Kubernetes 组合。如果相应的原厂商有提供产品化的替代品，建议可以考虑，一般在稳定性至少是可用性上都有提升。

Docker

Kubernetes

数据库

为了支持多租户，有开源技术栈有两个选择。
如果租户量大，流量比较高，团队技术能力足够的话，MongoDB是首选。MongoDB是一种安全可靠、可弹性伸缩的云数据库服务。

否则 Mysql + PostgreSQL 来实现多租户数据也是一个可以接受的选项。

IaC

字面意思是基础架构即代码（Infrastructure as Code），可以用代码来管理维护资源。允许保存基础设施状态，从而能够跟踪对系统（基础设施即代码）中不同组件所做的更改，并与其他人共享这些配置。
基于传统的DevOps概念，增加了自动配置化。
主要作用有两点：
自动配置开发测试环境。
自动化配置 SaaS 应用程序进行代码部署，动态触发和构建新租户。

开源工具有很多，这里主要推荐Terraform ：
安全高效地预览、配置和管理云基础架构和资源；
应用非常广泛，将基础结构部署到多个云；
自动化管理基础结构
Terraform能够创建配置文件的模板，以可重复、可预测的方式定义和预配ECS资源，减少人为因素导致的部署和管理错误。能够多次部署同一模板，创建相同的开发、测试和生产环境。

Terraform 数据流图

编译部署工具推荐git系 + jenkins。
Jenkins自动化部署可以解决集成、测试、部署等重复性的工作，工具集成的效率明显高于人工操作；并且持续集成可以更早的获取代码变更的信息。
Jenkins持续集成缩短了从开发、集成、测试、部署各个环节的时间，从而也就缩短了中间出现的等待时间；持续集成也意味着开发、集成、测试、部署得以持续。

消息队列 (MQS)

常见的 MQS 是 RabbitMQ，RocketMQ, Celery等异步通信。
从延迟或调度任务，到通过关键 Web 事务提高可靠性和持久性，解耦微服务应用程序。
这里推荐老东家的RocketMQ，支持国产的中间件产品。

历年双 11 购物狂欢节零点千万级 TPS、万亿级数据洪峰，创造了全球最大的业务消息并发以及流转纪录。

缓存

说到缓存，主要还是redis 和 memcached。redis与memcached相比，比仅支持简单的key-value数据类型，同时还提供list,set,zset,hash等数据结构的存储；redis支持数据的备份，即master-slave模式的数据备份；redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用等等，这似乎看起来redis比memcached更加牛X一些，那么事实上不一定。
需要在网络IO模型，内存管理机制，数据一致性问题，集群管理方式等多个维度进行衡量。
这里推荐redis，支持主从、集群和读写分离架构，具备低延迟、大吞吐、弹性扩缩容的特点。

云存储

选定了云厂商，都会有相应的云存储。一般都提供管理运维平台和API使用接口。如阿里oss, AWS 的 S3等等。

汇总到这里

上面主要围绕开发，部署，发布的流程用到的技术栈做了综述。
还没完，下面讲一下技术栈需要解决的重点问题。

---

多租户架构选型

多租户架构设计主要解决的问题是，可为租户提供托管服务，即软件即服务应用程序在多个客户之间共享。
多租户技术架构主要通过应用层的多租户和数据层的多租户来实现这个目标。

微服务 + 容器 + ECS

微服务已经不是陌生的架构，因为它们最大利用可用云资源、安全性和性能之间提供了平衡。
它还引入了更精细服务（微服务）的分解系统概念。鉴于篇幅不过多论述微服务优劣及过多的概念。
这里仅用一个简化的技术架构图来说明。

上面的综述章节，主要是基于微服务的架构来说明的。

Kubernetes多租户架构

Kubernetes 命名空间隔离的特性就可以实现多租户。不能不说Google的技术能力底蕴还是很强的。

无服务架构

FaaS（函数即服务，Function as a Service）：将函数代码托管给云产商，以服务形式运行，支持事件触发。代表产品有腾讯云SCF、AWS Lambda等。
BaaS（后端即服务，Backend as a Service）：指云平台提供的后端组件整合，开发者无需开发和维护后端服务，通过API/SDK的调用便可获得例如数据存储（对象存储、云数据库、云中间件等）、消息推送、账号管理、地图定位、AI、IoT等能力。

---

多租户数据库

遗憾的是以目前的数据的技术能力和设计理念，还不能完全适配多租户架构的需求。最直接粗暴的方式是数据库隔离，在安全性和性能上满足了多租户的要求。
目前广泛采用的是基于租户ID做隔离。使用这个方法的原因不是因为这种设计好，而是方法实现起来比较廉价，同时也带来了安全和资源抢占的问题。

共享表模式

所有租户共享数据库同个schema下的表数据。是使用比较普遍的的一种方式。
具体实现细节上各个公司团队不一，基本原理是根据租户ID做逻辑隔离。
这种没有安全性可言，一个bug就可以导致数据安全泄露事故。传闻，曾经发生过的某租户可以看到别的租户的数据的这种安全泄露的严重事件。资源隔离也无从谈起。当然，通过设计和权限限制可以做到一定的预防能力。
使用它的原因，主要是这种实现比较直接，尤其是对老系统的改造量不是特别大。

A schema per tenant

每个租户一个Schema，也称为bridge模型，是一种改进的多租户数据库方法，它比共享表模式更安全。
需要注意的是，如果租户数量比较庞大，这种模式会引起数据库对schema的管理复杂性。导致性能下降明显。PostgreSQL支持sckema分区的能力比较强，所以比较适合这种设计模式下使用。
但是PostgreSQL依然难以做到多租户的资源隔离。比如，一个租户高频的请求了大量数据库读写请求，会导致数据计算和存储资源的相互抢占等问题。

Database Per Tenant

有讽刺意味的是，每个租户一个独立的数据库，是目前技术上能做到最好的方案。但是，基础设施成本比较高，往往会造成数据库性能的闲置浪费。

多租户数据库技术选型

• PostgreSQL+Mysql.
• MongoDB
• GraphQL等等

---

多租户应用服务

多租户应用可以基于前面的架构选型做相应的设计和代码开发。如果是改造传统的设计架构，原则也是一样的。

Web 服务多租户

• 在web服务中设计租户空间和租户管理等。
• 为每个租户分配子域，用于识别租户或组织。
• 设计DNS/Nginx/Apache，并添加相应逻辑对租户进行映射。
• 用户角色管理。
  这里需要说明使用通配符解决DNS子域问题。
  子域过多，例如，‘org1.saas.com’、‘org2.saas.com’…等等，根据这种URL 结构，对 DNS 更改来进行每个租户的识别、身份验证和授权。
  如果子域过多，例如，‘org1.saas.com’、‘org2.saas.com’…等等无限下去，会相当难以维护。
  一种解决方法就是使用通配符记录放在DNS 管理记录中。
  通配符子域将所有路由重定向到多租户架构（到负载均衡器、应用程序服务器或集群端点）。
  CNAME ()记录指向“app.saas.com”或“saas.com/login”。 ()表示子域的通配符。
  最后，(A) 记录指向 ECS 集群、ALB 或 IP。

NGINX 多租户配置

Nginx需要配置 Nginx.conf 和服务器块（virtual hosts）。 为Nginx Web 服务器设置通配符virtual hosts。为所有租户设置一个通配符 VirtualHost。 通配符模式将匹配子域并相应地路由到SaaS 应用程序root。
为了满足数据传输的安全性要求，需要配置租户子域下的证书。 将它们添加到 CDN、负载均衡器或 Web 服务器中。并在nginx中增加相应的配置项。

---

案例

让我们来使用一张架构图来回顾和整合一下前面所讲的所有内容。

以上有些开源项目没有做介绍，比如监控，服务注册发现，搜索等等。
这些主要是根据使用场景和具体要求而定，等后面有机会再详述。

感谢耐心看完，希望能带来一些帮助。您的点赞，转发是我对我最大的鼓励：）