1.1  SAAS概述

1.1.1   软件发展的4个阶段

• 1 项目式软件开发阶段——做项目

–  依客户需求定制开发

–  存在重复开发，开发成本过高的问题

•  2 套装式软件开发阶段——做产品

–  将软件作为产品开发，满足相似需求的用户

–  不可能通过产品满足所有用户的需求

•  3 平台化软件开发阶段——做平台

–  业务驱动的基于基础平台的软件开发

–  软件的升级和运营维护成本越来越高

•  4 社会化软件大开发阶段——做服务

–  以服务为导向的软件开发运营模式

–  SaaS模式应运而生

1.1.2   SaaS(Software as a Service软件即服务)

•      SaaS是一种软件交付模式，将软件以服务的形式交付给用户，用户不再购买软件，而是租用基于Web的软件，

并按照对软件的使用情况来付费

•  SaaS由应用服务提供（Application Service Provider,ASP）模式发展而来

–  SaaS与ASP的相同点

•  通过互联网提供，运营商负责软件的管理和维护

–  SaaS与ASP的不同点

•  ASP仅对用户提供定制化的，一对一的服务方式

•  SaaS一般以一对多的方式提供服务

•  SaaS支持可配置性和可伸缩性

1.1.3   SaaS 与云计算

1.1.4   SaaS的特性

•      互联网特性

–  SaaS应用一般通过互联网交付，用户仅需要浏览器或联网终端设备就可以访问应用

•  多租户特性

–  通过多租户模式实现多种使用方式，以满足不同用户的个性化需求

•  按需服务特性

–  支持可配置性和按使用付费，按用户需求提供服务

•  规模效应特性

–  一般面向大量用户提供服务，以取得规模效应和效益

1.2  SAAS成熟度模型

1.2.1   四级成熟度模型

1.2.2   四级成熟度模型解析

①      Level1定制开发

•      为租户单独定制开发应用。

•      与传统软件相比，主要体现在软件租用付费商业模式和托管运行运营模式的区别。

•      一般不涉及大的技术架构变化。

•      为提高应用运行效率，需要更有效地整合硬件资源。

②      Level2 可配置的多租户SaaS应用

•      采用统一开发的模式，所有租户使用相同的程序代码，但各租户分别部署程序实例。

•      与第1级模型相比，降低了定制开发的软件研发成本。

•      关键在于通过元数据实现应用的可配置性。

–元数据：用于描述数据的数据，用于描述租户的个性化需求。

③      Level3 单程序实例支持多租户的SaaS应用架构

•      全部租户运行部署在单一程序实例上的同一套程序代码。

•      最大限度的提高了系统资源利用效率，同时降低程序代码升级维护的工作成本。

•      同时应注意，单实例架构为应用开发带来了更大的复杂度，需要更多的初期投入。

④      Level4 可伸缩的多租户SaaS 应用架构

•      租户通过负载均衡层访问以镜像方式部署在集群上的同一套程序代码实例上。

•      通过负载均衡方法为应用提供可伸缩性，使应用在大量用户访问下保持可接受的应用可用性和性能。

•      关键在于实现应用的可伸缩性，主要涉及负载均衡、资源管理等技术。

1.2.3   四级成熟度模型对比

1.3  SAAS的关键技术

1.3.1   多租户技术

多租户是SaaS模式下特有的核心概念之一，租户是指在线使用SaaS服务的企业、机构或个人，由于他们并不是真正的购买SaaS服务，因此没有SaaS服务的版权，只是租赁使用SaaS服务的功能，并按租赁的时间长短和功能多少支付费用，所以将他们称之为租户。而多租户实质上是为了实现SaaS服务的多用户性。达到服务共享使用规模效应，实现用户间最大程度的资源共享，真正达到资源共享的目的。

1.3.2   数据库设计技术

方案一、独立数据库(完全独立)

这是第一种方案，即一个租户一个数据库(Database)，这种方案的用户数据隔离级别最高，安全性最好，但成本也高。

优点：

为不同的租户提供独立的数据库，有助于简化数据模型的扩展设计，满足不同租户的独特需求；

如果出现故障，恢复数据比较简单。

缺点：

增大了数据库的安装数量，随之带来维护成本和购置成本的增加。

这种方案与传统的一个客户、一套数据、一套部署类似，差别只在于软件统一部署在运营商那里。如果面对的是银行、医院等需要非常高数据隔离级别的租户，可以选择这种模式，提高租用的定价。如果定价较低，产品走低价路线，这种方案一般对运营商来说是无法承受的。

方案二、共享数据库，隔离数据架构(部分独立)

这是第二种方案，即多个或所有租户共享Database，但一个Tenant一个Schema。

优点：

为安全性要求较高的租户提供了一定程度的逻辑数据隔离，并不是完全隔离；

每个数据库可以支持更多的租户数量。

缺点：

如果出现故障，数据恢复比较困难，因为恢复数据库将牵扯到其他租户的数据；

如果需要跨租户统计数据，存在一定困难。

 

方案三、共享数据库，共享数据架构(完全共享)

这是第三种方案，即租户共享同一个Database、同一个Schema，但在表中通过TenantID区分租户的数据。这是共享程度最高、隔离级别最低的模式。

优点：

三种方案比较，第三种方案的维护和购置成本最低，允许每个数据库支持的租户数量最多。

缺点：

隔离级别最低，安全性最低，需要在设计开发时加大对安全的开发量；

数据备份和恢复最困难，需要逐表逐条备份和还原。

如果希望以最少的服务器为最多的租户提供服务，并且租户接受以牺牲隔离级别换取降低成本，这种方案最适合。

 

按数据独立性、隔离性和安全性排序

– 完全独立 > 部分独立 > 完全共享

按硬件共享程度、方案性价比排序

-完全共享 > 部分独立 > 完全独立