售前工程师——Saas系统
目录
什么是Saas系统？
Saas系统的优缺点？
优势：
1：客户可以低成本快速接入
2：客户不需要关系系统的运维
3：主动权再软件公司手里
劣势：
1：并不能灵活的定制需求
2：信息安全问题
3：市场规模大，但缺少成熟案例
Saas系统要解决的问题
1：共性和特性的问题
2：数据安全保护
3：多租户
Saas系统的架构
终端层
路由层
展示层
服务层
统一的api网关
中台
前台
后台
一些心得
什么是Saas系统？
saas这个概念来源于云计算领域，其本质是软件即服务。要理解这个概念需要从历史说起，对应早期的软件行业，一般是A公司需要一套进销存系统，软件公司就会针对A公司的需求开发一套进销存系统，B公司也需要一套进销存系统，软件公司就会针对B的需求开发一套进销存系统，以此类推每当公司需要进销存系统的时候都需要软件公司为其开发一套并私有化部署到其他公司。
随着云计算的到来，云平台的概念逐渐深得人心，那是否可以将各种软件搬到云上，也就是建立一个集中式的由软件公司来维护的系统，其他公司需要使用系统，只需要该系统注册即可。此时的系统就是我们说的Saas系统。
Saas系统的优缺点？
优势：
1：客户可以低成本快速接入
不需要像以前一样为各个客户独立开发，只需要注册一个账号就可以使用。
2：客户不需要关系系统的运维
系统由软件公司维护，客户方既没有IT人员也可以照常使用系统。传统私有部署的项目必须要求客户子的IT人员去负责日常的运维。
3：主动权再软件公司手里
随着Saas产品盛行，之前纯乙方的地位有所改变。由于企业的数据和系统都在软件公司手里，所以再谈判的时候软件公司又更多的主动权。
劣势：
1：并不能灵活的定制需求
与传统的方式相比，因为Saas系统是一个共有系统，其对外只能提供一套能力。如果有些客户有定制化的需求则无法满足，因为单一客户的需求并不是所有客户都需要的。但是对于ToB来说，个性化需求是家常便饭一样，所有Saas系统设计的一大难点就是公共性和个性化的取舍。
2：信息安全问题
由于各个客户的数据都存在云端，客户有质疑其日常数据的安全性。这也是很多客户，尤其是大中型客户不愿将自己的业务放到Saas上的原因之一：一旦公司出现经营不合规问题（贪污，做假账等，这个再公司经营时有发生，特别是再创业公司），问题是事态会升级，因为云平台已经帮着他们把问题记录下来了，事情的主动权很可能就不在他们公司了。
3：市场规模大，但缺少成熟案例
Saas系统拥有着千亿市场，但ToB的Saas目前还没有成熟的案例，虽然有很多独角兽，但还在摸索当中。
Saas系统要解决的问题
1：共性和特性的问题
对于Saas系统来说每一个公司的个性化需求是常规合理的，但如果将个性化的需求成功降低，高敏捷的整合到Saas系统中是一个棘手的问题，这要求Saas系统应该有比较强的灵活性，扩展性。在系统架构设计上要做到可配置和强扩展，针对一个个性化需求如何快速响应并且不影响其他功能是架构设需要优先考虑的问题。
2：数据安全保护
如何让客户接入Saas系统的时候想想Saas系统是一个值得信赖的系统，这个问题需要从商务，技术，公司背景多方面去解决。技术上可以使用数据隔离，安全网关等技术加强数据的安全性。
3：多租户
Saas系统中的入住客户是多样化的，不像传统项目一个Crm系统的用户可能只是一个企业内部的人。在Saas中我们一般将一个企业称为一个租户。租户和租户之间是相互不影响的，A客户的问题不会影响到B客户。
Saas系统的架构
终端层
目前Saas产品一般都是PC端的，少量APP端，对于终端层我们的用户都是属于一个个的租户（租户类似于企业的概念）用户在登录后会在请求的Header中携带租户标识每个请求都会携带租户标识首先进入路由层。
路由层
路由层根据Header中的租户标书对请求进行分发，不同的租户访问不同的服务，这里比较成熟的做法是为每一个租户分配不同的三级域名，这样在每个租户看来，他们访问的就是他们自己的网站而不是所有人访问同一个网站，对于不懂技术的客户来说是极大的心理安慰，他们认为这个系统就是自己的，跟部署在公司内部系统一样。
展示层
这是是我们的前端项目层，我们会为不同的租户建立不同的前端代码仓库，并依托docker和B8s快速部署，每新增一个租户我们都会为其建立一套代码仓库并部署到线上。每个租户的用户可以通过李宇春精准访问到为其搭建的前端项目中。这样做的目的也是为了对租户实现物理隔离，如果一个租户有个性化需求，我们修改的仅仅是这个租户对应的代码，而不会触及其他租户服务层。
服务层
对于服务层的项目为了保证系统的灵活性，我们将公告的服务拆分出来形成能力中台，而针对不同的租户标识将数据传递到相应的中后台服务。并且在转发的过程中做鉴权，拦截，熔断，降级等安全保障。
统一的api网关
每个租户的前端项目在访问后台时，都会在其请求的header中携带租户标识，统一api网关会根据不同的租户标识将数据传递到对应的中后台服务并且在转发的过程中做鉴权，拦截，熔断，降级等安全保障。
中台
中台的能力与业务无关，仅仅是对外提供接口。比如我们的Saas服务中有很多功能用到了支付接口，需求对外付款，那我们需要将对接第三方支付的能力统一形成一个结算中台。其只能提供支付接口，打通各个支付渠道，而不需要关心支付订单是第三步生成还是两步生成，生成订单的步骤可能每个租户会不一致，所以这个交给前台去做。
前台
前台是中台能力的组织者，每个租户都会有一个与其对应的前台，针对不同的租户，个性化组装中台能力。每个前台的代码也是物理隔离的，每新增一个租户都会新增一套前台代码，这样可以保证每个租户的个性化需求不冲突。
后台
后台是数据存储，数据存储要根据数据的性质进行隔离。
拿我们常用的mysql数据库来说（其他的redis，mongo，es等类似），目前的做法是：
1：每一个租户创建一个数据库，用来存储小前台产生的数据。
2：大中台所产生的数据库集中存储。
这样对应数据管理和数据恢复来说都是合理的，实际开发发现运维如果这样是不同租户的数据集中存储（靠一个字段区分不同租户的数据），这样对于数据恢复的压力非常大，因为实际运维时都是按照租户运维的，如果想恢复某个租户的数据我们不得不将所有的租户数据恢复，又或者从大量的数据中提取当前租户数据。如果每个租户的数据库是物理隔离的，我们只需要恢复当前租户的对应数据即可。
一些心得
有很多人会觉得，这个设计方案太复杂，每次新增用户都要各种复制代码部署项目，各种路由修改，每个租户部署一套资源太过浪费。这个确实是的，为了保证系统的扩展性和灵活性我们对模块的拆分比较细致，但是这个问题在云时代会得到非常好的解决，这也就是为什么云计算时代才出现Saas系统，每当一个租户新增时我们要做的有：
1：复制代码
借助于各种代码托管平台我们可以快速复制代码仓库。
2：数据库复制
借助于各种数据库工具以及自动化脚本，我们可以快速复制出来一个数据库。
3：每个租户的系统独立部署
借助于基础镜像，我们可以一键部署出一整套服务，并且因为docker的特性，我们可以为这一整套服务灵活分配cpu和内存。
4：路由切换
借助于配置中心（nacos等）我们可以随时动态修改网关的路由。
以上四点每一步都要相应的技术可以解决，公司内部也可以基于以上四步创建一个自动化流程，一键创建租户，这套自动化流程也不是很复杂。