|
Steve Kirk
MSDN Content Development Group
本文介绍了在一个分布式服务器“优雅地扩展（scale gracefully）”
Active Server Pages (ASP) 事务处理应用程序的设计策略。“优雅地伸
缩”意味着该应用程序在分布到多台计算机的同时能够保持其功能完整性
和高效的使用能力。
在前面的一篇文章“An Active Server Interface for the Corporate
Benefits Sample,”中我给出了一个 ASP应用程序。该应用程序使用了一
个依照根据功能和可重用能力所划分的界限来分离表示和数据服务的分层
服务模型。在本文中，我将扩展该概念，以展示如何将事务处理性的应用
程序分为无状态（stateless）、封装的、能减少对ASP Session对象缓冲
数据需要的请求。通过减少对Session对象的需求，你将减少对cookies的
依赖，而且可以使你的应用程序易于在多个Microsoft IIS（Internet
Information Servers，Internet信息服务器）分布。
我还将讨论将无状态对象模型用于中间层服务对象，中间层服务对象
的方法调用之间不保存对象（属性）数据。对于你的服务对象，使用无状
态对象模型比有状态对象模型更加有效，因为无状态模型不需要Microsoft
Transaction Server (MTS，Microsoft 事务处理服务器)在每次停止对象
时设置对象属性缓冲和在激活对象时恢复数据。通过这种方式使你的应用
程序与 MTS友好协作，你能够预先设置其以便有效地使用它所提供的附加
计算能力。
最后，我将展示在事务处理应用程序中如何通过共享会话间的显示数
据（presentation data） 来减少一个主要的数据库查询耗费。检索显示
于用户界面数据的工作在典型事务处理应用程序中产生的查询工作要多于
实际更改数据的数据操作。如果这些显示数据存储于共享的显示数据缓冲
对象中，则可以被多个会话使用从一个当前处理（in-process）缓冲中提
供给用户界面，由此消除了后台数据库上的花费大、冗余性的查询。
本文适用于使用Microsoft Active Server Pages 2.0的n层事务处理
应用程序。应用程序服务由运行在Microsoft Transaction Server 2.0并
使用带有Microsoft Distributed Transaction Coordinator (DTC)的
Microsoft SQL Server 6.5 的COM（Component Object Model，组件对象
模型）服务器提供。
在数量上的能力
开发Microsoft Windows NT操作系统的服务器应用程序的众多优点之
一是服务器的能力可通过多台计算机分布式承担一个应用程序的工作而得
到提升。大量的能力可以在Microsoft新近演示的分布式环境中得到扩展。
该分布式环境是一个运行Windows NT Server 4.0、Microsoft SQL Server
6.5、Distributed Transaction Coordinator和Microsoft Transaction
Server的小型计算机工作组，能够以每天十亿次的速度进行银行事务处理
（大约是世界银行事务处理量的四分之一）。
如果你使用无状态请求模型设计ASP应用程序，你将能够通过多台IIS
服务器分布它，并能使用其在多台计算机上所能扩展的无尽能力。如果这
还不足以使你使用无状态请求模型，可以再想想其它优点：通过封装应用
程序请求和消除对会话状态的依赖，你的代码片段易于被重用，你的应用
程序也更易于维护。
Corpus Distributus
提供大数量在线事务处理（OLTP，online transaction processing） 的
分布式Internet服务器包括下面几部分：
HTTP服务器. 独立的IIS服务器组成的系统，使用任何分布或装入平衡
（load-balancing）策略，对Internet上的HTTP请求提供服务。随着对任
一种资源的需求的不断增长，该种资源或分支的搜寻路径可以传递到一台
未充分利用的计算机。为了利用这种强大的分布能力，你的应用程序需要
封装HTTP请求以便它们提供所有必要信息来满足请求。通过减少对请求间
的客户端所提供的服务器缓冲的依赖，应用程序请求集成为无状态。虽然
ASP提供Session对象用于服务器上的状态缓冲，但由于Session对象不能
在 IIS服务器间共享，所以对这种特性的依赖可能会限制了一个应用程序
的伸缩能力。而且由于检索会话数据的会话标记符（session identifier）
作为一个cookie传送到了浏览器，在用户的浏览器缺乏对 cookies的支持
或用户设置为拒绝cookies时，使用ASP Session对象会使你的应用程序走
向运行失败。
分层应用服务(COM服务器). COM的中间件（middleware）层，通过采
用MTS管理的 DCOM的计算机发布，组成应用程序。层次是根据功能和可重
用能力划分而界定的，而实际的组件界线由资源和分布式的要求确定。客
户端与后台数据库间的服务对象的分层提供了代码重用能力、高效的资源
利用能力、数据安全、事务完整性。MTS 控制对象的实例化以便实际在应
用程序中只有当需要对象的服务时才得到对象的引用并在不需要对象时立
刻释放它们。大多数对象，除了共享的显示数据对象（presentation data
object），都是无状态的，这是由于在方法调用之间不存在数据缓冲。无
状态对象模型减少了当 MTS为多个并发用户分配资源时所频繁缓冲和恢复
的数据数量。显示数据对象是无状态对象模型的例外，因为它们共享数据。
这减少了与数据库的冗余访问以便能够服务于多个并发用户的用户界面。
分布式关系数据库管理系统的服务器(SQL Server和DTC).后台数据库
管理系统提供了持久的数据服务，管理资源的场所(DTC)，它们被MTS下的
中间件层利用，保证了多SQL Server数据库分布的事务处理牢固性。
封装的请求
如果你使用无状态请求/响应模型（应用程序不依赖于ASP Session对
象缓冲的数据）设计ASP应用程序，你将能够在多个IIS服务器上分布并会
意识到所能获得的巨大能力。除了易于实现可伸缩性，你还能消除对客户
端cookies的依赖。无状态模型也鼓励你设计你的ASP应用程序，使之成为
可在多应用程序中重用的请求/响应对（request/response pairs） 的封
装集合。例如，一个标准的消费者编辑程序能够被所在机构内的许多其它
应用程序所使用。这些优点所带来的代价是减少 ASP Session对象所提供
的编程便利性，以及在请求 /响应对中要包含更多数据。因为每个请求包
含了用户ID和口令或其它验证（authentication）数据，所以你可能想进
行加密以便保证应用程序的安全性。如果你的应用程序使用一个基本的
HTML界面，你可能希望用户查看 HTML源代码时难以看到请求/响应组中的
系统数据。
一个没有ASP Session缓冲的富HTTP对话（Rich HTTP Conversation）
下面的冒名HTTP请求和响应序列示范了一个应用程序如何提供用于事务处
理的富界面（rich interface），而不依赖服务器在对象中设置缓冲数据。
这个对话由一系列访问循环组成，每个循环包含一个HTTP请求、应用程序
的事务处理以及一个HTTP响应。HTTP请求由该请求的目标资源（即URL）
的装入平衡调度所确定的 IIS服务器进行处理。请求的完整信息足以包括
服务器向应用程序服务提交事务处理所需的数据，以及要在一个HTTP响应
中返回用户浏览器的数据。
用户填写登录表单并提交表单
如果用户选择了一个消费者并查询该消费者的详细信息，系统提交下
面的请求。除了选择的消费者PKId包含在请求中被传送，FirstCustomerId
也包含于请求和随后的响应中以便应用程序将用户返回到消费者列表中相
同的段中。通过使用这种在请求和响应中添加占位符的技术，你不用对IIS
上的Session状态设置缓冲就能够保持用户界面上的连续性。
如果用户选择了Edit按钮，下面的请求会被发送。而如果已从消费者
列表界面中选择了Add Customer，则发送的请求是一个具有不同Action行
为且没有CustomerId的类似请求。
注意 如果你确实需要在一个用户会话中设置缓冲，就把它们写到后
台数据库中。后台数据库是存储任何必要的会话特定状态的最佳场所，因
为它的设计保证了分布式系统中的一致性。
无状态服务（Stateless Services）
因为服务器端的应用程序不负责保持对应用程序中每个用户进行跟踪，
它的操作只是在HTTP请求到达时处理它们。在文章"An Active Server
Interface for the Corporate Benefits Sample." 中我曾详细说明了一
个分层服务体系，该服务体系能够以一种不依赖会话状态缓冲的通用方式
处理HTTP请求。在这里我将着眼于服务对象的对象模型如何影响 MTS环境
下的性能。因为你的应用程序实例化的每个服务对象都要耗用服务器资源，
所以应用程序要高效使用资源就要在使用对象前尽可能晚的得到对象引用，
并尽可能早的释放它们。MTS 管理对象的实例化以便减少初始化的延迟，
但是不依赖于对象状态的对象模型由于初始化的耗用较少而比依赖状态缓
冲的对象模型的实例化过程更快一些。在你的应用程序保持着对一个对象
的的引用时，MTS 在方法调用之间停止该对象以释放资源。有状态对象模
型在每次引用对象时需要 MTS恢复缓冲的属性数据值，因此在服务于较多
的并发用户时程序效率将变低。
共享具有缓冲的显示服务对象
当对你的服务对象使用无状态对象模型时，对于显示服务缓冲
（presentation services cache）是一个重要的例外情况。包含了数据
对象集合的显示对象（Presentation object） 应该被共享，因为检索数
据并保持数据一致的费用很高。虽然需要一些耗费建立一个通告路径以便
当数据改变时能够通知多台计算机上的显示数据缓冲，但同允许每个会话
在每次需要更新界面时直接查询数据库相比，这些费用还是要低得多。在
一个使用显示数据缓冲的分布式ASP应用程序的例子中，每个ASP程序实现
一个较大的应用程序的部分功能。显示数据对象，Application("oPcache"),
在ASP应用程序启动时被初始化。当oPcache初始化时，它注册自己为
oCaches，成为一个能被每个提供Insert、Update或Delete 服务的工具对
象所引用的独立 COM服务器。无论何时，当一个工具对象进行插入、更新
或删除操作时，oCaches 将得到通告并随后通知其列表中的所有oCache对
象。
结论
提高你的 ASP应用程序能力的最有效方式是将应用程序分布到多台计
算机上。这里已讨论的三个策略确保你的应用程序在多台计算机上分布时
能够保持功能的完整性和高效使用新增能力。要使用不需要ASP Session
对象保留会话状态的无状态请求模型。该策略避免了依靠 cookies维持对
话的连续性并使你易于在多台 IIS服务器上分布你的应用程序。要在你的
中间层服务对象中使用无状态对象模型以节省 MTS在每个方法调用时缓冲
和恢复属性数据的工作。最后一点，要在所有会话间共享包含应用程序数
据对象集合的显示数据对象，以减少维护用户界面所需的冗余性数据库查
询的数量。
|
