|
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在每個方法調用時緩沖
和恢復屬性數據的工作。最后一點，要在所有會話間共享包含應用程序數
據對象集合的顯示數據對象，以減少維護用戶界面所需的冗余性數據庫查
詢的數量。
|
