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

简介:

SharePoint 2010认证考试出来之后,去把几个考试都考了一遍:70-57370-57670-66770-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管理中心的“服务器上的服务”页面中,管理员可以查看服务器场中的每台服务器上,运行了哪些服务。管理员可以通过这个页面,在每台服务器上启动或停止某个服务。如下图所示。

image

有一部分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网站提供服务。

image

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

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

(待续)





本文转自 kaneb0y 51CTO博客,原文链接:http://blog.51cto.com/kaneboy/388705,如需转载请自行联系原作者

目录
相关文章
|
8天前
|
机器学习/深度学习 API 语音技术
|
28天前
|
Cloud Native Devops 持续交付
构建未来:云原生架构在现代企业中的应用与挑战
【2月更文挑战第31天】 随着数字化转型的加速,云原生技术已经成为推动企业IT架构现代化的关键力量。本文深入探讨了云原生架构的核心组件、实施策略以及面临的主要挑战。通过分析容器化、微服务、DevOps和持续集成/持续部署(CI/CD)等关键技术,揭示了如何利用这些技术实现敏捷性、可扩展性和弹性。同时,文章还讨论了企业在采纳云原生实践中可能遇到的安全性、复杂性和文化适应性问题,并提供了解决这些问题的策略和建议。
|
21天前
|
设计模式 安全 Java
【分布式技术专题】「Tomcat技术专题」 探索Tomcat技术架构设计模式的奥秘(Server和Service组件原理分析)
【分布式技术专题】「Tomcat技术专题」 探索Tomcat技术架构设计模式的奥秘(Server和Service组件原理分析)
23 0
|
7天前
|
运维 监控 自动驾驶
构建可扩展的应用程序:Apollo与微服务架构的完美结合
构建可扩展的应用程序:Apollo与微服务架构的完美结合
30 10
|
8天前
|
机器学习/深度学习 PyTorch API
|
8天前
|
机器学习/深度学习 语音技术 算法框架/工具
|
29天前
|
Cloud Native 安全 Devops
构建未来:云原生架构在现代企业中的应用与挑战
【2月更文挑战第30天】 随着数字化转型的深入,企业正迅速采纳云原生技术以适应不断变化的市场环境。本文探讨了云原生架构的关键组成部分,包括容器化、微服务、持续集成/持续部署(CI/CD)和DevOps实践,并分析了它们如何促进企业的敏捷性和可扩展性。同时,文章也识别了企业在采用云原生技术时面临的安全、文化和技术挑战,并提出了相应的解决策略,以帮助企业在云时代保持竞争力。
|
30天前
|
敏捷开发 jenkins Serverless
Serverless 应用架构转型
【2月更文挑战第29天】
|
1月前
|
消息中间件 SpringCloudAlibaba Java
【Springcloud Alibaba微服务分布式架构 | Spring Cloud】之学习笔记(八)Config服务配置+bus消息总线+stream消息驱动+Sleuth链路追踪
【Springcloud Alibaba微服务分布式架构 | Spring Cloud】之学习笔记(八)Config服务配置+bus消息总线+stream消息驱动+Sleuth链路追踪
778 0
|
11天前
|
API 数据库 开发者
构建高效可靠的微服务架构:后端开发的新范式
【4月更文挑战第8天】 随着现代软件开发的复杂性日益增加,传统的单体应用架构面临着可扩展性、维护性和敏捷性的挑战。为了解决这些问题,微服务架构应运而生,并迅速成为后端开发领域的一股清流。本文将深入探讨微服务架构的设计原则、实施策略及其带来的优势与挑战,为后端开发者提供一种全新视角,以实现更加灵活、高效和稳定的系统构建。
18 0