对SAAS浅谈

怼烎@ 2022-08-29 09:48 195阅读 0赞

## 一、什么是Saas？ ##

从字面中理解SaaS的全称是Software as a service, 即软件即服务，即由传统的开发卖软件升级到开发软件卖服务。百度百科对SAAS的定义是：SAAS平台是运营saas软件的平台,SaaS提供商为企业搭建信息化所需要的所有网络基础设施及软件、硬件运作平台，并负责所有前期的实施、后期的维护等一系列服务，企业无需购买软硬件、建设机房等，租户开箱即用。SaaS 是一种软件布局模型，其应用专为交付而设计，便于用户通过互联网托管、部署及接入。  
  ToB Saas系统最近几年都很火,很多创业公司都在尝试创建企业级别的应用 CRM, HR,销售, 很多Saas创业公司也拿了大额风投，也有不少上市公司，比如有赞、微盟等。那么SAAS软件的优缺点如下:

*  #### 优点 ####

1、用户角度：开箱即用 、无需维护、按需使用、随处可用、使用成本降低；  
2、ASP提供商：节省销售成本、节省软件维护成本；

*  #### 缺点 ####

1、高度依赖网络、数据安全性和保密性要求高；  
2、定制化服务开发部署周期长；

## 二、saas演进过程 ##

SaaS成熟度模型根据是否具有可配置性、高性能、可伸缩可将SaaS成熟度分为四级，每一级都比前一级增加三种特性中的一种，分别是定制开发、可配置(代替定制) 、高性能的多租户架构以及可伸缩性多租户架构。

#### 2.1 定制化开发 ####

为用户提供专用的数据库实例及应用服务器实例，依据用户实际需求进行定制化开发，其实最初的SaaS应用成熟度模型，在技术架构上和传统项目型软件开发或软件外包没什么区别。有一个客户项目，就按照客户的需求来定制一个版本，每个客户都有一份独立的代码，各版本间可通用的只有少量可重用软件，库及开发人员经验。虽然最初级的SaaS模型，在应用架构上和传统软件模式并没有什么区别，但在商业模式上，最初级的SaaS模型和传统软件模式，还是存在本质上的区别——即软硬件及相应的维护职责都由SaaS服务商提供，用户按需缴纳费用即可使用。

#### 2.2 可配置化 ####

为用户部署单独的运行实例，但有效的减低了第二次开发的成本，通过可配置的形式，满足用户的基本需求。  
  最初级的成熟度模型，显然并不是良好的SaaS成熟度模型，每次新增用户都需要进行定制化的开发，单独部署。这种模式势必会导致随着客户数的增加，需要投入的定制化开发成本，软硬件已经运营成本，都将随着客户的增加而按照比较增加。但这种模式达到一定规模后，想要进一步扩大规模，基本上就只能依赖于人肉战术了。  
  所以，首先需要解决的问题就是降低定制化开发成本。SaaS第二级依赖的解决方案，就是通过可配置化实现有效降低开发，进而达到缩减成本的目的。希望通过可配置化来满足不同客户的需求，而不需要为客户进行特定的开发。但是，其实通过描述可发现，在第二级模型中，软件的部署架构并没有发生多大的变化，依旧是为每个客户部署一个运行实例，只是每个运行实例都是运行着同一份代码，通过配置的不同来满足不同客户的需求。

#### 2.3 高性能的多租户架构 ####

从应用架构的角度而言，第一级和第二级成熟度模型和传统软件并没有太大的区别，只是在商业模式上比较符合SaaS的定义。由于其应用架构的设计是为每一个新的租户都单独部署一份软件实例，在一对一的架构，势必会导致需要维护软硬件成本，随着新租户的增加而直线上升，无法有效的发挥SaaS模式的规模效应。所以，多租户单实例的SaaS架构才是通常上真正意义的SaaS模式，多个租户对应一个软件实例可有效的降低软硬件成本，充分发挥SaaS模式的规模效应。  
  实现多租户模型的关键是通一定的策略来确保用户数据的独立性，用户共享统一的应用实例，势必会对数据独立性提出一定的要求，在用户需求差别不大，客户数量不多时，讲一个第一级/第二级成熟度模型改造成多租户并不会太复杂，通常可以通过独立数据库，共享数据库独立数据结构，共享数据结果实现。

#### 2.4 可伸缩性多租户架构 ####

该级别的初始目的为了实现在用户数大量增加的情况下，无须更改应用架构，只需要简答的增加硬件部署的数量，就可支撑应用规模的增长。在架构设计中的Tenant Load Balaner层将会保存用户，租户与对应软件实例的映射，用户登录后，即刻映射到对应的软件实例。

## 三、SAAS架构常用方案 ##

SaaS成熟度模型分级不同，系统架构设计也不尽相同，下面简单说一下系统架构在不同分级模型下设计：

### 3.1 独立服务和数据库 ###

![image.png][]

*  ##### 优点： #####

为不同的租户提供独立的应用实例和数据库，有助于简化数据模型和业务模型的扩展设计，满足不同租户的独特需求；如果出现故障，恢复系统或数据均比较简单，系统间也不会相互影响。

*  ##### 缺点： #####

1、数据库层面：每个租户数据库都作为独立数据库进行部署，该模型提供了最大的数据库隔离。但隔离需要为每个数据库分配足够的资源来处理其高峰负载。这里重要的是， 弹性池不能用于部署在不同资源组或不同订阅中的数据库。这种限制使得这种独立的单租户应用程序模型成为从整体数据库成本角度来看最昂贵的解决方案；  
2、应用层面：每个租户若存在个性化定制，则需要对项目进行横向扩展，扩展时务必需要保证与主干版本的兼容性问题。  
3、运维层面：应用和数据库的安装数量会随租户的数量线性递增，随之带来维护成本和购置成本的增加。

### 3.2 共享服务独立数据库 ###

![image.png][image.png 1]

*  ##### 优点： #####

为不同的租户提供独立数据库，有助于简化数据模型扩展设计，满足不同租户的独特需求；如果出现故障，数据恢复均比较简单，也可以自动将单个租户恢复到较早的时间点。因为恢复只需要恢复存储租户的一个单租户数据库。这种恢复对其他租户没有影响，这证实了管理运营处于每个租户的细粒度级别。应用层面的维护成本和购置成本有所减少。

*  ##### 缺点： #####

1、数据库层面，数据模型统一  
2、应用层面，每个租户若存在个性化定制，则需要对项目进行横向扩展，扩展时务必需要保证与主干版本的兼容性问题  
3、运维层面，数据库的运维问题同模式一，应用层面的运维在版本控制的问题上难度有所增加

### 3.3 共享应用及数据库 ###

![image.png][image.png 2]

*  ##### 优点： #####

为安全性要求较高的租户提供了一定程度的逻辑数据隔离，并不是完全隔离；每个数据库可支持更多的租户数量。

*  ##### 缺点： #####

1、数据库层面，如果出现故障，数据恢复比较困难，因为恢复数据库将牵涉到其他租户的数据；  
2、应用层面，配置中心需要对租户信息进行完整且合理的分配和维护。

### 3.4 网关+前台+中台模式 ###

![image.png][image.png 3]

*  优点：
    
     *  有利于定制不同租户的个性化需求。例如：交互界面不同、工作流不同等等。
     *  服务只需要根据用户需求在前台做相应的横向扩展即可；
     *  不同租户间服务相互独立，互不影响。
 *  缺点：
    
     *  模块划分需要做好划分，重点注重业务之间的低耦合；
     *  调用链路变长，需要做一定的优化处理；
     *  模块纵向拆分后，后期研发和运维难度均会有所增加；  
        原文链接：https://blog.csdn.net/haponchang/article/details/104246317

### 3.5 通用saas逻辑图 ###

![image.png][image.png 4]

*  优点：
    
     *  服务只需要根据用户需求在前台做相应的横向扩展即可；
     *  不同租户间共享服务。
 *  缺点：
    
     *  模块划分需要做好划分，重点注重业务之间的低耦合；
     *  调用链路变长，需要做一定的优化处理；
     *  模块纵向拆分后，后期研发和运维难度均会有所增加；

## 四、技术选型 ##

多租户模式下，软件的架构需要考虑可扩展性（Scalability）、数据隔离、性能、数据库成本、性能监控等多指标。

*  ##### 4.1 数据库层： #####
 *  ##### 4.1.1 数据库的垂直切 #####

1）. 纵向分库就是根据业务耦合性，将关联度低的不同表存储在不同的数据库，做法与大系统拆分为多个小系统类似，按业务分类进行独立划分。与“微服务治理”的做法相似，每个微服务使用单独的一个数据库。  
2）. 垂直分表是基于数据库中的列进行，某个表字段较多，可以新建一张扩展表，将不经常用或者字段长度较大的字段拆出到扩展表中。在字段很多的情况下，通过大表拆小表，更便于开发与维护，也能避免跨页问题，MYSQL底层是通过数据页存储的，一条记录占用空间过大会导致跨页，造成额外的开销。另外，数据库以行为单位将数据加载到内存中，这样表中字段长度越短且访问频次较高，内存能加载更多的数据，命中率更高，减少磁盘IO，从而提升数据库的性能。

*  垂直切分的优点：
    
     *  解决业务系统层面的耦合，业务清晰
     *  与微服务的治理类似，也能对不同业务的数据进行分级管理，维护，监控，扩展等。
     *  高并发场景下，垂直切分一定程度的提升IO，数据库连接数，单机硬件资源的瓶颈。
 *  垂直切分的缺点
    
     *  部分表无法join，只能通过接口聚合方式解决，提升了开发的复杂度。
     *  分布式事处理复杂
     *  依然存在单表数据量过大的问题。

*  ##### 4.1.2 数据库水平切分 #####

当一个应用难以再细粒度的垂直切分或切分后数据量行数依然巨大，存在单库读写，存储性能瓶颈，这时候需要进行水平切分。  
  水平切分为库内分表和分库分表，是根据表内数据内在的逻辑关系，将同一个表按不同的条件分散到多个数据库或多表中，每个表中只包含一部分数据，从而使得单个表的数据量变小，达到分布式的效果。  
  库内分表只解决单一表数据量过大的问题，但没有将表分布到不同机器的库上，因些对于减轻mysql的压力来说帮助不是很大，大家还是竞争同一个物理机的CPU、内存、网络IO，最好通过分库分表来解决。

*  水平切分优点
    
     *  不存在单库数据量过大、高并发的性能瓶颈，提升系统稳定性和负载能力。
     *  应用端改造较小，不需要拆分业务模块。
 *  水平切分缺点
    
     *  跨分片的事务一致性难以保证
     *  跨库的join关联查询性能较差
     *  数据多次扩展维度和维护量极大。
 *  ##### 4.1.3读写分离 #####

为了确保数据库产品的稳定性，很多数据库拥有双机热备功能，也就是主从，主服务主要负责写，从服务器提供读功能，在查询压力较大的情况，读写分离是较好的方案。

*  ##### 4.1.4 分库分表中间件 #####

目前对于分库分表中间件，开源组件越来越多，常用的分库分表中间件具体如下：

*  ###### 简单易用的组件： ######
    
     *  Asgard（唯品会）
     *  DAYU （唯品会）
     *  ShardSphere(当当)
     *  TSharding（蘑菇街）
 *  ###### 强悍重量级的中间件： ######
    
     *  sharding
     *  TDDL Smart Client的方式（淘宝）
     *  Atlas(Qihoo 360)
     *  alibaba.cobar(是阿里巴巴（B2B）部门开发)
     *  MyCAT（基于阿里开源的Cobar产品而研发）
     *  Oceanus(58同城数据库中间件)
 *  #### 4.2 应用层优化： ####
    
     *  分布式：Dubbo（阿里）、OSP（唯品会）、Motan（微博）、Tars（腾讯），spring cloud
     *  cache: redis\\mc
     *  定时任务统计：elastic-job\\XXL-JOB\\SATURN(唯品会),具体介绍：https://www.jianshu.com/p/ab438d944669
     *  搜索引擎:技术组件ES
     *  异步化：ROCKET、KAFKA、RabbitMQ、plusar
 *  #### 4.3 运维与监控 ####
    
     *  日志分析系统：elk  
        ELK Stack 是Elasticsearch、Logstash、Kiban三个开源软件的组合。在实时数据检索和分析场合，三者通常是配合共用，而且又都先后归于 Elastic.co 公司名下，故有此简称，参考文档如下：  
        官网地址:https://www.elastic.co/cn/  
        官网权威指南:  
        https://www.elastic.co/guide/cn/elasticsearch/guide/current/index.html  
        安装指南：  
        https://www.elastic.co/guide/en/elasticsearch/reference/6.x/rpm.html

资料整理人：VICK

[image.png]: /images/20220829/386e2197a4744ebd9f4cf763a387bb17.png
[image.png 1]: /images/20220829/4bf61b08f5ae4f34b4b9b2656712786a.png
[image.png 2]: /images/20220829/0357fbb4aa794bdeb669ece7d0dc81e2.png
[image.png 3]: /images/20220829/d282c37771974555945ec9c7263a6911.png
[image.png 4]: /images/20220829/b3350afd3cce41cdae2789a4fe1f386f.png