千万级常规saas系统架构精讲（干货）

什么是saas系统

saas这个概念来源于云计算领域，其本质是软件即服务。要理解这个概念需要从历史说起，对于早期的软件行业，一般是A公司需要一套进销存系统则软件公司就会针对A的需求开发一套进销存系统，B公司也需要一套那软件公司就会针对B公司的需求再为B开发一套系统，以此类推每个公司需要进销存系统都需要软件公司为其开发一套并私有化部署到其公司。

随着云计算时代的到来，云平台的概念逐渐深入人心，那是否可以将各种软件搬到云上，也就是建立一个集中式的由软件公司来维护的系统，其他公司需要使用系统，只需要到该系统注册即可。此时的这个系统就是我们说的saas系统。

它是一个互联网平台，由所开发公司自行维护，可以让客户低成本快速接入。

saas系统的优缺点

优势：

1.客户可以低成本快速接入

不需要像之前一样为各个客户独立开发，平台就在互联网上，客户想使用只需要注册一个账号。

2.客户不需要关心系统的运维

系统由软件公司维护，客户方即使没有it人员也可以照常使用系统。传统私有化部署的项目必须要求客户有自己的it人员去负责日常的运维

3.主动权掌握在软件公司手里

随着saas产品的盛行，之前纯亿方的软件公司在地位上有所提升。由于企业的数据和系统都在软件公司手里，所以在谈判时软件公司拥有更多的筹码。

劣势：

1.并不能灵活定制需求

与传统的方式相比，因为saas系统是一个共有系统，其对外只能提供一套能力，如果有些客户有定制化的需求则无法满足，因为单一客户的需求并不是所有客户都需要的。但是对于toB的软件来说，个性化需求又是家常便饭，所以saas系统设计的一大难点就是公共性和个性化的取舍。在个性化定制的过程中不能影响其他系统（对于saas系统来说经常因为一个用户的个性化需求而改动公共代码，导致个性化满足了，但是公共的代码出现bug）。

2.信息安全问题

由于各个客户的数据都存放在云端，客户有理由质疑其日常数据的安全性。这也是很多客户，尤其是大中型客户不愿意将自己的业务放到saas系统上的原因：本质上云端的数据是否会泄露给社会是一大担心因素；另外一旦公司经营出现不合规问题（贪污，做假账等，这个在公司经营时难免会有发生，特别是在创业公司），问题的事态会升级，因为云平台已经帮他们把问题记录了下来，事情的主动权很可能就不在他们公司内部了。

3.市场规模大，但缺少成熟案例

saas拥有着千亿的市场，但toB的saas目前还没有成熟的案例，虽然有很多独角兽，但都还在探索当中。

saas系统要解决的问题

1.共性和特性的问题

对于saas系统来说每个公司的个性化需求是常见的合理的，但如何将个性化的需求低成本，高敏捷地整合到saas系统中是一个棘手问题，这要求saas系统应该有比较强的灵活性，扩展性。在系统架构设计上要做到可配置和强扩展，针对一个个性化需求如何快速响应并且不影响其他功能是架构师需要优先考虑的问题

2.数据安全保护

如何让接入saas系统客户相信saas系统是一个可信赖的系统是一个重要的议题。这个问题需要从商务，技术，公司背景多方面去解决。技术上可以使用数据隔离，安全网关等技术加强数据的安全性。

3.多租户

saas系统中的入住客户是多样化的，不像传统项目一个crm系统的用户可能只是一个企业内部的人。在saas中我们一般将一个企业称为一个租户。租户和租户之间是互不影响的，A客户的问题不会影响B客户。

针对于如上问题，系统架构的模块化，隔离化就显得非常重要了。模块化即将功能细分，每个模块只做特定的事情，如果模块划分的比较合理，那就可以让系统保留共性，从而快速响应个性。隔离化即将多租户的数据，服务，前端以及访问域名进行隔离，数据，服务是用户看不到的但是也要做，前端以及访问域名的隔离是用户可以切实发现的，不同的租户使用不同的域名进入saas系统，看到不一样的前端，这在用户心理上是极大的安慰，他们可以真切感受到自己是和其他租户“隔离”的。

saas系统架构

我们从左往右讲

终端层

目前saas产品一般都是pc端的，少量app端，对于终端层我们的用户都是属于一个个的租户（租户类似于企业的概念）用户在登录后会在请求的header中携带租户标识，每个请求都会携带租户标识首先进入路由层

路由层

路由层根据header中的租户标识对请求进行分发，不同的租户访问不同的服务。

这里比较成熟的做法是为每一个租户分配不同的三级域名，这样在每个租户看来，他们访问的就是他们自己的网站而不是所有人访问同一个网站，对于不懂技术的客户来说这是极大的心里安慰，他们认为这个系统就是自己的，跟部署在公司内部系统一样。

*：一般每个公司会有一个一级域名，然后公司会将这个一级域名下面的二级域名分配给不同的事业部或部门，二级域名下面的三级域名就可以由部门自行分配。所以这里说可以给saas产品的每一个租户分配一个三级域名。实际情况下可以按照情况自行决定，只要每个租户的域名不同即可。

展示层

这里是我们的前端项目层，我们会为不同的租户建立不同的前端代码仓库，并依托docker和b8s快速部署，每新增一个租户我们都会为其建立一套代码仓库并部署到线上。每个租户的用户可以通过路由层精准访问到为其搭建的前端项目中。这样做的目的也是为了对租户实现物理隔离，如果一个租户有个性化的需求，我们修改的仅仅是这个租户对应的代码，而不会触及其他租户。

服务层

对于服务层的项目为了保证系统的灵活性，我们将公共的服务拆分出来形成能力中台，而针对于不同的租户我们会对每一个租户有一个业务前台，数据存储统一称之为后台。

统一api网关

每个租户的前端项目在访问后台时，都会在其请求的header中携带租户标识，统一api网关会根据不同的租户标识将数据传递到对应的中后台服务。并且在转发的过程中做鉴权，拦截，熔断，降级等安全保障。

中台

中台的能力与业务无关，仅仅是对外提供标准接口。比如我们的saas服务中有很多功能用到了支付接口，需求对外付款，那我们需要将对接第三方支付的能力统一形成一个结算中台。其只提供支付接口，打通各个支付渠道，而不需要关心支付订单是三步生成还是两步生成，生成订单的步骤可能每个租户会不一致，所以这个交给前台去做。

前台

前台是中台能力的组装者，每个租户都会有一个与其对应的前台，针对不同的租户，个性化组装中台能力。每个前台的代码也是物理隔离的，每新增一个租户都会新增一套前台代码，这样可以保证每个租户的个性化需求互不冲突。

后台

后台是数据存储，数据存储要根据数据的性质进行隔离。

拿我们常用的mysql数据库来说（其他的redis，mongo，es等也类似），目前的做法是：

1.每个租户创建一个数据库，用来存储小前台产生的数据

2.大中台所产生的数据集中存储

这样对于数据管理和数据恢复来说都是比较合理的，实际运维中我们发现，如果不同租户的数据集中存储（靠一个字段区分不同租户的数据），这样对于数据恢复的压力非常大，因为实际运维时都是按照租户运维的，如果想恢复某个租户的数据我们不得不将所有的租户数据恢复，又或者从大量的数据中提取当前租户数据。如果每个租户的数据库是物理隔离的，我们只需要恢复当前租户对应的数据库即可。

一些心得

有很多人会觉得，这个设计方案太复杂，每次新增租户时都要各种复制代码，部署项目，各种路由修改，每个租户部署一套资源太过浪费。这个确实是的，为了保证系统的扩展性和灵活性我们对模块的拆分比较细致，但是这个问题在云时代会得到非常好的解决，这也就是为什么云计算时代才出现saas系统。

传统方式来说，每新增一个租户我们都需要申请服务器，部署项目，复制代码。但是在云计算时代我们依托容器化，cicd，devops，等技术可以实现快速部署，弹性伸缩。这也就解决了传统方式在技术方面的瓶颈。

举个例子，每当一个租户新增时我们要做的有：

1.复制代码

借助于各种代码托管平台我们可以快速复制代码仓库

2.数据库复制

借助于各种数据库工具以及自动化脚本，我们可以快速复制出来一个数据库

3.每个租户的系统独立部署

借助于基础镜像，我们可以一键部署出一整套服务，并且因为docker的特性，我们可以为这一整套服务灵活分配cpu和内存

4.路由切换

借助于配置中心（nacos等）我们可以随时动态修改网关的路由

以上四点每一步都有相应的技术可以解决，公司内部也可以基于以上四步创建一个自动化流程，一键创建租户，这套自动化流程也不是很复杂。