saas的由来

saas现在可能还是一个比较新的概念，或者说还不是那么普及，那么现在我们就来看一下saas的由来并且来看一下saas是不是以后软件发展的趋势。

从做项目说起

    软件公司从做项目开始，针对某个行业会针对性的做不同的项目，项目中包含的内容可能相当，也可能不相同，以XX公司为例，假设XX公司做办公自动化业务。

这也就是传统的项目型结构，在项目型结构中，如下图：

在图中可以看到，每个项目都会有不同的需求，其中很多是相同的，很多是不同的。

比如功能1，功能3和功能5，这些是相同的。

当这样的项目非常多的时候，我们就会从中发现很多相同的部分，于是就有了产品。

软件产品

     还是上面的公司，从项目到产品是一个封装的过程，将相同的部分提练出来，然后将不同的部分开发出来，进行定制化。

根据不同的用户需求，进行模块化的定制，并且销售给不同的用户，这样成本会得到很好的控制同时也能产生相当可观的利润。

其它模块根据情况进行定制。

这样看起来是没有什么问题，但是新的问题来了，对于一些不想花大的价钱来使用软件的用户来说，产品的价格对于他们来说还是非常高，而且还会增加很大的运营成本，包括数据库的升级，软件的升级，硬件的维护和管理等。

于是就有了我们提到了saas，他很好的解决了这些问题，来看一下saas软件的优势：

给用户的优势：

1. 拿来即用
2. 无需维护
3. 按需使用
4. 随处可用
5. 风险减小
6. 成本降低
7. 先天防毒

给供应商的优势：

1. 节省销售成本
2. 节省维护成本
3. 稳健的经验模式

saas的成熟度

第一级、可定制
     第一级成熟度类似于上世纪90年代初的应用服务提供商(Application Service Provider)所采用的软件交付模式。在符合这一级成熟度的系统中，每个客户拥有一个为其定制的应用实例，这一单独的实例运行在SaaS服务提供商的硬件之上。从系统架构而言，这一级别的SaaS系统和传统的本地安装软件非常相似，同一客户的不同终端用户使用客户端软件连接同一个应用实例，但这一客户实例和服务提供商同时运行的其它客户的应用实例相比是完全独立的。

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

这种怎么看怎么像我们传统意义上的软件开发模式，就是找客户，然后根据客户的需求进行定制化的开发，也就是可定制的，但是需要多次开发，一个客户拥有一个实例。

比如上面我们的例子，有可能会在应用服务提供商处产生多个软件的实例。

第二级、可配置
     在符合第二级成熟度的系统中，每个客户还是各自拥有一个单独的应用实例，但不同之处在于第一级中的用户实例是根据每个客户的需求单独定制的，而在这里，每个客户使用相同的代码。SaaS服务提供商通过详细的具体配置选项来允许客户改变自身应用的外观和系统行为。尽管如此，不同的应用实例之间还是保持完全独立运行。

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

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

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

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

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

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

 

saas系统的三大要素

从系统架构的角度来看，要设计一个符合实际业务需求的能够支持多用户同时访问的SaaS系统就必须关注以下三大要素：可扩展(Scalable)、高效的多用户支持(Multi-Tenant-Efficient)、可配置(Configurable)

可扩展
     可扩展意味着最大程度的提高系统并发性，更有效的使用系统资源。比如说应用，优化资源锁的持久性，使用无状态的进程，使用资源池来共享线和数据库连接等关键资源，缓存参考数据，为大型数据库分区等技术。

高效的多用户支持
     可高效的多客户支持则是设计基于SaaS模式的系统中最为重要的一环。比如说当一个用户试图通过某个基于SaaS模式的客户关系管理应用(Customer Relationship Management)来访问本公司的客户数据时，它所连接的这一基于SaaS模式的客户关系管理应用可能正同时被来自不同企业的成百上千个终端用户所使 用，此时所有用户完全不知道其他并发用户访问的存在。这种在SaaS应用中极为常见的场景就要求基于SaaS模式的系统可以支持在多用户间最大程度共享资 源的同时严格区分和隔离属于不同客户的数据。

可配置
     当在传统的本地安装软件的使用环境中谈论可配置性时，直接修改部分代码进行二次开发来适应当前用户的需求是比较常见的解决方案。但在基于SaaS模式的使用环境中，如果业务应用的任何部分被修改了，则这一修改将可能同时影响所有当前客户的使用环境。因此，一般而言在SaaS模式的使用环境中，客户使用元数据(Metadata)来为其终端用户配置系统的界面以及相关的交互行为。由此可见，设计SaaS系统的一大挑战就是要确保配置 软件应用的过程本身是简单且易于为客户所直接理解并使用的，而且应该无需考虑付出任何额外的开发和维护成本。