SharePoint 2010 服务应用程序(Service Application)架构（1）

SharePoint 2010认证考试出来之后，去把几个考试都考了一遍：70-573、70-576、70-667、70-668。如果你正有计划也去参加这几门认证考试，我可以提供的建议是：不要在11:30开始考70-668，否则到12:00吃饭的时候，你很可能还没有答完题目。70-668包含不少场景题，也就是给一个场景，包含各种Business Requirements、Technical Requirements、Recovery Requirements之类，然后基于此场景选出最佳方案。阅读并理解场景会花费不少时间。

嗯，言归正传。如果你曾经使用过SharePoint 2007，一定知道在SharePoint 2007中有一个叫做“共享服务提供程序”（Shared Services Provider，简称SSP）的东东。SharePoint 2010对SSP架构进行了优化，设计了一个更灵活、更有扩展性的架构：服务应用程序（Service Application）架构。这几篇博文将围绕Service Application，仔细讲讲这个东东。由于服务应用程序是SharePoint 2010一个非常基础的架构，无论你是Developer，或是IT Pro，都需要对它有足够的了解。

“服务”这个词是一个比较通用的词汇，它可以用在很多场合，在每个场合中，它的含义可能都不会相同。简单来说，当我们使用 服务这个词汇的时候，通常是用来描述某个在后台运行的，可以进行某种运算，或是提供某些数据，能够让它的使用者调用的一组代码。服务的概念与应用程序是相对的，我们通常使用应用程序这个词汇，来描述一个拥有用户界面，用户能在这个界面上进行诸如点击、浏览等操作，大部分情况下可能是运行在客户端计算机里面的一组代码。一个服务的使用者可能是另一个服务或一个应用程序。

上面是对服务这个通用词汇的解释，这个解释在大部分场景中都是适用的。接下来，让我们来了解SharePoint 2010系统中的服务。

SharePoint 2010将其所包含的用来提供某种功能的后端组件，也称为服务。例如，SharePoint 2010包含了Excel Services服务，这是一个能将Excel文档的内容渲染成HTML页面的后台组件。SharePoint 2010的服务运行在SharePoint服务器场中的服务器上。每台服务器，都可能运行了一个或多个SharePoint服务。大部分SharePoint服务，也都可以运行在一个或多个服务器上。

大部分的SharePoint 2010服务，都是运行在服务器场中的应用服务器上，但有些服务也是可以运行在前端Web服务器上的。实际上，SharePoint 2010系统中有一个名为“Microsoft SharePoint Foundation Web 应用程序”的服务，专门用来描述处理用户HTTP请求的前端Web服务，凡是启用了这个服务的物理服务器，就被SharePoint 2010系统识别为前端Web服务器。另外，还有一个名为“Microsoft SharePoint Foundation 数据库”的服务，是专门用来标识SQL Server数据库服务的，它并不代表任何实质上的SharePoint 2010服务，仅仅用来标识在哪些服务器上运行着SQL Server数据库。

在SharePoint 2010管理中心的“服务器上的服务”页面中，管理员可以查看服务器场中的每台服务器上，运行了哪些服务。管理员可以通过这个页面，在每台服务器上启动或停止某个服务。如下图所示。

有一部分SharePoint 2010服务，使用了SharePoint 2010的服务应用程序框架（Service Application Framework）来构建。如果一个服务基于服务应用程序框架，那么这个服务可以包含多个可配置服务器场实例（Configured Farm-Scoped Instantiation，简称CFSI）。每一个CFSI被称为一个服务应用程序（Service Application）。服务应用程序运行在服务器场中的应用服务器上，一个服务应用程序可以被服务器场中的多个网站所使用，有一些服务应用程序甚至可以被跨服务器场调用。

为什么在SharePoint 2010中要设计出服务应用程序这套架构呢？其主要原因就在于，在一个大型的企业级系统中，系统中的各种后端服务，必须从网站中解耦了出来。有一些功能，是每个网站都必须要使用，例如，每个网站都需要具有搜索功能，让网站的用户能够搜索内容和数据。如果搜索功能与网站直接耦合在一起，那么每个网站就都会有自己的搜索服务。这不仅增加了整个系统的设计难度，还会造成不必要的系统资源浪费。所以，必然设计出要有某种架构，能将一组所有网站都需要用到的公用服务，从网站中解耦出来。系统中所有的公用服务，都由一个集中的“资源池”来进行提供，而网站只需要存储其自己的数据和内容。当网站需要为网站用户提供某项功能时，网站可以直接调用由集中的服务“资源池”所提供的相应服务。有了这样的架构，不但减少了整体的资源消耗，而且可以让开发人员更容易的向整个系统中添加新的服务。

在Office SharePoint Server 2007中，这个架构被设计成共享服务提供程序（Shared Services Provider，简称为SSP）。Office SharePoint Server 2007中的共享服务，包括企业级搜索、业务数据目录（Business Data Catalog）、Excel Services、用户配置文件（User Profile）等等，都由共享服务提供程序，提供给各个SharePoint网站。值得一提的是，虽然在大部分Office SharePoint Server 2007系统中，只需要为整个系统创建一个共享服务提供程序，但如果有需要，管理员是可以在系统中创建多个共享服务提供程序的。每个共享服务提供程序可以分别提供不同的服务，或是为不同的网站提供服务。

下图是取自微软公司《Office SharePoint Server 2007 的规划和体系结构》在线文档中的一个共享服务提供程序架构示意图。从图中可以看到，整个服务器场中包含了两个共享服务提供程序，其中第一个为“Web应用程序1”和“Web应用程序2”所包含的SharePoint网站提供服务，另外一个为“Web应用程序3”所包含的SharePoint网站提供服务。

只所以在一个服务器场中创建两个（或更多）共享服务提供程序，可能是出于性能的考虑，也可能是出于功能分割的考虑。比如，在上图所示的服务器场中，有可能“Web应用程序3”所包含的SharePoint网站并不需要所有的共享服务，它们可能仅仅需要Excel Services服务，而不需要其他的诸如搜索、用户配置文件等服务。所以，在服务器场中新建一个单独的共享服务提供程序，配置此共享服务提供程序仅仅提供Excel Services服务，然后将“Web应用程序3”与这个共享服务提供程序关联。

在Office SharePoint Server 2007中，共享服务提供程序是与Web应用程序进行关联的。一个共享服务提供程序可以关联到多个Web应用程序，也就是说，它可以为多个Web应用程序所包含的所有网站提供服务。但一个Web应用程序不能和多个共享服务提供程序关联。比如在上图中，第一个共享服务提供程序可以与“Web应用程序1”和“Web应用程序2”关联，但“Web应用程序3”是不能同时与服务器场中的两个共享服务提供程序进行关联的。

（待续）