什么是saas系统saas的概念源于云计算领域，其本质是软件即服务。 理解这个概念需要从历史开始。 在早期软件业，一般来说，a公司需要销售系统，软件公司根据a的需要开发销售系统，b公司也需要该软件公司，根据b公司的需要为b开发系统。 这样，所有公司都需要销售系统，就需要软件公司为此开发、私有化并部署到自己公司。
随着云计算时代的到来，云平台的概念逐渐渗透。 是否可以将各种软件移动到云，即是否可以构建软件公司集中维护的系统。 其他公司需要使用系统，只需注册该系统即可。 此时的这个系统就是我们所说的saas系统。
这是一个互联网平台，由开发公司自行维护，帮助客户以较低的成本快速访问。
saas系统的优缺点优势：
1 .客户可以低成本快速访问
不需要像以前那样为每个客户独立开发，平台位于互联网上，客户只需要注册一个帐户。
2 .客户不需要在意系统的运输
系统由软件公司维护，客户无需it人员也可以照常使用系统。 传统的私有化部署项目要求客户具备负责日常运输的it人员
3 .主动权掌握在软件公司手中
随着saas产品的普及，以前纯亿公司的软件公司提高了地位。 由于企业的数据和系统在软件公司手中，协商时软件公司有更多的芯片。
劣势：
1 .不能灵活定制需求
与传统方式相比，saas系统是共享系统，因此对外只能提供一种能力。 如果有定制需求，则无法满足，因为不是所有客户都需要一个客户的需求。 但是，对于toB的软件来说，个性化的需求是家常便饭，所以saas系统设计的一大难点是公共性和个性化的取舍。 定制过程中不能影响其他系统。 (在saas系统中，公共代码经常因一个用户的定制需要而更改，从而满足定制要求，但公共代码中出现错误。)。
2 .信息安全问题
因为每个客户的数据都存储在云中，所以客户有理由质疑日常数据的安全性。 这也是许多客户(特别是大中型客户)不愿意将自己的业务放在saas系统上的原因。 本质上，云数据是否会泄露给社会是一个很大的担忧因素。 另外，如果公司的经营出现不合时宜的问题(贪污、虚假结算等)，这在公司经营时是不可避免的。 特别是创业公司的情况下)，问题的事态会升级。 因为云平台给我记录了问题，很可能事情的主动权不在他们的公司内部。
3 .市场规模较大，但成熟案例不足
虽然saas有千亿市场，但Tob SAAS尚未成熟，虽然有很多独角兽，但仍在探索中。
saas系统需要解决的问题1 .共性和特性问题
对于saas系统来说，每个企业的定制需求一般而合理，但如何低成本且灵活地集成到saas系统中是一个难题，要求saas系统具有相对较高的灵活性和可扩展性。 在系统体系结构设计中，要实现可配置、可扩展，设计人员需要优先考虑的问题是如何快速响应定制需求，不影响其他功能
2 .数据安全
如何让访问saas系统的客户相信saas系统是可靠的系统是一个重要议题。 这个问题需要从商业、技术、公司背景多方面解决。 技术上可以使用数据隔离、安全网关等技术来提高数据的安全性。
3 .多租户
saas系统的入住客户是多样化的，像传统项目crm系统这样的用户可能只是企业内部的人。 在saas中，一般把企业称为租户。 租户和租户之间互不影响，a客户的问题不影响b客户。
针对这种问题，系统架构的模块化、隔离化非常重要。 模块化细分功能，各模块只做特定的事情。 如果模块划分合理，则使系统具有共性，能够快速应对个性。 即将隔离和隔离多租户的数据、服务、前端及访问域名。 数据、服务虽然用户看不见，但会做。 前端及接入域名的隔离用户可以可靠地发现。 不同的租户使用不同的域名进入saas系统，看到不同的前端是用户心理上的一大安慰，他们可以体会到自己与其他租户“隔离”。
SAS系统体系结构
从左往右说吧
终端层目前，saas产品一般在pc端，少量的app端，对于终端层，我们的用户都属于一个个租户。 (租户类似于企业概念)用户登录后，会在请求的header中携带租户id，并在每次请求时携带租户id，首先进入路由层。
路由层根据header的租户id分发请求，不同的租户访问不同的服务。
在这里，为每个租户分配不同的三级域名已经很成熟了。 这样，在每个租户看来，所有人都将访问自己的网站，而不是访问同一网站。 对不懂技术的客户来说，这是非常令人安慰的。 他们认为这个系统是自己的，和引入公司内部系统一样。
*一般来说，每个公司都有一级域名。 公司将此一级域名下的二级域名分配给不同的事业部或部门。 二级域名下的三级域名可以由部门自行分配。 所以这里说可以为saas产品的每个租户分配三级域名。 实际情况可以根据情况自己决定，分别
租户的域名不同即可。 展示层这里是我们的前端项目层，我们会为不同的租户建立不同的前端代码仓库，并依托docker和b8s快速部署，每新增一个租户我们都会为其建立一套代码仓库并部署到线上。每个租户的用户可以通过路由层精准访问到为其搭建的前端项目中。这样做的目的也是为了对租户实现物理隔离，如果一个租户有个性化的需求，我们修改的仅仅是这个租户对应的代码，而不会触及其他租户。
服务层对于服务层的项目为了保证系统的灵活性，我们将公共的服务拆分出来形成能力中台，而针对于不同的租户我们会对每一个租户有一个业务前台，数据存储统一称之为后台。
统一api网关
每个租户的前端项目在访问后台时，都会在其请求的header中携带租户标识，统一api网关会根据不同的租户标识将数据传递到对应的中后台服务。并且在转发的过程中做鉴权，拦截，熔断，降级等安全保障。
中台
中台的能力与业务无关，仅仅是对外提供标准接口。比如我们的saas服务中有很多功能用到了支付接口，需求对外付款，那我们需要将对接第三方支付的能力统一形成一个结算中台。其只提供支付接口，打通各个支付渠道，而不需要关心支付订单是三步生成还是两步生成，生成订单的步骤可能每个租户会不一致，所以这个交给前台去做。
前台
前台是中台能力的组装者，每个租户都会有一个与其对应的前台，针对不同的租户，个性化组装中台能力。每个前台的代码也是物理隔离的，每新增一个租户都会新增一套前台代码，这样可以保证每个租户的个性化需求互不冲突。
后台
后台是数据存储，数据存储要根据数据的性质进行隔离。
拿我们常用的mysql数据库来说（其他的redis，mongo，es等也类似），目前的做法是：
1.每个租户创建一个数据库，用来存储小前台产生的数据
2.大中台所产生的数据集中存储
这样对于数据管理和数据恢复来说都是比较合理的，实际运维中我们发现，如果不同租户的数据集中存储（靠一个字段区分不同租户的数据），这样对于数据恢复的压力非常大，因为实际运维时都是按照租户运维的，如果想恢复某个租户的数据我们不得不将所有的租户数据恢复，又或者从大量的数据中提取当前租户数据。如果每个租户的数据库是物理隔离的，我们只需要恢复当前租户对应的数据库即可。
一些心得
有很多人会觉得，这个设计方案太复杂，每次新增租户时都要各种复制代码，部署项目，各种路由修改，每个租户部署一套资源太过浪费。这个确实是的，为了保证系统的扩展性和灵活性我们对模块的拆分比较细致，但是这个问题在云时代会得到非常好的解决，这也就是为什么云计算时代才出现saas系统。
传统方式来说，每新增一个租户我们都需要申请服务器，部署项目，复制代码。但是在云计算时代我们依托容器化，cicd，devops，等技术可以实现快速部署，弹性伸缩。这也就解决了传统方式在技术方面的瓶颈。
举个例子，每当一个租户新增时我们要做的有：
1.复制代码
借助于各种代码托管平台我们可以快速复制代码仓库
2.数据库复制
借助于各种数据库工具以及自动化脚本，我们可以快速复制出来一个数据库
3.每个租户的系统独立部署
借助于基础镜像，我们可以一键部署出一整套服务，并且因为docker的特性，我们可以为这一整套服务灵活分配cpu和内存
4.路由切换
借助于配置中心（nacos等）我们可以随时动态修改网关的路由
以上四点每一步都有相应的技术可以解决，公司内部也可以基于以上四步创建一个自动化流程，一键创建租户，这套自动化流程也不是很复杂。