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,如需转载请自行联系原作者

目录
相关文章
|
9天前
|
运维 持续交付 开发工具
深入浅出:GitOps在微服务架构中的应用
【10月更文挑战第26天】本文深入探讨了GitOps在微服务架构中的应用,介绍了其核心理念、自动化部署流程和增强的可观测性。通过实例展示了GitOps如何简化服务部署、配置管理和故障恢复,并推荐了一些实用工具和开发技巧。
|
1天前
|
Go 数据处理 API
Go语言在微服务架构中的应用与优势
本文摘要采用问答形式,以期提供更直接的信息获取方式。 Q1: 为什么选择Go语言进行微服务开发? A1: Go语言的并发模型、简洁的语法和高效的编译速度使其成为微服务架构的理想选择。 Q2: Go语言在微服务架构中有哪些优势? A2: 主要优势包括高性能、高并发处理能力、简洁的代码和强大的标准库。 Q3: 文章将如何展示Go语言在微服务中的应用? A3: 通过对比其他语言和展示Go语言在实际项目中的应用案例,来说明其在微服务架构中的优势。
|
6天前
|
机器学习/深度学习 人工智能 自然语言处理
医疗行业的语音识别技术解析:AI多模态能力平台的应用与架构
AI多模态能力平台通过语音识别技术,实现实时转录医患对话,自动生成结构化数据,提高医疗效率。平台具备强大的环境降噪、语音分离及自然语言处理能力,支持与医院系统无缝集成,广泛应用于门诊记录、多学科会诊和急诊场景,显著提升工作效率和数据准确性。
|
7天前
|
JavaScript 持续交付 Docker
解锁新技能:Docker容器化部署在微服务架构中的应用
【10月更文挑战第29天】在数字化转型中,微服务架构因灵活性和可扩展性成为企业首选。Docker容器化技术为微服务的部署和管理带来革命性变化。本文探讨Docker在微服务架构中的应用,包括隔离性、可移植性、扩展性、版本控制等方面,并提供代码示例。
36 1
|
9天前
|
运维 Serverless 数据处理
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
36 1
|
11天前
|
前端开发 API UED
深入理解微前端架构:构建灵活、高效的前端应用
【10月更文挑战第23天】微前端架构是一种将前端应用分解为多个小型、独立、可复用的服务的方法。每个服务独立开发和部署,但共同提供一致的用户体验。本文探讨了微前端架构的核心概念、优势及实施方法,包括定义服务边界、建立通信机制、共享UI组件库和版本控制等。通过实际案例和职业心得,帮助读者更好地理解和应用微前端架构。
|
13天前
|
运维 监控 Serverless
Serverless架构在图像处理等计算密集型应用中展现了显著的优势
Serverless架构在图像处理等计算密集型应用中展现了显著的优势
26 1
|
8天前
|
弹性计算 Kubernetes Cloud Native
云原生架构下的微服务设计原则与实践####
本文深入探讨了在云原生环境中,微服务架构的设计原则、关键技术及实践案例。通过剖析传统单体架构面临的挑战,引出微服务作为解决方案的优势,并详细阐述了微服务设计的几大核心原则:单一职责、独立部署、弹性伸缩和服务自治。文章还介绍了容器化技术、Kubernetes等云原生工具如何助力微服务的高效实施,并通过一个实际项目案例,展示了从服务拆分到持续集成/持续部署(CI/CD)流程的完整实现路径,为读者提供了宝贵的实践经验和启发。 ####
|
5天前
|
监控 安全 应用服务中间件
微服务架构下的API网关设计策略与实践####
本文深入探讨了在微服务架构下,API网关作为系统统一入口点的设计策略、实现细节及其在实际应用中的最佳实践。不同于传统的摘要概述,本部分将直接以一段精简的代码示例作为引子,展示一个基于NGINX的简单API网关配置片段,随后引出文章的核心内容,旨在通过具体实例激发读者兴趣,快速理解API网关在微服务架构中的关键作用及实现方式。 ```nginx server { listen 80; server_name api.example.com; location / { proxy_pass http://backend_service:5000;
|
7天前
|
缓存 监控 API
探索微服务架构中的API网关模式
随着微服务架构的兴起,API网关成为管理和服务间交互的关键组件。本文通过在线零售公司的案例,探讨了API网关在路由管理、认证授权、限流缓存、日志监控和协议转换等方面的优势,并详细介绍了使用Kong实现API网关的具体步骤。
24 3
下一篇
无影云桌面