应用程序服务.docx
- 文档编号:28820868
- 上传时间:2023-07-20
- 格式:DOCX
- 页数:64
- 大小:63.06KB
应用程序服务.docx
《应用程序服务.docx》由会员分享,可在线阅读,更多相关《应用程序服务.docx(64页珍藏版)》请在冰豆网上搜索。
应用程序服务
版本2.0
第11章
Web应用程序服务
服务蓝图
MSA参考体系结构工具包
Microsoft机密。
©2003MicrosoftCorporation。
保留所有权利。
这些资料属于Microsoft公司的机密信息,同时被当作商业秘密。
这些资料中的信息仅面向Microsoft授权的接收者。
对于这些资料的使用、散发或公开讨论,以及任何反馈均以所附的许可协议条款为依据。
您可以通过向Microsoft提供这些资料的任何反馈,表示同意该许可协议的条款。
如果该许可协议已被删除,请在使用这些资料之前,在/specs/agrmt02.asp上阅读有关条款。
摘要
本章提供了在各种企业情境中设计和部署Web应用程序服务的信息和程序。
本指南基于InternetInformationServices6.0(IIS),后者是包含在WindowsServer2003各版本中的Web服务器服务。
本文档中的信息(包括URL及其他Internet网站参考资料)可能随时变更,恕不另行通知。
使用本文档的全部风险或因此导致的后果均由用户自行承担。
除非另外注明,否则此处作为例子提到的公司、组织、产品、域名、电子邮件地址、徽标、人员、地点和时间纯属虚构,绝不意指,也不应由此臆测任何真实的公司、组织、产品、域名、电子邮件地址、徽标、人员、地点和时间。
遵守所有适用的版权法律是用户应尽的责任。
在不对版权法所规定的权利加以限制的情况下,如未得到MicrosoftCorporation明确的书面许可,不得为任何目的、以任何形式或手段(电子的、机械的、影印、录制等等)复制、传播本文的任何部分,也不得将其存储或引入到检索系统中。
Microsoft可能拥有本文档主题涉及到的专利、专利申请、商标、版权或其他知识产权。
除非在Microsoft的任何书面许可协议中明确表述,否则获得本文档不代表您将同时获得这些专利、商标、版权或其他知识产权的许可证。
©2003MicrosoftCorporation.保留所有权利。
Microsoft、ActiveDirectory、ActiveX、FrontPage和Windows是MicrosoftCorporation在美国和/或其它国家或地区的注册商标或商标。
此处提到的实际公司和产品名称可能是其各自所有者的商标。
MicrosoftCorporation•OneMicrosoftWay•Redmond,WA98052-6399•USA00
简介
本章的Microsoft®SystemsArchitecture(Microsoft系统体系结构,MSA)“服务蓝图”指南提供了有关实施MicrosoftInternetInformationServices(IIS)6.0的设计指导,并提供了组织可用于在企业级WEB应用程序系统基础结构上设计和提供关键任务服务的信息。
注意本文档仅供参考,这意味着用它实施IIS来满足特定的业务需求之前,必须综合IIS6.0和Web应用程序设计的专家意见。
可在本文档工具包的“基础结构蓝图”指南中的“MSA应用程序基础设施体系结构”一章中找到关于应用程序体系结构的附加信息。
“MSA实施工具包”中的“MSA2.0规划指南”的“Web应用程序服务”一章给出了详细的实施细节。
目标读者
本章面向负责在企业环境下设计和部署Web应用程序服务的信息技术(IT)专业人士。
本章的读者应能理解服务级指导中提供的技术细节。
但是不要求服务专家参与企业级讨论并理解所做出的决策。
必备知识
尽管本章设计是为了使任何有兴趣理解实施基于IIS的Web应用程序服务各个方面的人士受益,但是仍然假定读者具备某些知识并能理解以下内容:
∙IIS6.0
∙Web应用程序
∙操作系统和服务器硬件
业务需求
职责和业务功能不同的组织更加需要为企业内用户、其它数据中心和外界提供基于Web的服务。
为提供这些服务,他们必须部署基于Web服务器的高度可用、安全和可伸缩的体系结构。
此外,这些体系结构应能进行监控和审核,并具有在不明显影响其所提供服务的条件下接受变更的能力。
Web应用程序服务向企业提供一种机制以在Web上提供应用程序接口。
该接口可以支持基于Internet的服务组织情形下的外部用户,也可支持各团队和合作伙伴间共享信息或工作流的内部Web应用程序。
由于以下情境描述了当前许多组织需要提供的功能种类,所以非常典型。
尽管列表还远未完备,但它洞察到了基于Web的技术与组织提供的服务模式和类型的融合。
∙电子商务应用(Internet业务):
典型的电子商务站点提供有关组织所提供的产品和服务信息。
电子商务站点必须高度可用(因为不可用性会转化为商业损失)、安全(提供包括记帐和供货在内的事务服务)且可伸缩(以便吸引由于服务增长和业务的季节性增长导致的用户数增加)。
∙组织Web站点:
组织托管能提供有关产品和服务信息和自身及其合作伙伴联系信息的公共站点。
通常这些信息由搜索引擎用于推广业务并瞄准广大受众。
∙企业内联网Web站点:
这些是在企业内运行Web应用程序来向雇员提供服务,使得他们能相互协作、共享知识、协调各团队间的工作并执行行政和公司任务。
这些服务必须安全且易用。
∙脱机交易支持:
销售部雇员能通过个人数字助理(PDA)、移动电话以及使用安全无线或开发商网络技术的平板电脑来访问销售数据。
这种能力允许销售人员在任何时候可从任何地方访问销售信息,并向组织提供更新信息以更好的做出业务回应。
∙合作伙伴界面:
组织需提供交换信息以及与其合作伙伴一起管理合资或合作公司的界面,其中包括安全可靠的上传和下载的能力。
∙自定义应用程序:
大多数组织要求新服务与现有的或自定义的系统相集成,这可能通过无法采用具有成本效益的方式进行迁移的过时技术来实现。
例如,自定义内容管理系统可能需要与基于Web的服务进行集成。
这些情境要求以Web为中心的解决方案能提供具有不同的可用性、安全性和性能水平的服务。
除了具有这些特性,环境也应该具有成本效益、适于改变并能很好的吻合组织远景规划和业务目标。
为拥有集中式机构和分公司并需要与业务合作伙伴和客户共享信息的企业级组织提供基于Web的服务是一项极具挑战性的任务。
针对Web应用程序服务的MSA企业设计
Web应用程序是一个向地理上分散且具有不同硬件类型的用户提供IT服务来满足其计算需求的既定媒介。
基于Web的服务范围广泛,其中包括共享在标记语言中使用页面的信息、提供动态应用程序功能和电子商务。
而业务逻辑和数据存储要求由其它技术来提供,网络服务器充当用户和相关系统的信息经纪人。
Web服务器需要支持标记语言、针对动态服务托管不同的技术、在电子商务环境下提供安全事务并执行一些其它任务。
这些不断变化的要求转化为对严格的安全性、对不断变化的工作负载的适应性、所提供服务类型的灵活性、与底层系统的易集成性的需求。
根据组织特性及其作为媒介与Web的相关性,使用不同的可用性、安全性和性能要求。
对于经营Internet业务(目录和电子商务)的组织,拥有高度可用性以及多级别的安全性和一致的性能非常重要。
当组织与合作伙伴交互时,他们务必提供安全连接和安全结构以便这些合作伙伴能访问组织数据并参与工作流。
当然所有这些功能应该在不危及组织内部安全或招致可自动化任务产生附加的人员成本情况下实现。
可根据规模、计算储量和其它因素将分公司数据中心分成许多级别。
基础结构应该允许这些数据中心按其要求的任何方式与中央数据中心集成。
服务定义
作为通信媒介,Web应用程序服务使用Web技术向用户提供应用程序。
通过组织托管的Web服务器来提供这些服务。
Web服务器至少应提供以下服务:
∙HTTP(Web站点)
∙FTP(针对文件传输)
可能要求Web服务器提供以下附加服务:
∙使用网络新闻传输协议(NNTP)的新闻服务。
∙使用简单邮件传输协议(SMTP)和邮局协议(POP3)邮件传输服务。
∙支持使用Web分布式创作和版本控制协议(WebDAV)进行远程创作。
此处所提到的Web服务器是作为MicrosoftWindows®Server2003系列的一部分的IIS6.0。
可将IIS6.0作为WindowsServer 2003操作系统的可选部件进行安装。
其提供托管Web站点和FTP站点的服务,为Web资源提供WebDAV工具,也作为基于XML/SOAP的Web服务的主机或分发器。
IIS也可用于提供静态HTML页面服务、使用动态服务器页面(ASP)开发、ASP.NET或Internet服务器应用程序编程接口(ISAPI)应用程序开发的动态内容,以及自定义通用网关接口(CGI)应用程序。
尽管与包括中间件(COM+和.NET)和数据库的许多技术交接,IIS6.0的主要任务还是提供应用层服务。
下图描绘了组织中IIS所提供和使用的各种典型服务。
图1.IIS6.0应用程序接口
IIS使用ActiveDirectory®目录服务提供基于Windows的安全性(身份验证和访问控制)。
同时也通过证书服务针对安全连接使用安全套接字层(SSL)和加密通信。
为提供商务应用程序功能,必须将IIS 6.0连接到本地运行或通过远程机制运行的COM+组件或.NET配件。
也可使用结构化查询语言(SQL)、可扩展的标记语言(XML)或Web应用程序的ADO.NET库将其连接到数据库。
服务设计
针对企业的Web应用程序服务设计受到诸如应用程序类型、用户类型、可用性和安全性要求、以及关于基础结构使用和需求方面的增长率等诸多因素控制。
以下章节将全面介绍Web应用程序服务的一些特征及其对设计程序的影响。
设计程序
针对组织设计Web应用程序服务是一个复杂的消耗性程序。
不应认为本节的讨论是权威的设计程序,它旨在作为具有清晰和明确的商业目标的组织应遵循的实际生活设计程序的指南指导原则。
开始设计程序前,收集与将要设计服务的性质和规模相关的要求非常重要。
随后应该对所收集的信息进行分类和分析,以便做出适当的设计选择。
以下活动是设计程序的关键部分:
∙收集设计输入:
使用正式方法决定希望Web应用程序服务满足的要求。
由专家使用各种工具吸收并分析本步骤收集的信息(包括应用程序详细资料)。
然后根据商业原因和现有技术施加的约束条件明确设计事项。
∙定义设计范围:
该活动包括区分要求服务支持的应用程序类型及其规模(用户数、站点数和数据容量等)。
同时也需要分析服务的商务关键性、当前和预期的商务需求、战略技术以及组织发展方向以定义设计范围。
∙可伸缩性:
希望组织内的Web应用程序服务能实时响应用户群、数量以及被托管的应用程序类型的增长。
这就要求设计是可伸缩的,以便能满足施加于业务的各种需求。
必要时Web应用程序服务应该遵循上扩或外扩策略,服务应该允许对可伸缩性参数进行粒度控制以确保必要时能调整性能。
该步骤要求将不同的技术可伸缩性方案映射到服务要求。
∙可用性:
Web应用程序服务要求的可用程度受商业目标和组织内服务的关键性驱使。
估计可用性要求并选择合适的实现要求的机制非常重要。
∙硬件和软件要求:
务必生成和分析信息以选择包括服务器、存储器和网络组件等适当的硬件资源。
应该用这种方式选择操作系统和Web服务器以允许最大化硬件资源的利用率。
∙安全性:
由于可从Internet访问Web服务器,它们可能遭受不同类型的攻击。
通过选择适当的用户身份验证方法并将凭证用于良好组织的权限结构来确保它们的安全。
一些Web应用程序可能要求加密敏感数据。
∙应用程序支持:
设计应能支持具有不同的复杂度、其它技术的使用以及不同的部署模式等的应用程序。
应用程序可以使用接口并向托管于其它体系结构的服务实例提供接口。
设计的应用程序支持方面也应考虑诸如CPU密集型或输入/输出(I/O)密集型等个别应用程序的不同运营特性。
∙成本:
尽管一些实例在安全性和可伸缩性等其它设计因素方面有优势,但是实现这些设计的成本受到限制。
因此应该进行成本受益分析以使设计与当前和未来商务需求一致。
应该对设计程序的本阶段收集的信息就企业需求进行分析。
考虑实施和管理Web应用程序基础结构的程序和策略尽管超出了本章的范围,但也非常必要。
有关该主题的更详细信息,请从以下网址:
参阅MicrosoftOperationsFramework(MOF)文档。
本章的剩余章节将讨论不同的设计标准以及建立Web应用程序服务实例以实现特定的商业目标集的步骤。
设计输入
为针对给定的情形确定合适的Web应用程序服务设计,应该执行以下步骤以在设计程序开始前获取必要的信息。
定义设计范围
以下信息应该作为设计范围定义的一部分进行收集:
∙要求服务的设计的数据中心或企业实例的类型。
∙Web应用程序服务提供的应用程序服务数量和类型。
∙服务的商业目标和被托管应用程序的商务关键性。
∙被托管的Web站点在用户数和容量方面的规模。
使设计与商业目标一致需要对组织,特别是在要求Web应用程序服务和服务器发挥不同的作用以及希望其提供的服务类型方面有清晰的理解。
为在组织环境下定义Web服务器和基于Web的应用程序的角色,对典型组织的要求进行建模非常重要。
这种组织拥有很大的中央用户群并且合作伙伴遍布全球,它也拥有能满足用户群的不同部门和分公司。
将这种典型组织分割成逻辑情境,并在下表中显示它们所发挥的作用。
情境
角色
公司或总部
向中央用户群提供服务,并作为部门和分公司的集线器。
它也针对B2B要求充当与合作伙伴的界面。
如果组织有受Internet驱动的业务,那么总部情境也与基于Internet的服务中心有联系。
分公司
满足组织远端分公司的需求。
分公司可以使用总部托管的一些服务,但是也可本地托管一些服务。
具有许多不同的分公司配置。
部门
为部门提供服务。
由于部门既是组织的一部分又是独立的实体,所以可将服务共享或本地化。
但是,部门对于集中式资源和服务依赖于总部。
外联网(Extranet)
提供组织及其合作伙伴之间服务接口的基础。
典型的服务包括安全和结构化数据访问和工作流共享。
将该情境映射到企业B2B需要。
Internet
提供诸如执行商务功能的Web站点托管等服务。
也包括诸如电子商务站点等金融交易。
此外,它也能提供内容管理系统和管理服务。
表1.企业情境示例
可根据诸如应用程序数、站点数、成本和性能特性等因素对满足这些情境要求的Web应用程序进行分类。
以下列表从规模和背景方面简单描述了Web应用程序的不同类型:
∙企业内联网应用程序:
将大多数企业内联网应用本地化到组织,并向特定的用户组提供服务。
虽然这些应用程序提供许多功能,但是它们通常不是商务关键性的。
它们可能非常复杂并利用综合安全来提供特定的商务功能。
∙中小型企业Internet应用程序:
这些应用程序为内部还是外部用户提供商务功能由应用程序特性决定。
缺少服务可能会导致效率损失和商务损失等的任何损失。
∙大型Internet应用程序:
这些应用是商务关键的,并且需要最高级别的可用性、安全性和可伸缩性。
任何对服务级别的安全威胁都可能导致商务损失。
新闻和电子商务站点是这些应用类型的一个例子。
可从以下网址获得有关针对商务关键的实施建立基础结构程序的相关信息:
在Web应用程序服务背景下,所有企业情境和应用程序类型在可用性、安全性和性能方面具有不同的要求。
随着运营规模的增大或商务关键性的增加,管理作为一种要求变得更复杂也更重要。
企业情境也不同于其中托管的应用程序特性。
应用程序分析
一旦理解了服务要求的全部领域,那么理解将提供Web服务的应用程序的特定要求非常重要。
本节列出了在将应用程序建立或托管到现有基础结构之前应该回答的子问题。
∙是否已经针对想要应用提供的性能进行了应力测试?
∙是否能独立扩展应用程序的不同组件?
∙是否和已知问题或扩展限制的任何其它系统组件存在相关性?
∙是否应用程序在需要对防火墙开放的端口等体系结构方面有特定的要求?
∙应用程序是否使用会议?
如果使用,如何实现?
∙用以创建应用程序的技术是否在任何方面影响对用来满足可用性、安全性和可伸缩性要求的技术方案的选择?
∙是否存在任何限制服务的最小可用性水平和服务水平协议(SLA)?
∙存在哪些更新Web服务器上内容的机制?
本章末尾附录11.1的“设计输入”中包括有关收集应用程序信息的抽样调查表。
其它如可用性、安全性、可管理性以及硬件和软件要求等将在本章剩余章节提出。
每节将讨论不同的设计方案并评估其优缺点。
可用性
Web应用程序服务设计用于托管具有不同可用性要求的应用程序。
一些应用程序是关键任务并且必须一直提供服务或者高度可用,而另外一些可能具有中度或低度可用性要求。
对于Web应用程序,可用性包含以下内容:
∙系统可用性
∙服务可用性
∙站点可用性
系统可用性
将系统可用性定义为满足商务需求或企业服务水平协议(SLA)的高度可用服务器。
Web服务器易受包括书面申请、安全漏洞、过时组件和弱性能或安全审核等许多因素的攻击,它非常谨慎的排除所有单点故障。
可考虑采用以下方法来维持系统可用性:
∙网络适配器协作(NIC协作)
∙冗余网络路径
∙服务器群集
∙负载平衡
其中每一种方法都依赖于备用配置中的某类硬件冗余或附加硬件。
如果发生硬件故障,备用硬件可以接管主要处理,以便修理或替换发生故障的组件。
方案1—NIC协作
可在失效转移配置中协作网络适配器以提供更高可用性或负载分配。
NIC协作允许二个网络适配器共享单个IP地址。
优点
不会出现性能下滑:
NIC协作的优势在于可以避免网络适配器故障。
如果发生故障,冗余适配器可以继续无性能劣化的传送网络流量。
缺点
NIC协作的缺点包括:
∙附加成本:
附加网络适配器的使用增加了成本。
∙不兼容性:
NIC协作可能与特定类型的硬件不兼容。
方案2—冗余网络路径
服务器及其资源之间的连接性可能是单点故障。
最好为服务器资源提供替代路径,以便路径故障不影响服务器所提供服务的可用性。
优点
可用性:
具有冗余路径的优点在于在网络或设备故障时可通过替代路径路由流量来维持可用性。
缺点
具有冗余路径的缺点包括:
∙增加了复杂度:
该方案中要求设置交换机引入了网络复杂度。
∙增加了开销:
具有到Web服务器的更多访问路径也意味着具有更多的安全性和维护开销。
方案3—服务器群集
服务器群集允许服务器作为单个单元工作,共享资源并提供更优异的性能和可用性。
可在不同的配置中建立2节点或4节点的服务器群集。
如果活动服务器发生故障,可将处理转移到备用服务器。
发生故障的服务器经过修理或替换后,可重新开始处理。
优点
服务器群集的优点包括:
∙高度可用性:
最大化备用服务器的用性并最小化停机时间。
∙更快更可靠的存储器:
可根据组织需要将内容与服务器去耦并部署更快或更可靠的存储器。
缺点
服务器群集的缺点包括:
∙更高的硬件和管理成本:
群集要求设计中存在附加服务器(备用服务器),从而增加了硬件和管理成本。
∙交易损失:
失效转移不保存应用程序状态,所以进程内的交易将丢失。
∙性能劣化:
在激活-激活群集中发生失效转移时,单台服务器接管发生故障的服务器负载,这通常会使性能劣化。
方案4—负载平衡
负载平衡机制用于外扩Web服务器。
负载平衡允许动态添加和删除负载平衡机制支持的服务器。
优点
负载平衡机制的优点包括:
∙发生故障时自动检测:
如果服务器发生故障,负载平衡机制自动检测故障且不向发生故障的服务器发送任何请求。
沿着负载平衡群集中的剩余服务器分配附加负载。
∙替换服务器的自动检测:
发生故障的服务器重新上线时,负载平衡器检测它的存在性并开始向其发送请求。
∙保存状态:
如果服务器发生故障,一些负载平衡器可通过维持会话图表自身来保存状态。
缺点
负载平衡机制的缺点包括:
∙更高的硬件成本:
根据运营规模和所用的负载平衡类型,负载平衡器增加了硬件成本。
∙更高的复杂度:
可要求在网络层安装负载平衡机制,这增加了服务设计的复杂度。
负载分配的方式依赖于负载平衡的类型以及所用的负载平衡算法。
下图描述了为增加可用性而对Web应用程序服务采用的不同可用性机制。
图2.增加的可用性机制
服务可用性
根据商务需求和服务水平协议(SLA)要求,Web服务器(比如Web站点)托管的特殊服务应该可用。
通常通过Web应用程序服务体系结构协同其它组件如应用层或数据库等来提供可用性。
IIS6.0提供一种称为工作进程隔离模式的新请求处理体系结构,这就为使用内置于IIS6.0可靠性特征的可用性和可靠性特征如应用程序池、Web园和健康监控等提供了基础,并能有效的用以提供Web应用程序服务可用性。
下图描述了工作进程隔离模式。
图3.工作进程隔离模式
IIS6.0具有以下组件:
∙HTTP.SYS:
核心模式设备驱动器向用户模式应用程序路由HTTP请求。
∙WWW服务管理和监控组件:
配置万维网(WWW)发行服务(WWW.Service)并管理工作进程。
∙工作进程:
将进程请求提交到为其分配的Web应用程序。
∙Inetinfo.exe:
托管元数据库和非Web的服务。
IIS6.0中的工作进程隔离模式针对进程为Web应用程序请求的各种ISAPIDLL实例使用不同的进程。
IIS6.0的以下特征可用于增强服务的可用性:
∙快速故障保护:
当应用程序池检测到给定时段分配的工作进程太多时,有可能变得不健康,那么启动快速故障保护。
该进程切断与检测条件的万维网(WWW)服务的通信并启动适当活动,典型的如为事件日志发送错误或警告,然后重新开始工作进程。
∙应用程序池队列长度:
应用程序池队列长度限制防止大量排队等候的请求使Web服务器超载并影响服务的可用性。
当启用应用程序池队列长度限制时,IIS在排队等待新请求之前针对指定的应用程序池队列监控请求数。
如果向队列添加的新请求数超过了队列大小,服务器将拒绝请求并向客户端发送503-错误响应(不能自定义)。
优点
工作进程隔离模式的优点包括:
∙可靠性:
由于应用程序运行于自身的进程中,一个应用程序故障不会导致整个Web服务器瘫痪。
∙监控不健康的应用程序:
可将针对应用程序的健康状况检查机制用于停止和开始检测到的不健康应用程序。
∙健康状况监控:
可监控CPU负载并关闭导致处理器开销的恶意应用程序以使其它应用程序可用。
可在规定的时段后(CPUResetInterval)重新开始应用
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 应用程序 服务