SAAS相关技术要点

这篇文章原本是咱们开发组内部用的一个小文档。由于咱们公司之前没有作SAAS的经验，就成立了一个小组作一作这方面的技术前探，我是成员之一。这篇文档想从宏观的层面把开发一个SAAS应用所要用到的技术点稍微梳理一下，便于指导后面的技术前探工做。之因此发在这里，是由于本身相关的研发经验太缺少，可能有些技术盲点是本身根本没能考虑到的，但愿园子里的各位大牛多多指导。

一.聚焦“三头怪”

  在MS的官方文档中，把构建一个足够成熟的SAAS（MS简单列出了SAAS应用的4级成熟度）所面临的3个主要挑战：可配置性，可扩展性，多用户存储结构设计称为“three headed monster”。在MS给出的两个SAAS的demo(分别为LitwareHR和Crab)中，着重解决的也是这三个问题。因此，咱们在进行技术前探的时候，也要扣准这三条主线。

1.概念
  SAAS是一个典型的“单实例多处应用”的软件类型，这就要求实例自己在不一样的应用环境下有很强的配置能力。具体说来，须要对如下4个方面提供配置能力：
  （1）程序的外观。
  （2）工做流程与业务规则。
  （3）数据模型。
  （4）用户及最终用户的存取权限。
  这种自定义的能力应该在易配置性和配置能力两个方面作好权衡，最优的结果固然是经过最方便的配置手段来实现最复杂的自定义功能，但这并不容易作到，因此有可能咱们会须要为一些比较高级的用户提供基于已有系统的二次开发能力（使用脚本等）。下面咱们就具体来谈一下关于可配置性的各个方面。

2.配置的实现基础：元数据（MetaData）
  系统经过配置数据展示不一样的外观和行为，那么对整个系统来讲，配置数据就是系统中的元数据。笔者本身也没有特别研究过元数据，仅仅是开发中用过一些xml文件或者数据库中的特定表来保存一些配置信息，但对于一个成熟的SAAS应用，这种简单的配置方式多是不够的。如何设计出结构灵活、功能强大、兼容性好的元数据结构，如何在代码中提供最有效率的元数据服务（Metadata Service），如何定义元数据的元数据（Metadata of metadata），如何保证在元数据结构发生变化的时候不影响程序的运行，这一切都须要咱们在对元数据自己的语义特性和可能的技术支持手段进行过调研以后才能得出。另外，笔者在写这篇文章的时候，很偶然在网上找到了几幅关于元数据服务层设计的图片，颇有意思：

上面这幅图的上半部分给出了SAAS参考体系结构的一个概念模型，下半部分则给出了对应于体系结构的每一部分，现有的可能采起的技术手段。咱们注意到，元数据服务和元数据数据结构定义是里面惟一的盲区。
   下面这个图是Matias Woloski给出的对各主要配置模块（界面、业务规则、多用户数据结构、访问控制）提供的元数据服务的可能解决方案，也许能够作为咱们进一步深刻的一个线索。

3.配置的需求基础：业务共性提取与业务个性分析
  为何是全部tenant共享一套代码？由于全部这些用户在软件需求上有共同的须要，在业务流程上有不少共通的地方，他们全部的应用都是在一个比较肯定的业务领域（Business Domain）内展开的。咱们须要把这个业务领域内的业务需求梳理清楚，而后提供咱们的软件为这个业务领域服务。既然他们都属于一个业务领域，那么咱们提供一套能够运行的软件就好了，为何还要提供那么强的配置能力呢？由于同属于一个业务领域内的客户，他们在业务规则的细节上其实有不少不一样，业务流彻底相同的两个企业实际上是不存在的。另外，每个企业都在不停的发展变化，业务结构也都在不断的调整、重整、升级过程当中，咱们的软件应该能够在必定的弹性范围内，支持企业的这种升级。
  因此，研究咱们的SAAS软件所要解决的业务领域特色，找出这个领域目前在横向范围内的企业业务间的差别性，以及在能够预见的未来的业务升级要求，实际上是实现SAAS软件最开始的、也是最难的一步。但这一步骤自己和技术的关系可能并无那么大，所涉及的最多也能也就是包含UML在内的众多领域建模技术。这一部分应该属于SAAS研究中业务和技术结合、同时业务占据的比重更大的一部份内容。

4.配置主要内容1：程序外观的配置
  外观的配置其实包括的内容不少，但比较核心内容笔者认为是界面元素的多粒度模块化，只有实现了这一点，才有可能让用户在多个粒度级别上去定义本身想显示什么、以什么样的界面风格去显示。这一点上也一直是笔者认为.Net比较有优点的地方，由于MS的产品一直在构件化上面表现不俗。仅就Asp.net2.0中，已经有Custom Control,User Control,Web Parts,Theme, Skin, MasterPage等成熟界面技术可使用；在.Net3.0的WPF(现已改名为SilverLight)中，相信更有不少优秀的模块化界面技术的出现，笔者还没有研究过。这些都须要咱们去学习和发现。
  另外，若是咱们继续采用基于浏览器的软件系统，Web程序的“体验本地化”是必不可少的工做，在这方面AJAX技术已经愈来愈成熟，MS的AJAX 1.0正式版已经发布。
  咱们在学习这些界面技术的时候，不只要学习它们的使用方式，还要明白它们底层的编译模型和运行模型，这样咱们才能对每一个显示模块对象实例如何以最小的运行成原本完成尽量多的界面显示和交互响应功能有充分的把握。

5.配置主要内容2：业务流程的配置 
  所谓业务流程，不知笔者的理解是否正确，其实应该属于经典的工做流（workflow）问题。因此这一方面尽管很是重要与复杂，但研究起来重点却最为突出，无非就是两个：
  （1）对工做流方法论的研究。笔者没做过关于工做流的开发项目，在这方面暂时没有发言权，但笔者认为在利用工做流相关的工具和类库进行开发以前，应当在方法论上对工做流有一个比较有度的把握。
  （2）对各类现存的工做流工具的研究。工做流是企业开发的重点，相关的产品应该很多，笔者知道的主要工具以下：
      a.WF(Microsoft Workflow Foundation), 这是.Net3.0新增的三大类库之一，专门用于对工做流技术的支持。
      b.BPEL(Business Process Execution Language),这是由IBM牵头搞的一个利用XML来描述业务过程行为的标准，目前在业界也获得了普遍的支持和应用。固然，BPEL并不彻底等同于工做流，它对人、角色、工做项目等并无明肯定义，重在刻画一个基于Web服务的业务流程。
  
6.配置手段的易用性
  一个被普遍接受的观点是，易用性可能成为一个SAAS软件成败的关键。做为SAAS应用的使用者，确定会关心是否是他的每个员工都能很容易的使用这个系统，这实际上是企业部署SAAS应用的主要成本之一。而在整个系统的操做中，对外观和业务流的自定义配置颇有可能成为最复杂的部分，这部分操做的易用性也将直接影响整个软件的易用性。
  想加强配置手段的易用性，须要咱们多向salesforce这样的成熟SAAS应用学习取经。  

三.可扩展性及相关技术

1.概念
  应用的可扩展性包含两个方面的要求：（1）高效地利用应用资源，从而最大限度地提升并行性。（2）当原先的服务器资源确实没法知足不断增长的用户数量时候，能够很方面的经过向上扩展（提高硬件性能）或横向扩展（增长硬件数量）来提升整个系统的并发处理能力。可扩展性并不只仅是SAAS面对的难题，全部基于Internate的大型网络应用队会面对这样的挑站，因此网络上相关的资料不少，大多谈及大规模企业应用的体系结构设计的主题，都会涉及到对可扩展性问题的讨论。笔者本身没有开发过大型的应用系统，更详细的知识点须要进一步的学习和了解以后才能给出，下面暂时只能简单列出一些笔者之前接触过的内容做为可能的技术研究点以下。

2.可扩展性支持技术1：应用的无状态模式
  咱们须要研究如何设计应用，使之运行在无状态模式下。也就是说，全部必需的用户和会话数据都存储在客户端或分布式存储设备上，任何应用实例都能访问。无状态是指每一个事务处理都能由任何实例来完成，用户在一次会话中可用众多不一样的实例进行事务处理，但用户自己并不知情。好比咱们在作Asp.net开发的时候，若是用Session变量来存储状态信息，由于它须要占用服务器资源，当你想增长机器以扩展性能的时候，它们会起阻碍做用，由于Session是与特定机器相关连的。在这方面，也许咱们能够参考EJB中的关于无状态会话Bean，以及其管理器无状态管理器的实现。其实，internet能发展到今天的规模，跟http这个无状态的协议应该有很大的关系，而internet的扩展性已经在现实世界中被印证了，因此若是咱们能尝试着去理解整个因特网的结构特色，也许咱们对如何建构一个高可扩展性的大型系统会有更深的了解。另外，从SOA的角度来说，提倡的Service通常是Stateless的，给定什么样的输入，就会有对应的肯定的输出。一旦服务有了状态，就没法方便的使用对象池来减小对象的数量，从而提升了负载。

3.可扩展性支持技术2：大型数据库的分解、重构技术
  MySpace是一个过亿注册用户的超大型网站，在三年的发展过程当中，它完成了从一个单服务器到及具扩展性的架构的变化，我想种变化其实对于咱们研究如何创建一个可扩展的系统其实有很强的借鉴意义：
（1）最先。两台Web服务器，一台数据库服务器，和咱们目前的结构是彻底同样的。在初期的发展中，MySpace就是经过添加新的web服务器来提升性能的，直到其数据库服务器过载。
（2）50万用户。要增长数据库，这时候面临着保证数据一致性的问题。在第二代架构中，他们启用了3个SQL Server数据库服务器，一个为主，接受全部的数据提交，并将内容复制给另外两个，由它们全力向用户提供数据。在这个架构中，经过增长辅数据库服务器的方法，能够有效应对系统访问量的增长。
（3）100-200万用户。数据库服务器开始受制于I/O容量。这时候，把全部业务放到一个DB上看来已经不行了，因而他们对数据库的架构进行了垂直分割，不一样的数据库服务器服务于不一样类的功能，有的负责登陆，有的负责博客等。另外，但用户达到200万的时候，他们启用了存储区域网络（SAN:Storage Area Network）。按MySpaces的说法，此举极大提高了系统的性能、正常运行时间和可靠性。
（4）300万。垂直分割不够用了，毕竟有些信息（如用户表）须要在全部DB中共享，维护数据一致性的开销很大。另外，有一些应用增加太快，其专用DB压力太大。这时候，须要进行向上扩展(Scale Up:升级服务器)和向外扩展(Scale Out:增强分布式能力，用大量便宜的服务器来分担压力)的抉择。为了尽可能少改动之前的代码，他们先考虑了向上扩展，研究了如何使用32CPU的服务器的问题。但最终，他们仍是走上了向外扩展的道路，开始提炼分布式计算架构（这是向外扩展架构必须面临的问题，大厂商如Google甚至开发了本身的分布式文件系统）。这时候，前面被拆分的应用在逻辑上又被整合了起来。而且，用户以百万为一组，被分别存储不一样的DB。固然会有一个特殊的DB来控制全部的账号和密码，但其功能单一，也就比较容易控制负荷。
（5）1000万。采用了新型的SAN,更改了SAN和数据库的绑定方式。在Web服务器和数据库服务器之间加上数据缓存层---他们说这是一开始就应该作的事情，但他们成长太快，以致于一直没有实现。
（6）2600万。采用SQl Server2005，由于支持64位的数据库可使用更多内存。  
  从MySpace的变化能够看出，随着用户量的增长和用户数据量的积累，数据库服务器将日益成为瓶颈。在它成为瓶颈以前，充分作好各类相关的技术准备工做是必须的。

4.可扩展性支持技术3：线程和网络链接等聚集资源的共享（负载均衡）
  将线程、网络链接和数据库链接等资源集中，这有助于使计算资源最大化，并提升咱们预测资源使用的能力。固然，在这些方面，其实IIS和ADO.NET等基础的资源服务系统已经做了不少相关的考虑，咱们作的资源调度应该是基于这些服务器之上的。咱们能够参考.Net对线程池的管理，也能够参考ADO.NET对链接池的管理。另外在进行资源调度和管理的时候，要充分考虑整个网络的拓朴结构，并充分借鉴分布式系统在实现方式特别是资源调度算法上的一些考虑和特色。
  因此，这里总的来讲强调的是一种负载均衡的概念，而负载均衡除了上面提到的这些软件方面的手段，可能还包括对一些硬件设备的认识和选购，特别是对各类负载均衡服务器的性能和功能的掌握。

5.可扩展性支持技术4：其余
  （1）多级缓存技术。缓存，说白了就是用空间换时间。越是并发的系统，越须要仔细考虑缓存的问题，咱们每发现一处能够在多用户间反复重用的数据并将其加入缓存，都有可能使这部分数据的生成效率提升上千倍（若是这个数据能够在上千个用户间共享的话）。另外，如何提升缓存的命中率，也是当咱们的网站逐渐变大以后，愈来愈重要的问题。还有，对于memcache这类的比较牛的缓存解决方案，也许咱们也须要深刻研究它与咱们项目的结合点。
  （2）仔细研究数据库的锁定方式，在对数据库操做的时候，尽量锁定小范围的数据集合。采用既能够实现并发最大化，同时还能使排它锁定最小化的方式写入数据库操做。例如，在执行只读操做时，不要锁定记录。这些环节看似虽小，其实对整个系统的并发性都有显著的影响。  

四.多用户存储结构设计及相关技术
  一家公司的用户使用咱们的SAAS应用服务存取客户信息时，该用户链接的应用实例同时可能还会为其余几十家，甚或是数百家公司的用户提供服务，各用户之间彼此互不知情。这就要求应用架构可以最大化不一样用户间的资源共享，不过仍要区分属于不一样客户的数据。因此，咱们在设计存储结构的时候，一方面要考虑结构自己的可扩展性，一方面还要考虑数据访问的安全性。

1.数据访问控制
  数据是否是安全，会不会被没有权限的人窃取或篡改，这是用户最关心的，所以也是咱们最关心的。安全问题涉及的内容也确实是很是多，笔者这里试着从几个方面简单进行阐述：
（1）过滤：在用户和数据源之间加入中间层，给用户的感受是数据库里只存了本身的数据。
 在这方面，典型的手段是采用视图。
（2）权限：采用ACL来限制谁能访问什么数据，以及能够对数据做什么操做。
   在这方面，有一个很关键的问题是如何创建一个受信任的链接。比较常见的方式有服务器模拟客户端用户的身份（impersonation）去访问数据；或者服务器始终以本身的进程身份来访问数据（受信任的子系统方式），额外的安全都放在应用的内部。前一种方式配置上比较复杂，但安全性较高；后一种方式不须要太多配置，但安全性较低，而且有些资源单靠服务器进程自己的访问级别是访问不到的。咱们在开发的时候可能须要混合使用这两种链接方式。
   另外，有些时候可能须要服务器以代理的方式来访问一些其余资源。
（3）认证（Authentication）
  前面几点说的都是对于某个特定的用户，系统如何控制他的访问权限（也就是说，都属于受权/Authorization方面的问题），那么系统如何知道某个客户端请求确实是来自某个用户呢？这就是Authentication要作的工做。单就这一部分，包含的知识也至关多，以Asp.net2.0为例，就有Windows验证、基于表单的验证等；单就Windows验证，又有Kerberos，NTLM等不一样的验证协议，这些验证协议在对代理服务器的支持、运行效率上都是有差异的，须要咱们学习和掌握。另外，在.Net3.0中，MS在这一起好像又提出了一个新的概念和实现技术，CardSpace。这个技术里应该是凝结了MS对网络安全的最新思考，笔者以为应当重点关注（此技术和Active Directory, WCF, Windows Live ID等技术都有很强的相关性）。
  还有，从宏观上来看，认证的方式分为集中式认证（centralized authentication system）和非集中式认证（decentralized authentication system）两种，咱们须要研究它们之间区别和联系，结合起来利用。
（4）加密
  对用户的敏感数据进行加密，未受权方及时得到了这些数据也派不上用场。能够采用对称或非对称的加密算法。非对称算法的保密性好，但处理开销也大得多。实际操做中，通常是两种方式混用，即数据采用对称加密法，但用非对称加密法来加密对称密钥。

其实，和安全相关的问题还有不少，好比sql注入，代码安全等等，这里就不一一详述了。

2.可扩展的数据结构
  关于这一部分，MS在其白皮书中的第二章《多用户数据体系结构》中已经有了比较详细的交待，本文中就再也不重点介绍。可能采起的数据结构有：（1）独立数据库；（2）共享数据库，不一样用户有不一样架构；（3）共享数据库，共享架构。一共是三种方式，这三种方式的资源利用率愈来愈高，但在设计上也愈来愈复杂。因此，也并非共享的程度越高越好，下面这幅图说明了如何在数据库的独立和共享性上面作以取舍：

对于三种模式中最复杂的“共享数据库，共享架构”，MS给了两种建议性的方案：预约义扩展字段以及名值表。一方面，咱们能够参考这些方案实现，另外一方面咱们也能够思考本身的方案出来。另外，无论数据存储到底采用哪一种方案，都要为数据表之后可能的横向或纵向切分留下余地。从数据库的横向扩展来看，主要的手段是复制和分组，具体如何去作都须要进一步的研究。

五.SAAS与SOA
  SAAS指的是一种软件商业模式（特别是营销模式），而SOA指的是系统的实现（包括已有系统的整合）方式，二者本不在一个概念层上，但笔者在这里仍是想强调一下二者之间的关系，特别是SOA的相关技术对SAAS的重要性。由于在SOA身上体现了业务整合、业务敏捷等众多特性，正是SAAS所须要的。特别是业务敏捷，虽然它强调的是一个企业业务在纵向时间轴上的变化和软件的应对，而SAAS更强调在同一时间点上同步厂商之间的业务区别，但二者在技术要求上并没有本质区别。
  另外，SOA已经渐渐成为企业应用开发的标准，咱们的用户除了采用咱们的SAAS软件，极可能还使用了不少其余的应用系统。为了能让咱们的系统更开放，和其余的周边系统有更好的交互，一种SOA的思想和技术手段将在咱们的开发中必不可少。
  SOA自己也是一个技术集，涵盖的面很是广，本文在此就不展开了。

六.其余技术

1.单点登陆
  对现代网络应用易用性的基本要求之一，至少在咱们系统内部，咱们要作到用户一次登陆，便可访问全部他有权访问的全部子系统。

2.对SAAS树状体系结构的进一步认识
  SAAS自己是一个从服务提供商到各个企业，从企业到各个部门，从部门到每一个最终用户的树状管理结构，这样的一个结构包含一些能够利用的技术特色：
  （1）安全权限的继承性
  系统的受权（Ahthorization）通常都是根据用户组/角色/Role来进行的，在对受权的管理上，MS提出了一个“配置域”的概念。存取控制由配置域管理。每一个配置域根据应用的关系策略继承上级配置域的角色、许可和商务规则，并可在适当的时候对其进行修改、添加和删除。从概念上来讲这是很是合理的，好比一个企业内的部门是一个配置域，它的上级配置域就是企业，而下级配置域可能会具体到每一个最终用户（也多是部门内的小组）。但具体实现的时候如何去作，还须要咱们进一步研究并给出方案。  
  （2）用户的不一样等级
  按MS的文档，将用户区分为“用户”和“最终用户”。其实这里的“用户”指的就是一个单位或组织，不一样“用户”之间的数据至少在逻辑上是互相隔离的。而“用户”能够为本身企业内部的多个“最终用户”受权，最终用户最终能在用户的控制之下访问到用户数据的一个子集。
  这种把用户分红等级来处理的方式是颇有意义的，好比在创建受信任链接的时候，就能够采用用户模拟和非用户模拟两种方式的结合。对用户采用模拟方式，对最终用户采用非模拟方式。好比在存储结构设计的时候，能够给用户单独创建数据库。

3.活动目录  若是咱们全部的数据都取自关系数据库服务器，那么可能永远不须要活动目录。但有些资源是存储在文件系统中的，这就须要活动目录为咱们提供存取服务了。咱们须要研究原有的Active Directory技术，以及刚提出的ADAM(Active Directory Application Mode)等技术。