SaaS 架构基础理论（一）

《互联网时代的软件革命 SaaS架构设计》学习笔记

1、背景

云计算提供的强大软硬件环境和基础服务，将逐渐成为支撑SaaS应用的基础设施。各个云计算平台所包含的大量具有自身特色的公共服务，将为SaaS应用的开发提供了丰富的资源。而统一整合各个云计算平台的公共服务，也成为了SaaS服务集成平台SIP的发展目标。未来的SaaS应用将架构在又SIP整合的多个云计算平台上。

2、SaaS商业模式

2.1、什么是SaaS

ASP是Application Service Provider“应用服务提供商”，这种模式将用于需要的软件统一部署在应用提供商的软硬件环境中，软件运行所需的人力、物力资源都有提供商维持，而用户只需要在自己办公室使用这些软件即可。------重点在于提供有软硬件环境这样的服务，且网络带宽和软件技术上有限制，ASP用户体验不好，用户无法接受自己软件和数据交由第三方托管。

SaaS是Software as Service“软件即服务”，用户对软件的需求实际上是对应用服务的需求，而用户使用软件实际是在消费应用服务。软件的用户是服务的需求者和消费者，而软件的提供商是服务的提供者和生产者。----对于软件来说，离开软件提供商的支持和维护，很难真正用起来。

		ASP	SaaS
不同点	看问题角度	站在软件开发商角度看问题，希望以一种新的新式向用户提供软件	站在用户角度看问题，考虑用户需要什么，搞清楚提供软件的本质是未来提供服务
不同点	关注目标	开发商只是为了解决用户硬件环境的持续维护问题，应用服务的统一托管	关注软件本身，是否能为用户提供有效的服务
相同点		SaaS和ASP之间形似而神不似

2.2、SaaS软件的优势：

2.3、SaaS劣势：

• 对互联网的依赖，已经不是问题
• 数据安全性：传统软件用户数据存放在自己的电脑商或企业自己的服务器中，用户自己维护数据的安全性；-SaaS软件的数据库一般配备有双机热备分系统，实时备份用户数据。
• 数据保密性:传统软件数据由用户自己保管；SaaS软件商自身信用建设。

3.SaaS应用架构

3.1、SaaS成熟度模型

SaaS相对传统软件，将原本由软件使用者所承担的软硬件、网络、系统维护的费用，转成支付给SaaS服务提供商的租用费用；

对SaaS服务提供商，依然需要承担相应的软硬件、网络、系统维护等费用。除了降低软件使用者的第一次一次性投入成本呢，将一次性的投入转变为时间、需求的逐步投入。

比较项	传统软件200个客户的综合成本	SaaS软件200个客户的综合成本
软件开发成本	取决与客户需求的异同，以及软件可配置性的强弱	1个软件开发成本
服务器成本	200台服务器	10台服务器
网络设备成本	200套	5-10套
IT维护人员成本	200人	2-3人

3.2、SaaS成熟模型分级

SaaS软件要降低企业综合使用成本最主要的手段是发挥SaaS的规模效应。

规模效应是商业模式和应用架构，一般采用多个租户共享一个运行实例的架构（Multi-Tenant，多租户架构），高性能，可配置，伸缩性。

	可配置	高性能	可伸缩
Level1	×	×	×
Level2	√	×	×
Level3	√	√	×
Level4	√	√	√

Level1：设备托管
Level2：设备共享、可配置化
Level3：多租户、数据隔离、高性能
Level4：多租户、可配置、可伸缩

3.2.1、Level1 定制开发

软件服务提供商为每一个客户定制一套软件，并为其部署。独立数据库实例和应用服务器实例，数据库中的数据结构和应用的代码可跟进客户需求做定制化修改。

3.2.2、Level2 可配置

开发通用型产品，为满足不同客户的不同需求，通用性产品具有配置性，客户通过简单的配置满足自己的个性化需求。为每个客户独立部署一个运行实例，每个运行实例运行同一份代码，通过配置的不同需求满足客户的个性化需求。

3.2.3、Level3 高性能的多租户架构

多租户实例的应用架构可以有效降低SaaS应用的硬件即运行维护成本，最大化的发挥SaaS规模效应。

实现Multi-Tenant架构的关键是通过一定的策略保证不同租户间的数据隔离，确保不同租户既能共享一个应用的运行实例，又能为用户提供独立的应用体验和数据空间。

独立数据库、共享数据库独立数据结构、共享数据结构。

实现方式：

• 在传统企业应用的数据模型基础商，增加一个Tenant表，用于描述租户信息。
• 在大部分与租户有关的业务数据表中添加TENANT_ID 字段。
• 数据模型改造完成后，还需要改造登录逻辑，在会话记录用户属性的TENANT_ID。
• 在业务数据查询过滤时，都加上TENANT_ID =?过滤条件。

3.2.4、Level4 可伸缩的多租户架构

随着租户数量的逐渐增加，集中式的数据库性能就将成为整个SaaS应用的性能瓶颈，如果不进一步考虑数据库的分区设计，就只能依赖更强大的硬件设备来向上扩展。单一设备极限，导致SaaS架构无法满足低成本运营需求。
水平扩展在用户数大量增加的情况下，无需修改应用架构，仅简单增加硬件设备的数量，就可以支撑应用规模增长。

从Multi-Tenant SingleInstance系统扩展为Multi-Tenant MultiInstance。用户首先通过接入Tenant Load Balance层，再被分配到不同的Instance上，通过多个Instance来分担用户访问，实现水平扩展。

数据库实现方式：
Tenant Load Balance层会存放用户、租户、对应的Instance的映射关系，用户登录后即可通过映射关系，将用户重定向到相应的Instance。

3.3、如何选择合适的SaaS架构

考虑因素包括：

• 你的产品所面向的客户群的特征与需求；
  客户是否原因接受共享应用的模型、个性化需求是否强烈
• 你的产品的租户数量级别；
  成熟度高的SaaS产品开发成本（开发维护成本）更高，租户数量决定选择的成熟程度。
  租户小于10个，多租户架构带来的收益并不大；大于50之后，多租户架构是SaaS的必然选择。
  租户数量在10000以下时，可伸缩性无需考虑；租户在50000~100000甚至更高时需要重点考虑伸缩性
• 你的团队的开发能力与你们愿意付出的开发/改造成本

下一篇就多租户-高性能多租户-可配置多租户-可伸缩多租户具体实现解释

侵权请联系删除