新的服务应用程序架构是一种可扩展的中间层应用程序，可以为第三方应用程序或者服务提供数据或某种专业计算能力。新的服务应用程序架构能够被服务器场中不同服务器所共享，具备一定的负载均衡的能力，该负载均衡可自定义。

全新的服务模型将更加灵活

服务将不再依赖于 SSP，而是相对独立

Web 应用程序拥有更加宽泛的服务选择余地

可对高能耗的服务实现更优化的负载平衡

既可依附于单独的服务器场，也可在多个服务器场之间共享

所有服务器场均可专门用于服务托管

用于超高能耗型服务的成本投入可控，例如Web 分析服务、商业智能、搜索服务、Office Web等等。

以上讨论过于直板，为了建立更加直观的认识，我们从一个实际案例开始吧。

故事发生在某大型能源行业国有制造企业，该企业承担了国内外众多大型工厂、工程的设计和施工项目。它已经采购了SharePoint 2007，将为它的市场部、开发部、设计部提供门户网站、项目管理、产品数据管理的解决方案。三个部门的需求和业务各有特点，又前后相继，具体如下：

1、市场部

市场部包括项目的立项申请、以及项目执行过程中的保函、佣金、签约资料、信函等文档管理和成本测算管理。每个项目产生约数十上百兆的文档。

2、开发部

开发部承担报价设计、合同设计、以及交底文档管理，合同设计过程需要进行简单的管理。每个项目产生数百兆的文档。

3、设计部

设计部承担企业所有在建项目的初步设计、详细设计、完工设计等工作，要求对设计过程中图纸目录、设计计划、设计师任务、设计工时、设计图档、设计更改、图纸晒发进行有效管控。

系统将根据设计计划向任务负责人及时派发任务，提醒设校审人员在线执行校审工作，任务完成后，系统会自动生成工时单，要求设计部人员填写相应任务所耗用的工时，由专业主管在线审核。设计部每年承担的并行项目约有十余个，每个项目在完成后，产生约20-50G的各类文档：Office、CAD、各种三维模型等等。这些文档最终会形成一个可交付的结构化的项目成果库。

考虑到本系统承担了大量的数据存储和计算工作，因此设计院购买了3台8核16G的IBM 服务器，以及统一备份管理的高速磁盘阵列。然后，组织人员使用SharePoint 2007 实施了以上解决方案，解决方案中包含了大量自定义的工作流活动、事件处理、Web部件、应用程序页面。

服务器规划：一台SQL Server 报表服务器、一台作为应用服务器、一台前端服务器、数据库服务器使用了企业的统一SQL Server 集群。

网站规划：

本系统上线不久，就遭遇了用户较为强烈的不满，尤其是市场部和开发部，由于这两个部门的应用只是简单的文档管理和较少的工作流管理，他们反映新上线的系统还不如之前一家小公司实施的文档管理系统响应速度快，这不合常理。

通过上面的网站规划，显而易见，且不论服务器组合是否有优化空间，网站规划逻辑本身就很有问题：所有门户和项目网站都放在同一个网站集中。

为什么说这是一个问题呢？我们可以通过SharePoint的几个基础概念来弄懂这个问题所在。

1、服务器场

将多台物理服务器组合成一个硬件资源池，从而实现单台服务器所不具备的处理能力。

2、Web应用程序

对硬件资源池的计算和存储虚拟化，任何系统都离不开两个方面：计算（CPU和内存）、存储（磁盘）。SharePoint Web应用程序使用IIS来发布，使用W3WP的一个进程实例，内存上限一般设定为800M – 1G ； 它使用SQL Server来进行数据存储。

可以回想一下SharePoint  ”管理中心”中， Web应用程序的创建过程，指定一个应用程序池名称，指定一个数据库名称（当然，一个Web应用程序可以包含N个内容数据库，此处指的是创建的第一个数据库名称，一般名称为WSS_Content_XXX），实际上可以认为是对计算资源和存储资源的分配。

小结一下：一个Web应用程序只能有一个应用程序池（计算资源，有内存上限，尤其32位系统）和多个内容数据库。

3、网站集

网站集是一堆面向具体业务应用的网站的集合。如果说Web应用程序还是对资源的分配，与具体企业业务没有具体关系的话，那么网站集则是从Web应用程序分配的资源里面分出一部分，服务于某个具体业务需求。网站集在创建的时候，会默认创建一个顶级网站，以衍生出一些列的子网站，算得上是所有网站的父亲、祖父、曾祖父……

一个网站集只能存储于一个内容数据库中。 但一个内容数据库可以存储多个网站集的内容。一个网站集只能属于一个Web应用程序，也就只能够使用当前Web应用程序对应的单个计算资源（一个W3WP，不超过1G的内存使用上限）。

4、网站

网站集中的一个具体应用的示例。

我们通过以上的介绍来分析一下该企业网站规划的问题所在。

首先，由于使用的是单个网站集存储所有数据，就意味着所有数据都必须存储在一个SQL Server数据库之中。该企业设计部以10个年并行项目计算，10 X 20G = 200G。每年该数据库至少多出200G的数据。而SharePoint 2007 推荐的单库大小是80G，不超过 200G。实际上很多项目在完工后，都处于只读状态，但却不得不参与数据库的查询分析，影响了数据库的性能。

其次，由于设计部的功能使用了大量的计算资源，如原始CAD dwg图纸的在线转换可视化，产品结构基线分析等等。使得共用同一“计算资源”的市场部和开发部不得不忍受着资源被抢占的痛苦。

明白了问题所在，参考以上的几个基础概念，在SharePoint 2007下，我们可以将设计部放置在单独的Web应用程序中，将市场部和开发部放置于另一个Web应用程序中，从而将双方的计算资源独立。此外，使用网站集来管理每一个项目，从而确保每个内容数据库中容纳不超过2个项目网站集。似乎一切都开始正常了。

但是也存在一些问题，譬如，由于存在两个Web应用程序，在部门网站切换时，需要再次认证；在调用另一个Web应用程序数据时，需要额外的认证和设置等等。

在SharePoint2010 中，这些可以进一步优化，譬如我们看到的Office Web App服务，就类似于CAD文档在线可视化的服务，在新的服务应用程序架构中，这种高能耗的服务被独立出来了，可以使用单台或多台服务器，甚至一个独立的服务器场为该运算进行服务。同样，对于一些具备全局特点的数据，也可以通过服务应用程序来提供。

但是为了适应Sharepoint 2010的服务架构，我们提供一个A+B的加法运算服务，也需要编写大量的代码，使它能够通过Powershell创建、在管理中心被设置，被Web应用程序关联调用等等。所以，它是一把牛刀，非必要场合不要用它，毕竟开发者都是比较懒的。