SaaS的成功，不仅源于其对商业模式的变革，还有赖技术架构上的创新。前者简言之，是软件从“产品”到“服务”的思维转变；后者简言之，便是伴随“软硬件、网络、系统维护”等重任转嫁“软件开发者”所带来的规模效应的发挥。
SaaS成熟度模型分级，正是衡量规模效应的重要指标。
分级依据
是否具有可配置性、高性能、可伸缩等特性。
四个分级
一级成熟度模型：不可配置、无高性能、不可伸缩；
二级成熟度模型：可配置、无高性能、不可伸缩；
三级成熟度模型：可配置、高性能、不可伸缩；
四级成熟度模型：可配置、高性能、可伸缩；
一级成熟度模型：定制开发
初级成熟度模型，被定义为 Ad Hoc/Custom（特定的/定制的），即软件服务提供商为每个客户定制一套专属软件，不同软件版本有分属的独立代码，并被分别部署在不同的数据库实例和应用服务器实例上。这种模型下，数据库中的数据结构和应用代码，均可根据用户需求做定制化修改；而不同软件之间，只有少量的可重用组件、库、开发经验可共享和重用。
初级成熟度模型，较之传统的项目型软件开发或软件外包，仅在商业模式上有所差别，即软硬件和维护职责由SaaS服务提供商承担；而在技术架构上没有明显差异：传统的“项目型软件开发”即符合这一特性；传统的C/S、B/S软件，经商业模式改造（由软件商部署软件，用户按需付费，应用架构上不做调整），也可转变为SaaS初级成熟度模型。
二级成熟度模型：可配置
由于初级成熟度模型，需按客户需求做独立代码定制开发，不同客户的代码亦需独立部署。因此，随着客户数量增多，客户所对应的定制开发成本、软硬件以及运行维护成本必然成比例增长，系统的规模集成优势难以发挥。 这种情况下，有实力的软件公司，便从项目软件定制开发，转攻可配置的通用型软件，这就是SaaS二级成熟度的雏形。
二级成熟度模型，跟一级成熟度模型一样，在应用架构上与传统软件相比没有多大差别，依然为每个客户独立部署一个运行实例。只是，与一级成熟度模型中“每个实例专属一份代码”相比，二级成熟度模型中，每个实例共享同一份代码，而客户的个性化需求，仅通过不同的配置来实现。
满足二级成熟度模型的软件，比如B2C网上商城系统、论坛系统等，软件的硬件部署、网络环境和运行维护等工作，由软件提供商承担，客户的个性化需求通过不同配置来实现，而客户仅需支付年服务费即可。
可配置性，作为“二级成熟度模型区分于一级成熟度模型”的重要特性，承担着替代定制开发和降低开发成本的重任。然而，可配置性常通过MetaData(元数据)来实现，这便为非基于元数据而设计的传统应用架构，带来了从底层开始的大量的系统改造问题。
三级成熟度模型：高性能的多租户架构
三级成熟度模型，一改一、二级成熟度模型“多租户多实例”的架构，用“多租户单实例”的Multi-Tenant架构取而代之，从而极大地发挥了SaaS应用的规模效应（有效降低了硬件和运行维护成本）。目前用户量较大的互联网应用，其应用架构基本上都采用了三级成熟度模型。
“隔离不同租户数据，确保不同租户共享同一个运行实例的基础上，为每个租户提供独立的应用体验和数据空间”，是目前实现Multi-Tenant架构的关键。客户需求差别不大且客户数量也不很大的情况下，通过独立数据库、共享数据库、独立数据结构、共享数据结构等方案，将一、二级成熟度模型，改造成Multi-Tenant架构的工作不会太复杂。但基于Multi-Tenant架构的互联网特性（高数据量、高并发量） ，要想将单实例的传统架构改造成 Multi-Tenant架构，就不是那么容易了。另外，Multi-Tenant架构 在实现可配置性方面，相对传统软件也有较大差别（如数据模型的扩展方案等）。
四级成熟度模型：可伸缩性的多租户架构
四级SaaS成熟度模型，通过将三级成熟度模型Multi-Tenant SingleInstance系统，扩展为Multi-Tenant MultiInstance，以及增加Tenant Load Balance层，将已接入用户数据分配到不同Instance以分担用户访问的方式，解决多租户单实例应用架构下，集中式数据库随租户数量增多而性能受限的问题。这是一种高效的水平扩展策略，在租户数量大增时，无需更改应用架构，而仅需简单增加硬件设备数量 ，就可实现“支撑应用规模增长，方便实施应用修改”的效果。
四级成熟度模型，其实现难点在于“针对原有单个Instance的数据库服务器，实现其数据的水平拆分”，而拆分结果是多实例的数据水平拆分框架。 架构中，Tenant Load Balance 层会存放用户、租户与对应的Instance对应关系，并将登陆的用户定向到相应的Instance。随着用户数量增多，适当增加Instance数量便可满足更多租户的使用问题。
网友评论