最近跟几位产品总监和技术的朋友们聊天，很多认为SaaS很简单，无非就是一个按量收费的多用户租赁模式。
其实真的是这样吗？
（no，答案太过于片面~）
why？
SaaS确实是云计算的一种，确实是按量收费，一般也是采用多用户租赁模式，这些都是没毛病。但是说SaaS模式的架构非常简单，那就只能说大家对SaaS的理解仍然存在于一个表象的层面。要么就是认为把一个局域网的东西搬到公网这就是SaaS，要么就是没有做过真正SaaS或者所做的SaaS应用只是一种非常低级的模式，甚至根本谈不上是云计算的范畴。
作为一种云计算模型，一个典型的SaaS模式首先需要以下三种计算模型支撑：
1）分布式计算模型
这是最基本的模型，也是后两种模型的基础；现在非常火的Hadoop就是分布式计算模型中一种。
2）分布式数据存储和访问模型
分布式数据库访问和存取模型是SaaS企业应用的基础。
这种模型也很多，GFS，HFS，TFS都属于这类，当然一些分布式数据库包括阿里的Ocean数据库也都属于这一类；对于企业级的应用底层数据节点不采用数据库当然是可以的，但如果采用数据库，好处也是非常多的，至少要简单很多。
用什么类型的数据库，这个需要从你SaaS平台本身的业务进行考虑衡量，主要是从数据分离方式和效率两个方面。比如对SaaS企业应用来说，采用GreenPlum这类数据库并不是不可以。特别是牵扯到关联查询的时候，对于一个按用户分离和隔离的企业应用，如果数据节点采用关系数据库，那么80%的企业应用的关联查询都会落到一个节点中，那么查询的效率自然会比较高。如采用分布式数据库，一般都很难做到这点——分布式数据库处理这类查询的时候，都需要把数据集中到一个节点进行处理（分布式数据库中的A表和B表并不一定在一个数据节点的），虽然可以采用一些策略来减少无效数据的传输，但往往效果不大。
观点：
对于分布式计算，通用往往代表着效率更低。
Google的GFS设计理念：面向应用设计接口，较受认同。
3）分布式部署与运维模型
作为云计算下的SaaS应用，必须是可以支撑横向扩展（Scala out)的,而这些节点（包括应用节点和数据节点）的增加和管理完全靠人力去完成，基本是不可能的事情。
因此只要是云计算模型下的SaaS应用，分布式部署与运维支撑模型就是必须的：应用程序节点的实时监控，管理和部署，数据节点的实时监控和部署，缓存节点的监控，管理和部署，文件服务器的监控，管理和部署等等。
以上三种模型就构成了SaaS应用的基础，但SaaS应用又有自己的特殊性，因为牵扯到商务逻辑、事务处理（高一致性和准确性）以及数据的整理和分离等。
比如，SaaS应用的分布式数据存储和访问往往不能简单的采用已有的一些开源分布式系统，或者一些开源的分布式数据库系统，因为在大型的SaaS应用中，数据的分割（分布的基础）往往也不能做到单一，而数据的分割又会影响数据访问的路由策略。这就导致通用型的做法不太适合具体的需求。
是不是光从计算模型上已经感觉到了技术的光环了~~~
