大家知道SaaS应用开发的难度吗？

　  SaaS应用开发的广泛使用作为移动互联的快速发展的一部分，展现出了它不同于传统PC软件的巨大的优势。各种应用已经深入到人们生活的方方面面。SaaS应用开发在为人们生活带来科技便利的同时，也将为企业带来更多的经济效益。但是您知道SaaS应用开发的难度吗?今天就由课课家教育平台为大家讲解，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) 企业数据的规范性和统一性问题(这会涉及到参照，统计等后续一系列问题点);

　　分享：SaaS应用开发平台

　　ADP作为SaaS应用的开发平台，与iBOS完美地结合。通过ADP，开发人员快速地开发出各类SaaS应用，让iBOS强大运行功能得以充分发挥。有了ADP，您可以根据您的客户群体，由您自己或您的合作伙伴开发出符合您的客户需求的各类SaaS应用，为您的SaaS运营服务增添丰富多彩的应用服务，大大提高您的服务能力和扩展能力。 ADP和虚拟平台(VSP)一起， 将让您快速向SaaS转型。

　　ADP使得开发人员能以表单化的方式来描述应用模型， 易学易用， 大大简化了应用开发， 缩短了开发过程。 ADP将应用模型存为可以被iBOS动态读取的XML文件。一旦这些程序和模块被iBOS加载完成，iBOS就能按开发者的预先设计为客户提供服务。

　　通过iBOS和ADP， 开发人员可以轻轻松松地研发各类SaaS应用。开发人员无需了解SaaS运营，甚至不需要在开发中了解安全需求的设置，仅仅需要关心业务数据、关系、规则、流程等等， SaaS中最让人人敬畏的客户化功能也大部分自动实现，就是余下的客户化功能也让开发人员轻轻松松地实现。

　　ADP 的功能非常强大，从简单的应用到中国目前最复杂业务系统诸如电信计费、保险理赔、税务申报等等， 都能轻轻松松地在ADP上开发。开发的效率成倍提高，维护成本成倍地下降，修改升级不再是旷日持久的拉锯战。

　　ADP开发者或者业务技术人员可以通过浏览器或者Eclipse IDE接口来按照需求开发、测试业务模块

　　Microsoft Access 项目的定义：

　　Microsoft Access 项目 (.adp) 是一种 Access 数据文件，它能通过 OLE DB (OLE DB：对多种类型的数据源(包括关系数据、邮件文件、纯文本和电子表格)提供有效的网络和 Internet 访问的组件数据库结构。)

　　组件结构有效地以本地模式访问 Microsoft SQL Server 数据库。使用 Access 项目，可以像创建文件服务器应用程序那样，轻松地创建一个客户/服务器应用程序。

　　总结：

　　很多企业喜欢利用面试的方式来偷师，用处其实并不是很大，SaaS应用的单个问题点都并不是很复杂，关键在于这些点放到一起的时候，你如何根据你自己的业务进行取舍才是关键，而这种东西，靠拉再多的人来面试都是解决不了问题的，原因非常简单：不懂的人跟你讲，你会被误导，而真正懂的人给你讲的也未必适合于你的应用，如果你结合你的问题去问别人，别人也未必是hellokitty。

      随着消费类互联网市场(To C)的格局渐定，越来越多的创业者和资本将目光投向了企业级(To B)，“风口猪论” 又起。有人大胆预测：2017年 将是企业级互联网服务的 “元年”，未来几年内，国内企业级领域或迎来大发展的黄金岁月。摸准了，会诞生一批超过 10 亿美金的高价值公司。如果大家还想了解更多的相关内容，请登录课课家教育平台!