SaaS系列介绍之六: SaaS模式分析(上)

1 引言

　　如果我们想要更多的玫瑰花，就必须种植更多的玫瑰树。

　　                           ________姚群《成功激励格言精选》

　　SaaS模式是个新兴的话题，有许多慨念还定义不清楚，其研究的内容又很复杂。我们从SaaS模式的软件平台成熟度上入手，分析SaaS模式中有代表并关键的模式。重点放在质量管理上。从质量管理上分析如何提高SaaS应用的质量。

　　2 SaaS模式研究的主要内容

　　SaaS模式所要研究与实现的内容非常多，我们分情况分重点可归纳如下：

　　l SaaS的运营模式

　　分析SaaS服务的营销方式、服务成本及收费手段、SaaS模式的人群关系。

　　研究实施SaaS服务的过程管理，结合软件工程原理、ISO2000规范、CMMI规范、IPD(集成产品开发)以及IT企业项目实施的经验，形成一整套满足SaaS模式的实施过程管理规范。做到咨询规范化、培训标准化、控制科学化、使用制度化。

　　结合我国中小企业，特别是个人消费者对SaaS平台与软件的典型应用中的集成需求，对网络化制造与SaaS的服务功能、服务标准和规范技术进行研究，设计与编制中小企业网络化制造系统与SaaS服务的标准化体系结构、集成接口方案和相关规范。开发标准化集成接口软件工具。

　　l SaaS的商业模式

　　企业门户的诞生、搜索引擎的崛起、SOA的热门、Web2.0的浪潮……这一路互联网走得跌跌撞撞却赚得盆满钵溢。而在软件行业，互联网化和服务化已是大势所趋。

　　面对已在美国形成风暴的在线服务，2008年被定位为中国的SaaS年。我们在这一历史时机决战的大战役中是观望不前，还是积极投入?

　　SaaS的商业模式主要分析SaaS在管理软件应用的切入点、目标客户群、盈利模式、市场容量、发展周期、收费模式、周期每阶段预期收入、竞争环境。

　　l SaaS的开发模式

　　SaaS的开发需要打造一个开发链。我们需要有一个统一的SaaS平台，有自定义工作流、自定义表单、自定义数据模型、自定义界面、自定义报表、统一组织机构及权限控制。还需要有依赖平台的如CRM类的业务系统。这些软件首先要考虑到如何架构、如何设计、如何开发、如何测试、如何部署、如何版本控制、如何培训教育、如何支持服务大家，这些方面都必须规范统一。

　　团队配合方面，需要有group、wiki、blog、mail、IM、office online来协作，并且必要的时候还需要配合代码搜索。这也就是为什么google大力发展Gmail、Gtalk、Project Hosting、code search、office online、blog、group forum、SVN。其实Google要搭建的就是SaaS平台和SaaS生态链。您看Google不仅给我们提供了分布式全球存储基础设施(商业称“云存储、云计算”)、各种应用，而且提供了应用API，而且最近还提供了App Engine，而且还提供了代码社区。

　　l SaaS平台实现模式、应用模式和商务模式的研究与实现

　　通过深入分析我国中小企业特别是园区企业对网络化制造系统的需求，建立符合区域制造业和园区经济发展特色的、可操作的SaaS平台实现模式、应用模式和商务模式。确保SaaS服务平台商务模式的实用性和可推广性。

　　l 中小企业核心业务流程的研究与实现

　　选择工业园区、软件园区、生产力促进中心，通过多视图集成化建模，对中小企业现状从静态布局、动态运行和企业管理等三方面进行描述，分析其组织机构、岗位设置、业务流程、商业模式、信息流、知识流、资产流、总体或局部功能结构，从而形成面向特定产业的多视图的知识管理、供应链管理、项目管理和信息管理模型。

　　l 基于SaaS模式的中小企业管理软件的体系结构设计

　　研究基于国际互联网或园区网络的SaaS模式的企业管理软件的体系结构，以中小企业SaaS服务平台为重点，分析剖析SaaS平台的框架设计及业务应用软件的体系架构及相关组合关系。

　　l 基于SaaS模式的应用软件构件的配置与管理

　　运用应用服务器(Application Server)对开发的应用系统构件和构件包进行管理，方便灵活的实现系统可配置、可裁剪、可定制、可修改，保证软件系统适应不同的管理模式，支持业务流程重组和软件系统功能的配置与调整。

　　l 安全策略及加密技术的实现

　　面向中小企业管理的SaaS系统平台是用同一套平台供大量企业用户使用，除了考虑基础平台要具有可扩展性以外，还要解决应用软件系统一对多的适应性和数据访问权限的安全策略及加密技术。

　　l SaaS服务平台资源的整合

　　SaaS服务平台提供给用户的服务是多功能、全方位的。要解决资源的整合，包括多系统集成、多目标控制、多用户协同、多级权限控制技术和开发、维护、递送多个客户共享的软件服务技术，以及基于多层架构，C/S模式、B/S模式，系统集中运行、数据分开存放的软件技术。

　　l 采用软件构件化技术，开发适合我国中小企业管理模式的构件库和构架库

　　以面向对象的设计思想，组件化开发方式，利用接口技术开发如工作流引擎、自定义报表、基于标准协议的数据交换模块、动态表单、统一权限控制及认证等中间件，提供特定服务的构件库及构架库，把应用逻辑封装成套件，通过系统配置功能将构件组装成面向具体企业的服务模块，设计出高内聚低耦合的可高度复用的构件模块。建立基于J2EE、.net平台的软件构件包。

　　这种软件包应该在软件开发过程充分体现构件化的优越性并可进行软件再工程。

　　l 建立工业园区企业、科技园区企业等中小企业SaaS服务平台

　　研究与建设为工业园区企业、科技园区企业、生产力促进中心提供专业化的网络化制造服务，并包括政策与法律、软件与信息共享、培训与咨询等基础与共性的服务于中小企业的SaaS服务平台。

　　l SaaS的运行技术基础

　　SaaS仅仅只是片面理解的一套可以存储多个客户单位数据的B/S软件。如果您要应对上亿次的访问，几亿用户的并发和数据存储，您的运行基础设施一定是一个可信平台。

　　3 SaaS模式的推动力

　　研究SaaS模式是个很复杂的工程，如何推动SaaS模式，我们应该做到以下几点：

　　l 需要专门的SaaS专家

　　SaaS是一种很专业的模式，要正确实现它往往需要一个有实践经验的SaaS专家作为伙伴来给予帮助。对于任何规模的公司来说，和一名SaaS专家来贯彻始终地评估和优化业务将会有助于避免代价高昂的错误、减少未来的和现在的成本以及获得加速业务增长的回报。

　　l 财务的重新评估

　　对于软件公司来说，进入SaaS市场所面临的最大的内部挑战就是为一种完全不同的收入模式来配置人员和其他资源。在传统的、持久的许可模式下，收入以一种大型的、循环的模式来达到平衡。

　　但在SaaS模式中，客户以月为基础来为使用软件付费。刚开始的时候可能比传统许可的收入要低得多。但是，一两年或这更长的时期，SaaS的收入可能远远超出许可模式，并且它会提供更多的可预见的现金流。在一个理想的SaaS模式中，持续的投入需要软件公司对自己的预算和收益做出计划。

　　l 客户持续租用决定SaaS的成功

　　使客户持续租用至关重要，因此，软件公司需要一组新的规范，如100%的正常运行时间、高水平的安全和性能保证，面向服务的运作方法必须负责确保服务的质量、优质的发布，并且最重要的是要保证客户的满意度。这种满意度包括：产品的易用性、访问数据的快速、服务的持续和稳定、数据的安全和备份等。

　　这样的需求在SaaS基础设施上提出了新的要求，以满足必须的性能、可用性和安全需求，持续的应用监控是必需的。

　　l 持续保持新的面孔

　　当然，客户的需要和期望总是随着时间而改变的。这意味着，软件公司也必须对他们的开发过程保持一种新鲜的面孔。SaaS业务的成功很大程度上依赖于产品的制造和发布。客户总是对产品提出各种新的思想，共性被客户提出并得到厂商的回应，新鲜感让客户觉得厂商一直为客户着想和努力。

　　l 软件厂商的技术能力

　　在SaaS环境中，应用程序代码本身往往必须经过优化，以确保可靠性和高性能。另外，产品扩展和新产品开发必须要对市场动态作出响应。所有这些都需要一个针对SaaS环境调整的流水化开发过程。

　　不断优化产品，软件厂商需要快速提高他们的开发能力，不再只是简单地进入市场，而是基于预先的前端产品规划和部门管理的运作。软件厂商应该获得工具和洞察力，从而以一种更加顺利和可操控的方式带来更多备受关注和频繁的软件功能的发布，以满足日益变化的顾客需求。

　　l 销售如何推进

　　既然SaaS为终端用户消除了先期许可和基础设施成本，购买决策往往从公司层级转移到部门层级。因此，SaaS销售人员必须拜访相应的部门经理，而不是IT执行官。

　　另一个重要的考虑是市场营销。对SaaS产品有效的市场营销技术和对许可软件有效的那些市场营销技术是不同的，如何影响目标客户关注SaaS产品仍然是一个值得研究的课题。

　　1)通讯频宽的限制

　　SaaS商业模式需要有充足的带宽资源支持，目前我国的通讯基础设施有了很大的发展，但是带宽资源还没到富余的程度，因此，频宽资源可能会成为制约SaaS发展的一个重要因素。

　　2)网络安全性

　　网络的安全性包括了两层含义：一是技术上能够抵御黑客的非法侵入，另一层更重要的含义是SaaS商本身的职业操守达到一定的层次，顾客的商业秘密不会因SaaS自身的原因而泄露。

　　3)社会信用体系

　　我们看到美国的SaaS业发展迅速，应该看到他们多年积累的信用体系其实是SaaS发展的关键动力。然而，反观国内的企业，普遍缺乏信用观念，这极大地增加了SaaS用户的交易成本和投资风险。

　　4)品牌因素

　　由于SaaS这一商业模式本身需要很高的技术要求、安全要求和信用要求，SaaS商的品牌因素也特别重要。

　　虽然技术是SaaS成功的原动力之一，但是SaaS的成功关键不仅在于先进技术和人力资源的掌握，也依赖于对相关业务流程和信息管理的行业经验，因此目前的少数SaaS所提供的功能远不能满足企业用户的需要，无法达到真正的SaaS所提供的功能。

　　4 SaaS模式的软件平台成熟度

　　SaaS模式的软件平台是个很复杂的东西，如何检验平台的成熟度标准至今并没有统一的结论，我们尝试通过对国内外基于SaaS模式的软件平台设计中若干关键要素及常见架构的研究，结合目前市场趋势，对SaaS软件平台进行初步的探讨和分析。

　　4.1 SaaS软件平台的三大特点

　　从应用架构师的角度来看，设计出色的SaaS应用与设计欠佳的应用之间主要有三点不同之处。设计出色的SaaS应用具有可扩展性、多用户高效性，而且可配置。

　　l 可扩展性

　　应用的可扩展性是指能最大限度地提高并行性，以便更高效地利用应用资源，例如，我们要优化锁定时间、无态性、共享线程和网络连接等汇集资源、高速缓冲参考数据以及对大型数据库进行分区等。

　　l 多用户高效性

　　对习惯于设计独立的单用户应用的架构师而言，多用户性要求他们进行重要的思维转型。例如，一家公司的用户使用CRM应用服务存取客户信息时，该用户连接的应用实例同时可能还会为其他几十家，甚或是数百家公司的用户提供服务，各用户之间彼此互不知情。这就要求应用架构能够最大化不同用户间的资源共享，不过仍要区分属于不同客户的数据。

　　l 可配置性

　　当然，如果我们必须用一台服务器上的单个应用实例满足多家不同公司的需求，那么我们就难以针对某个最终用户的使用体验编写定制代码，因为只要针对某个客户进行了应用定制，就会改变其他用户的使用。因此，我们不是在传统的意义上进行应用定制，而是让每个客户用元数据配置应用的外观和行为。

　　SaaS架构师面临的挑战在于，如何确保客户应用配置的简易性，同时还不必为每项配置支付额外的开发或运营成本。

　　4.2 SaaS软件平台的四级模型

　　一般来说按照目前业界通行标准，基于SaaS模式的系统可以按照其设计成熟度分成以下四种程度，其中每一级与前一级的区别则在于是否引入了前述三大要素中的部分或全部。

　　从广义上说，我们可采用四级模型来说明SaaS应用的成熟度，每一级都比前一级增加了上述三种成熟特性中的一种。

　　

　　图1 SaaS软件四级成熟度模型

　　1. 第一级 定制

　　第一级成熟度类似于上世纪90年代初的ASP(Application Service Provider)所采用的软件交付模式。这种模式下，软件服务提供商为每个客户定制一套应用软件，并为其部署。每个客户使用一个独立的数据库实例和应用服务器实例。数据库的数据结构和应用代码可能都根据客户需求做过定制化修改。这种模式相对传统软件，差别仅仅在于商业模式，在应用架构上没有任何差别。

　　符合这一级成熟度的系统，每个客户拥有一个为其定制的应用实例，这一单独的实例运行在SaaS服务提供商的硬件之上。从系统架构而言，这一级别的SaaS系统和传统的本地安装软件非常相似，同一客户的不同终端用户使用客户端软件连接同一个应用实例，但这一客户实例和服务提供商同时运行的其它客户的应用实例相比是完全独立的。

　　因此，传统的服务器-客户端的应用可以在花费少量开发资源和无需重新设计整个架构的前提被改造成符合这一级别的SaaS模式的系统。虽然相比起其它更为成熟的SaaS模式的系统，这一类型的系统所能给SaaS服务提供商带来的收益有限，但它确实可以让SaaS服务提供商通过整合服务器硬件和管理来降低成本，因此目前有不少国内的软件厂商就尝试应用这种手段将其已有的传统系统改造为相应的SaaS系统。

　　实际上传统的C/S、B/S软件在商业模式上做出相应的改变，就符合该模型。这种模式下，对于每个客户需要为其定制发、单独部署等等，因此很难达到规模效应。

　　2. 第二级 可配置

　　第二级成熟度模型是在第一级的基础上的改进，也就是针对每个客户的定制化可以通过配置的方式实现，而不需要通过定制代码、数据库结构来实现。这种模式要求软件开发商在设计应用的时候已经考虑了扩展性，所以针对不同需求的客户，可以采用灵活的配置来响应。这种模式下每个客户依然有独立数据库实例和应用服务器实例，但是每个客户的实例都是相同的版本，通过不同的配置来满足客户不同的需求。符合第二级成熟度的系统，每个客户各自拥有一个单独的应用实例，但不同之处在于第一级中的用户实例是根据每个客户的需求单独定制的，而在这里，每个客户使用相同的代码。SaaS服务提供商通过详细的具体配置选项来允许客户改变自身应用的外观和系统行为。尽管如此，不同的应用实例之间还是保持完全独立运行。

　　将所有客户的应用实例集中于同一代码库之下极大的减少了对于SaaS服务提供商的服务需求，因为此时对系统代码任何微小的改变都会立刻影响所有的当前客户，这下也就可以节省为每个客户的应用实例单独升级或修改的成本。但是相比起第一级的成熟度模型，如果试图将一个传统的服务器-客户端的应用改造成符合第二级成熟度的SaaS系统，将需要花费更多的重新架构和开发的成本。

　　最后，同第一级模型有一处类似的是，符合第二级成熟度模型的系统一样需要SaaS服务提供商准备足够的硬件和存储空间来支持潜在的大量的同时运行的应用实例。

　　这种模式相对第一级成熟度模型可以降低定制开发的成本，但是由于其部署、维护还都是独立的，还是很难达成规模效应。

　　3. 第三级 可配置，高效的多用户支持

　　第三级的成熟度模型就是符合multi-tenancy架构的，multi-tenancy完整的名称应该是Single Instance Multi Tenancy，也是单实例多租户。这级模型下软件提供商部署一个应用的实例即可满足多个客户的要求。

　　在第三级的成熟度模型中，服务提供商通过运行一个应用实例来为所有的客户服务，同时通过可配置的元数据来给每一个客户提供不同的用户体验和功能。可配置的权限控制和安全策略则确保了每一个客户的数据被单独存放且与其它客户的数据相隔离。因此，从最终用户的角度出发，他们将感受不到所使用的应用实例也在同一时间为其他客户所共享。

　　这种方式解决了这样一个问题，那就是随着SaaS服务供应商业务的发展和客户的增多，只能通过提供更多的服务器资源来运行更多应用实例，现在SaaS服务供应商可以用同样数量的服务器资源为更多的客户服务，从而比起前两级成熟度模型的系统，更有效的利用了硬件资源，降低了运营成本。

　　但这一架构的不利之处在于无法灵活的提升系统性能，除非使用数据分区技术来提高数据库的性能，一般来说SaaS服务供应商将只能通过把系统转移到更为强大的服务器上来提升性能。

　　在客户的需求差别不大，客户数量不是特别大的情况下，将第一级/第二级熟度模型的应用改造成符合multi-tenancy架构的应用并不会太复杂，最常见的改造方案有：

　　1) 增加一个Tenant表(或者类似作用的表，例如企业表、个人表)。

　　2) 在大部分的业务数据表中都要增加TenantID字段，来唯一标识多租户。

　　3) 改造登录界面，在登录界面增加一个企业号输入框，并修改其逻辑代码，在会话中记录登录用户所属的TenantID，如图2：

　　

　　图2 SaaS模式登录界面

　　4) 在业务数据查询过滤时，都增加上TenantID=?过滤条件。例如初始数据模型如下：

　　

　　图3 传统软件数据模型

　　改造后的数据模型如图4：

　　

　　图4 SaaS软件数据模式

　　经过以上简单的改造，系统基本上就可以实现multi-tenancy架构。但是要真正较好的达成第三级成熟度模型，显然没有这么简单，这样简单的改造将面临可配置性和性能的双重挑战。

　　在multi-tenancy架构下，要实现可配置性，相对第二级成熟度模型下实现可配置性，会面临更大的挑战，尤其是数据模型的扩展。在单租户的模型下，一般我们都会通过直接扩展表、扩展字段来实现数据模型的扩展，而在多租户的模型下，不同租户可能有不同的数据模型的扩展需求，采用直接扩展表、扩展字段的方法变得不太可行。因此在多租户模型下，更多地通过预留字段和name-value对的模式实现数据模型的扩展。

　　l 可延伸性模式

　　根据设计，应用自然会包括标准的数据库设置，带有与您解决方案属性相对应的默认表、字段、查询以及关系等。但是，不同的企业会有着各自独特的需求，而僵化的、没有延伸性的默认数据模型是无法解决这些具体问题的。举例来说，SaaS职位跟踪系统(SaaSjob-tracking system)的一个客户可能需要配合每个记录存储外部生成的分类代码串，以将系统与其他进程全面集成。另一位客户可能不需要分类字符串字段，但却要求支持跟踪整数类型的ID号。因此，在许多情况下，您所开发和实施的方法都应使客户能延伸默认的数据模型以满足需要，同时又不会影响其他客户对数据模型的使用。

　　l 预分配字段

　　实现数据模型可延伸性的方法很简单，即在希望实现用户可延伸性的每个表格中创建一定预设数量的定制字段。

　　表4-1.带有一组定制字段、标记为C1～C3的表格。

　　表4-1 定制字段

　　

　　在上表中，同一表格中混有不同客户的记录;用户ID字段将每个记录与相应的用户

　　相关联。除了标准的一组字段外，我们还提供一系列定制字段，每个客户可决定如何使用这些定制字段，以及如何针对这些定制字段收集数据。

　　数据类型的问题怎么解决呢?这也很简单，您只需为所创建的每个定制字段选择一般的数据类型即可，不过客户可能会觉得这种方法限制性过强。有的客户可能需要三个额外的字符串字段，而我们可能只提供了一个字符串字段、一个整数字段以及一个布尔字段(boolean field)。那怎么才能实现灵活性呢?

　　一种方法是针对每个定制字段采用字符串数据类型，并使用元数据来跟踪用户希望使用的“真实”数据类型。图5.Web页面上的定制字段由元数据表中的项目定义。

　　

　　图5 Web页面上的定制字段与元数据表的关系

　　在上例中，用户使用了应用的可延伸特性向数据输入屏幕添加了称为“寄件人邮政编码”的文本框，并将该文本框映射至称为C1的定制字段。创建文本框时，用户使用了确认逻辑(此处未显示)以要求文本框包含的是整数。实施后，这一定制字段由元数据表中的一条记录来定义，该表包括了用户唯一的ID号(1017)、用户为该字段所选的标记(“寄件人邮政编码”)，以及用户希望该字段使用的数据类型(“整数”)。

　　您可在统一的元数据表中跟踪所有应用的定制字段的字段定义，或为每个定制字段使用不同的表格;例如，“C1”表会定义每个使用C1定制字段的用户，“C2”表执行的操作与此相同，如此类推。

　　表4-2 执行关系表

　　

　　表4-3 定义定制字段表

　　

　　表4-4 执行操作表

　　

　　表4-2在统一的元数据表格中存储字段定义与在独立表格中存储不同的定制字段。

　　采用独立表格的主要优势在于，每个特定字段表格仅包含使用该字段的用户的行，这节约了数据库的空间。(如果采用统一表格方案，那么每个至少采用一个定制字段的用户都会在统一表中获得行，尽管用户实际并未使用空字段，但其却会表现为可用的定制字段。)采用单独表格的方法也有其弱点，因为它会增加定制字段操作的复杂性，要求必须采用SQL的JOIN语句来调查单个用户的所有定制字段定义。

　　当最终用户在字段中输入数量并保存记录时，应用在数据库中创建或更新记录前，会将寄件人邮政编码的值转换为字符串。只要应用检索记录，就会检查元数据表中要使用的数据类型，并将定制字段中的值转换回原类型。

　　l 名称值对

　　前面部分介绍的预分配字段模式是用户扩展并定制应用数据模型的一种简单方式。不过，这种方案存在一定的局限性。在给定表格中决定提供多少定制字段需要进行综合权衡。如果定制字段太少，用户就会感到应用有局限性;如果太多，数据库又会变得太大，造成浪费，并且很多字段都得不到利用。在这极端情况下，两种情况都会发生，有的用户定制字段过多，有的用户则不够用。

　　避免发生上述局限性的一种方法是使客户自己能够对数据模型进行延伸，在独立的表格中存储定制数据，并使用元数据来定义每个用户定制字段的标记和数据类型。

　　

　　图 4-6. 表格延伸的定制字段。

　　这时，元数据表格存储关于每个用户定义的各个定制字段的重要信息，其中包括字段名称(标记)和数据类型。当最终用户采用定制字段保存记录时，会发生两件事。第一，记录本身在主要数据表中被创建或更新;保存所有预定义字段的相关值，但不会保存定制字段。这时，应用为记录创建唯一的标识符，在记录ID字段中保存它。第二，在延伸表中创建一个包含下列信息的新的行：

　　•主要数据表格中与记录关联的ID;

　　•与正确定制字段定义关联的延伸ID;

　　•将正在被保存记录中定制字段的值转换成字符串。

　　上述方案使每个用户都能根据需要创建尽可能多的定制字段，以满足业务需求。当应用检索客户记录时，会在延伸表中进行查找，选择与记录ID相对应的所有行，并为所用的每个定制字段返回一个值。

　　为了将这些值与正确的定制字段相关联并将其转换为正确的数据类型，应用会使用延伸表中与每个值关联的延伸ID在元数据中查找定制字段信息。

　　上述方案使用户能自行决定数据模型的可延伸性，并同时保持了采用共享数据库的成本优势。这种方案的主要弱点在于，其会增加诸如索引、查询以及更新记录等数据库功能的复杂程度。如果您希望使用共享数据库，同时估计客户在延伸默认的数据模型时要求相当大的灵活性，那么这种方法通常是最可取的。

　　l 定制列

　　可延伸数据模型的最简单类型是直接向用户的表格中添加列的情况。

　　

　　图7. 专用表格添加定制行。

　　这种模式适合独立数据库或独立架构应用，因为每个用户都拥有可独立修改、不影响其他客户端的表集。从数据模型的角度看，这是三种可延伸模式中最简单的一种，因为这不需要您分别跟踪数据延伸。

　　不过，从应用的体系结构角度看，这种方法可能更难实施，因为其会允许用户更改表格中列的数量。即便您能使用定制列模式，您也应当考虑能不能采取预分配字段或名称值对等其他模式，以减小开发难度，从而使您编写的应用代码能够假定每个表格中的已知字段数量且固定不变。

　　在multi-tenancy架构下有许多最实践：

　　l 数据库很容易成为multi-tenancy架构应用的性能瓶颈，因此可能导致较大数据库压力的行为应该尽量避免;如大数据量表关联，复杂SQL语句，实时的数据统计，Like、or等可能导致数据库索引不能有效利用的SQL。

　　l 为了保证应用服务器层能水平扩展，一般要求应用服务器层做到无状态(不要使用Session等)，以便有效利用Load Balance设备进行负载均衡。

　　l 对于频繁读取读取的内容，采用合适的Cache策略提升其性能。

　　l 采用合适的数据库垂直拆分，以分担数据库服务器的压力。

　　l 采用搜索引擎来满足一些大数据量的模糊查询的需求

　　l 采用定时统计+增量数据的方式，来满足一些数据统计的需求。

　　第三级成熟度模型具备一定的可伸缩性(应用服务器只要实现无状态，一般可水平扩展，数据库服务器通过数据表的一定程度的垂直拆分也能实现一定程度上的扩展)，但是由于其中只有Sing Instance，在用户数量达到一定规模之后(例如百万级甚至千万级)，其集中式的数据库服务器、存储等很容易成为系统性能的瓶颈，这时候依赖于单纯的向上扩展(服务器硬件配置的升级)系统性能提升有限，而且成本很高，这就是第四级成熟度模型产生的背景。

　　4. 第四级 可配置，高效的多用户支持可扩展

　　第四级成熟度模型相续第三级成熟度模型，系统扩展为multi-tenancy multi- instance，最终用户首先通过接入Tenant Load Balance层被分配到不同的Instance上，通过多个Instance我们可以实现应用的近似无限水平扩展。要实现第四级成熟度模型，最复杂的就是针对原有单个Instance的数据库服务器，实现其数据的水平拆分。对于multi-tenancy应用而言，最适合的数据水平拆分方案即按照Tenant进行拆分，实现按照Tenant进行数据水平拆分的方案大致如下：

　　l Tenant独立放到一个集中式的DB中。

　　l Tenant表增加字段Data_DB(或者类似名称)，表明该Tenant的业务数据位于哪个业务数据库中(Instance中)。

　　用户登录时，根据其Tenant将其定位到相应的业务数据库，后续其业务操作和数据查询都针对其对应的业务数据库。

　　在这一级也就是最后一级的成熟度模型中，SaaS服务供应商将通过运行一个负载均衡的具备权限验证功能的平台来为众多的客户同时服务，每个客户的业务数据将被单独存放，同时提供使用可配置的元数据来为每一个客户提供其自身需要的独一无二的用户体验。符合这样一个成熟度的SaaS系统将可以轻易支持一个相当大的客户数目，这是因为在其后台运行的服务和业务实例可以在不修改系统架构的基础上随着需求动态的增加和减少，任何的系统变动和修复可以轻而易举的同时作用于数以千计的客户环境中，就如同只为单一客户服务时同样简便。

　　应该说将符合第三级成熟度模型的软件切换成符合第四级成熟度模型，架构复杂度并不会太大，不过要应用直接去做这件事情，还是有很大的开发工作量。另一方面，也要有开发人员从一开始就得面对这种数据的水平拆分，增加了系统的复杂度。另一种更合适的方式，是将这种数据的水平拆分方案作为一个横切面剥离出来，在系统部署的时候在通过配置的方式横切入系统，这样就可保证数据水平拆分方案对于应用的开发人员完全透明。对于第三级成熟度模型的SaaS软件，可以很容易地通过这样一个框架实现其向第四级成熟度模型的转变。

　　4.3选择适合的成熟度等级

　　综上所述，符合最高的第四级的成熟度模型的SaaS系统似乎永远是SaaS系统设计的终极目标，但实践证明这并非永远正确。一般来说，将SaaS系统的成熟度看成一个两头具同等重要性的杠杆也许更为恰当，杠杆的一头是独立(Isolated)的数据和代码，而另一头则是共享(Shared)的数据和代码。

　　

　　图8 数据分离与隔离的杠杆模型

　　选择何种程度的成熟度模型取决于SaaS服务供应商所支持的商业模式、系统模型和运营需求，以及其它基于客户业务需求的一些考虑，而且以上各种因素之间往往还会有微妙的联系：

　　1. 商业模式

　　独立的数据模式是否符合财务考量。为了获得经济和管理上的好处而采取数据共享往往意味着SaaS服务供应商可以因此节约相当一部分的管理成本。但在有些情况下，客户可能会对此有不同的需求，比如说，尽管SaaS服务供应商可以保证客户的机密数据即使与其它客户的数据存放在一个数据库内但绝对不会外泄，客户仍然可能受强有力的法律或文化上的限制，从而抵制或干脆拒绝使用任何基于多个客户使用共享服务来访问同一个应用结构的SaaS软件服务。当然从商业模式的角度来看更重要的是，一旦计划运营基于这一商业模式的SaaS系统，SaaS服务供应商必须证明该应用如何能在当前采用的成熟度模型基础上保证业务顺利发展且实现盈利。

　　2. 系统模型

　　应用是否能在单一逻辑实例下运行，是否能将以前基于桌面或传统的服务器-客户端的应用改造成为基于互联网的SaaS系统，这些需求往往从根本上就与要求单一实例和元数据为主的SaaS模式开发不相适应。因此基于财务考量，投入相当的人力物力来将当前系统转换到一个完全符合SaaS成熟度模型的系统往往是一个得不偿失的选择。而当您选择一切重新开始，设计和建造一个基于网络的SaaS应用时，往往会感到拥有更多的自由的开发空间。

　　3. 运营模式

　　SaaS服务提供商如何保证客户服务条款(SLA：Service Level Agreement)得到执行，如何慎重的评估包含在已经与客户签署的SLA中的诸如系统当机时间、服务选项以及灾难恢复等条款，以及如何在当前这样一个多个独立客户共享访问单一实例的SaaS架构下实现这些服务条款永远SaaS系统运营维护中的一大挑战。

　　5 小结

　　SaaS模式是个全面与复杂的课题，本章主要从SaaS模式研究的主要内容入手，重点介绍了SaaS模式的软件平台成熟度及其质量管理。

　　通过SaaS模式的软件平台成熟度的研究让大家了解到如何评估SaaS模式下的软件的质量标准，如何选择适合的成熟度等级;通过SaaS模式的质量管理的分析，把我们的质量管理浸透到开发与服务的每个环节，让质量管理无所不在，只有这样才能开发出客户最大满意度的产品，企业才能真正获取最大的利益。