说一说 SaaS 应用开发的难度在哪儿

最近做SaaS应用的很多，这种模式是未来的一种趋势，这种模式的最大好处就是云计算的好处--节约资源。网上有很多人觉得SaaS很简单，就是一个多用户租赁模式。这种认识也不能说不对，因为SaaS确实一般都采用多用户租赁模式。但这种说法非常的不全面，是一种盲人摸象。而且很多人认为SaaS 模式的架构非常简单，那就只能说他没有真正做过SaaS模式或者他们做的SaaS应用是一种非常低级的模式，根本谈不上是云计算的范畴，就是一个把局域网的东西放到了公网而已。

作为一种云计算模型，一个典型的SaaS模式需要以下三种计算模型支撑：

1)分布式计算模型

这是基本的模型，也是后两种模型的基础;现在非常火的Hadoop其实只是分布式计算模型中一种，而且并不是特别的复杂;

2)分布式数据存储和访问模型

这种模型很多，GFS，HFS，TFS都属于这类，当然一些分布式数据库包括阿里的Ocean数据库都属于这一类;分布式数据库访问和存取模型是SaaS 企业应用的基础，对于企业级的应用底层数据节点不采用数据库当然是可以的，但如果采用数据库，好处也是非常多的，至少要简单很多。现有的分布式数据库对于 SaaS应用，特别是SaaS企业应用来说采用GreenPlum这类数据库并不是不可以，但需要根据你的SaaS应用的业务本身进行权衡(主要是数据分离方式和效率的问题)。特别是牵扯到关联查询的时候，对于一个按用户分离和隔离的企业应用，如果数据节点采用关系数据库，那么80%的企业应用的关联查询都会落到一个节点中，查询的效率会比较高。如果采用分布式数据库，一般都很难做到这点，因为分布式数据库处理这类查询的时候，都需要把数据集中到一个节点进行处理，虽然可以采用一些策略来减少无效数据的传输，但往往效果不大。(分布式数据库中的A表和B表并不一定在一个数据节点的)，这也是我一直以来的观点：对于分布式计算，通用往往代表着效率更低。我比较认同Google的GFS设计理念：面向应用设计接口。

3)分布式部署与运维模型

作为云计算下的SaaS应用，必须是可以支撑横向扩展(Scala out)的,而这些节点(包括应用节点和数据节点)的增加和管理完全靠人力去完成，基本是不可能的事情，因此只要是云计算模型下的SaaS应用，分布式部署与运维支撑模型就是必须的：应用程序节点的实时监控，管理和部署，数据节点的实时监控和部署，缓存节点的监控，管理和部署，文件服务器的监控，管理和部署等等。

以上三种模型就构成了SaaS应用的基础，但SaaS应用又有自己的特殊性，因为牵扯到商务逻辑、事务处理(高一致性和准确性)以及数据的整理和分离等，SaaS应用的分布式数据存储和访问往往不能简单的采用已有的一些开源分布式系统，或者一些开源的分布式数据库系统，因为在大型的 SaaS应用中，数据的分割(分布的基础)往往也不能做到单一，而数据的分割又会影响数据访问的路由策略。这就导致通用型的做法不太适合具体的需求。

SaaS 的这种基础实际上就已经非常具有技术含量了，而SaaS业务应用本身，在逻辑上就更难了，并不是访问数据库加上一个隔离字段那么简单。一般SaaS系统除了基本的多用户租赁(注意，设计SaaS的时候一定要以软隔离为基础，这样可以做到最大化的自由，而且不会影响数据库隔离和数据库实例隔离的需求 )还会牵扯到在线许可，多时区，多语言，以及功能、页面、流程的可配置。特别是更深层次的应用更会涉及到在线跨企业资源共享和流程协作的问题，处理这类问题会非常棘手。特别是SaaS在线企业级应用，你需要面对的问题会更加复杂(业务规则的分与合)。如果在做架构的时候，如果没有考虑到这些问题，后面的噩梦会很多。甚至你可能玩不转。

SaaS应用其实并不简单，哪怕就是一个CRM在线应用，也是非常具有业务和技术含量的。根据我的分析，纷享销客和销售易虽然融了不少的资，但他们的系统架构还算不上真正意义下的云计算模式下的SaaS。金蝶，用友，速达的在线应用虽然没有深入研究，但通过他们用户的一些反馈，我感觉60%的可能性是伪云计算SaaS应用。当然，如果知道内幕的，可以告诉我。

SaaS企业应用涉及的点非常多，而且很多点之间是有关联的，因此你必须在这些问题点的处理中不断地进行平衡，进行取舍。比如，采用面向服务(SOA)的架构，在一定程度上是可以减少一些复杂性，但这样一来也降低了应用系统的整体性，SOA的粒度和边界的划分就是非常重要的权衡点。

在进行企业SaaS应用架构的时候，最好先弄清以下几个点：

1) 数据隔离和数据分布的路由策略;

2) 需要做哪些业务，是否需要做用户间进行资源共享和流程协作;

3) 如果需要资源共享和协作，那么这个过程中的用户数据归属问题;

4) 企业数据的规范性和统一性问题(这会涉及到参照，统计等后续一系列问题点);

......