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

目录
相关文章
|
6天前
|
弹性计算 Kubernetes 安全
Kubernetes 的架构问题之在Serverless Container中保障应用的安全防护如何解决
Kubernetes 的架构问题之在Serverless Container中保障应用的安全防护如何解决
46 8
|
1天前
|
监控 Java 开发者
随着软件开发的发展,传统单体应用已难以适应现代业务需求,微服务架构因此兴起,成为构建可伸缩、分布式系统的主流
随着软件开发的发展,传统单体应用已难以适应现代业务需求,微服务架构因此兴起,成为构建可伸缩、分布式系统的主流。本文探讨Java微服务架构的设计原则与实践。核心思想是将应用拆分为独立服务单元,增强模块化与扩展性。Java开发者可利用Spring Boot等框架简化开发流程。设计时需遵循单一职责、自治性和面向接口编程的原则。以电商系统为例,将订单处理、商品管理和用户认证等拆分为独立服务,提高可维护性和容错能力。还需考虑服务间通信、数据一致性及监控等高级话题。掌握这些原则和工具,开发者能构建高效、可维护的微服务应用,更好地应对未来挑战。
6 1
|
2天前
|
消息中间件 Java API
解密微服务架构:如何在Java中实现高效的服务通信
微服务架构作为一种现代软件开发模式,通过将应用拆分成多个独立的服务,提升了系统的灵活性和扩展性。然而,实现微服务之间的高效通信仍然是许多开发者面临的挑战。本文将探讨在Java环境中实现微服务架构时,如何使用不同的通信机制来优化服务之间的交互,包括同步和异步通信的方法,以及相关的最佳实践。
|
3天前
|
弹性计算 监控 数据挖掘
事件驱动架构的优势与应用:深度解析与实战应用
【8月更文挑战第17天】事件驱动架构以其松耦合、可扩展性、异步处理、实时性和高可靠性等优势,在实时数据处理、复杂业务流程、弹性伸缩和实时通信等多个领域展现出巨大的应用潜力。通过合理应用事件驱动架构,可以构建灵活、可扩展和可维护的系统架构,满足不断变化的业务需求和技术挑战。对于开发者而言,深入理解事件驱动架构的核心概念和优势,将有助于更好地设计和实现高质量的软件系统。
|
6天前
|
Kubernetes 安全 Serverless
Kubernetes 的架构问题之Serverless Container中提供对外服务如何解决
Kubernetes 的架构问题之Serverless Container中提供对外服务如何解决
41 5
|
6天前
|
存储 算法 前端开发
JVM架构与主要组件:了解Java程序的运行环境
JVM的架构设计非常精妙,它确保了Java程序的跨平台性和高效执行。通过了解JVM的各个组件,我们可以更好地理解Java程序的运行机制,这对于编写高效且稳定的Java应用程序至关重要。
21 3
|
7天前
|
编解码 Linux 数据安全/隐私保护
Linux平台x86_64|aarch64架构如何实现轻量级RTSP服务
为满足在Linux平台(x86_64与aarch64架构)上实现轻量级RTSP服务的需求,我们开发了一套解决方案。该方案通过调用`start_rtsp_server()`函数启动RTSP服务,并设置端口号及认证信息。支持AAC音频和H.264视频编码,可推送纯音频、纯视频或音视频流。此外,还支持X11屏幕采集、部分V4L2摄像头采集、帧率/GOP/码率调整、摄像头设备选择与预览等功能。对于音频采集,支持alsa-lib和libpulse接口。整体设计旨在提供150-400ms的低延迟体验,适用于多种应用场景。
|
3天前
|
缓存 Java Maven
SpringCloud基于Eureka的服务治理架构搭建与测试:从服务提供者到消费者的完整流程
Spring Cloud微服务框架中的Eureka是一个用于服务发现和注册的基础组件,它基于RESTful风格,为微服务架构提供了关键的服务注册与发现功能。以下是对Eureka的详细解析和搭建举例。
19 0
|
3天前
|
监控 负载均衡 API
从单体到微服务:架构转型之道
【8月更文挑战第17天】从单体架构到微服务架构的转型是一项复杂而系统的工程,需要综合考虑技术、团队、文化等多个方面的因素。通过合理的规划和实施策略,可以克服转型过程中的挑战,实现系统架构的升级和优化。微服务架构以其高度的模块化、可扩展性和灵活性,为业务的持续发展和创新提供了坚实的技术保障。
|
12天前
|
Cloud Native 云计算 微服务
云原生时代:企业分布式应用架构的惊人蜕变,从SOA到微服务的大逃亡!
【8月更文挑战第8天】在云计算与容器技术推动下,企业分布式应用架构正经历从SOA到微服务再到云原生的深刻变革。SOA强调服务重用与组合,通过标准化接口实现服务解耦;微服务以细粒度划分服务,增强系统灵活性;云原生架构借助容器化与自动化技术简化部署与管理。每一步演进都为企业带来新的技术挑战与机遇。
50 6

热门文章

最新文章