SaaS软件即服务模型研究

SaaS是Software-as-a-service(软件即服务)的简称，大多数的专家在软件即服务区别于传统的套装软件和简单的Web站点的一些基本特点上达成一致。也就是说，软件即服务必须有以下特点：“软件部署为托管服务，通过互联网存取”。

一、SaaS分类与发展前景

通常软件即服务分为两类： (1)面向企业的服务，向各种规模的企业和组织提供的服务。面向企业的服务通常是可定制的大型商务解决方案，旨在协助开展财务、供应链管理以及客户关系等商务工作。这种服务通常采用用户预订的销售方式。(2)面向个人消费者的服务，向公众提供的一类服务。面向个人消费者的服务有时以用户购买的方式销售，不过通常免费提供给用户，从广告中赚取收入。

软件服务化虽然在中国还是个刚刚兴起的新生事物，但是由于国内具有非常良好的生长土壤，目前备受业界的关注。据统计我国约有1200万家中小企业，这是一个数量非常庞大的软件服务化消费群体。而另一方面，中小企业灵活多变、发展迅速等特点，又急需专业的IT系统和服务来帮助其提高工作效率、提升管理质量、降低运营成本，以增强其核心竞争能力。软件服务化正是解决这些矛盾的最佳途径，用户可以根据自己的应用需要从服务提供商那里定购相应的应用软件服务，并且可以根据企业发展的变化来调整所使用的服务内容，具有很强的伸缩性和扩展性，同时这些应用服务所需要的专业维护与技术支持也都是由服务商的专业人员来承担。

二、SaaS模型研究

根据软件即服务的定义：软件部署为托管服务，通过因特网存取。根据。软件”和“存取”的不同定义，很难确定软件即服务的架构。但是，从应用架构师的观点来看，一般的SaaS结构应该至少满足以下三个特点中的一个或多个它们就是：可扩展性，可配置性，多用户高效性。从广义上说，可采用四级模型来说明SaaS应用的成熟度，每一级都比一级增加了上述三种成熟特性中的一种。

(一)传统的基于网络的软件结构模型。成熟度的第一级类似于20世纪90年代传统的应用服务供应商(ASP)提供软件的模式。在这种情况下，不同的客户拥有各自主机应用的定制版本，在主机服务器上运行自己的应用实例。从架构上说，这种成熟级别的软件与传统销售的企业系列软件很相似，即公司中的不同客户连接到服务器上运行的相同实例，但该实例完全独立于主机上其他客户运行的其他实例或进程。一般说来，传统的客户端一服务器应用无需太多开发工作，也不必从头重新设计整个系统，就能转变为第一级成熟度的SaaS模型。尽管这一级别的成熟性难以提供全面成熟型SaaS解决方案的很多优势，但仍能帮助供应商整合服务器硬件和管理，从而降低成本。

(二)可配置的软件即服务模型。对于第二级成熟度而言，供应商为不同的客户(或用户)分别提供应用实例主机服务。就第一级成熟度而言，每个实例都是对用户分别定制的，而在第_级成熟度上，所有实例都使用相同的代码实施，供应商提供详细的配置选择.让客户能改变应用的外观和行为，从而满足客户的需求。尽管不同实例在代码层面上彼此相同，但彼此之间仍完伞隔离。供应商所有客户都使用相同的代码库，这大幅降低了SaaS应用的服务要求，因为代码库的任何更改都能证刻方便地作用于供应商的所有客户，从而无需逐一更新或优化每个定制实例了。但是，在应用最初针对独立定制而不是配置元数据进行设计的情况下，将传统的应用转变为第二级成熟度的SaaS应用时，比起第一级成熟度的转型而言，将需要多得多的架构重新设计工作。与第一级成熟度类似，第一二级成熟度也要求供应商提供足够的硬件和存储资源，以支持大量应用实例同时运行。

(三)可配置、多用户效率软件即服务模型。对于第三级成熟度，供应商借助单个实例来满足小同客户的需求，并采用町配置的元数据为不同的用户提供独特的用户使用体验和特性集。授权与安全性策略可确保不同客户的数据彼此区分开来。从最终用户的角度来看，不会察觉到应用是与多个用户共享的。这时就不再需要为不同客户的不同实例提供人量服务器空间，因此使用计算资源的效率将大大超过第二级成熟度，从而直接降低了成本。但是，这时的。大弱点在于，应用的可扩展性有限。如果不用分区来管理数据库性能的话，j{能通过采用更强大处理器来扩展应用(向上扩展)，但足这样做只能使投入回报逐渐降低，最终导致功能的提高难以适应低成本的要求。

(四)可扩展、可配置、多用户效率软件即服务模型。第四级成熟度也是最高级成熟度。这时供应商在负载平衡的服务器群上为不同客户提供主机服务，运行相同的实例，不同客户的数据彼此分开，可配置的元数据可以提供独特的用户体验与特性集。SaaS系统具备可扩展性，可轻松适应大规模客户的需要，可在无需对应用进行额外架构设计的情况下根据需求灵活地增减后端服务器的数量，不管有多少用户，都能像针对单个用户一样方便地实施应用修改。

三、SaaS成熟度模型的抉择

一般来说，会认为所有的SaaS的目标都是实现四级成熟度，但是情况并非如此。可以将SaaS成熟度视为隔离数据和共享数据两个极端之间的一点。具体应用应在两端之间的哪一点上，这取决于业务、架构及运营需求，也取决于客户的考虑。一般情况下，抉择采用何种成熟度模型，取决于以下三方面的因素：

1、业务模型。隔离方法是否有利于赢利?如果抛弃了共享方案的经济性和管理优势，这将意味着向消费者提供应用的成本将会更高。但在某些情况下，为了满足其他需要，这种做法会是值得的。此外，即便向用户解释不存在机密数据遭窃的风险，但有的客户从法律或文化的角度出发，也会强烈抵制不同用户共用应用的架构模型。当然。说到底。商业模型应确保小管采取何种成熟度的模型，都能实现盈利。

2、架构模型。应用能否运行统一的逻辑实例?如果希望将基于台式机或传统客户端一服务器应用转移拿基于因特网的交付系统，那么原来的应用可能根本不能与统一实例、以元数据为中心的模式相兼容，需要明确将原系统转型为完全成熟的SaaS应用进行大量投资，到底从财务上合不合算。如果从头设计和构建网络应用，那么在采用单个实例模式时才会拥有更高的自由度。

3、运营模型。能否确保始终满足服务水平协议(SLA)的要求?应仔细考虑与客户之间现有SLA条款下应承担的责任，其中包括停机时问、支持选项、灾难恢复等，并确定上述责任在互不相关的客户共用一个应用实例的应用架构下能否得到保证。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友