Web體系結構發展規劃

步驟 1. 確定您的工作負荷模式
因為容量規劃主要是大容量網站的問題，所以在本文中我們將假定您的工作負荷容量大而且正在增長，而且需要提供動態數據并處理交易。除此之外，您必須考慮到其他指數，例如交易復雜性、數據變更率及安全性。在進行分析以后，您就可以將工作負荷模式分為 5 類：發布/預訂、在線購物、客戶自助式服務、交易、或企業對企業。適當地確定您的工作負荷模式可確保我們的方法中的其余步驟獲得最佳結果，并使您的網站能最大程度地滿足未來的需求。（如果您以前是按我們小組的系列論文做的，則您無須檢查工作負荷模式，并可跳至步驟 2。）

請參考以下的工作負荷模式說明（或參閱工作負荷模式概覽以了解其本質，并將其匯總到表格中）來確定您的工作負荷模式：

• 發布/預訂網站為用戶提供信息。發布/預訂站點范例包括搜索引擎、媒體站點（如報紙和雜志）以及事件站點（例如奧運會和溫布爾登錦標賽）。站點內容會頻經常繁變化，從而促使網頁布局不斷 變化。盡管搜索量小，但搜索到的唯一項目很多，這就是此類站點在所有站點類型中頁面訪問量最大的原因。例如，悉尼奧運會網站（WebSphere 環境）成功地處理了每分鐘 120 萬次點擊的訪問量（有關 WebSphere 的信息請參閱參考資料）。與其他站點類型相比，安全性不是大問題。數據變更率較低。這種站點類型處理的交易最少，很少或者根本不連接任何舊有系統。
• 在線購物站點允許用戶瀏覽和購買。站點范例包括用戶購買書籍、衣物甚至汽車的典型零售站點。站點內容相對固定 — 例如部件目錄 — 或動態變化（例如，隨著促銷和特殊折扣活動的開始和結束，項目被頻繁添加和刪除）。搜索流量比發布/預訂站點大，但搜索到的唯一項目數不是很大。數據變更率較低。交易流量處于中上水平，并幾乎始終在增加。許多大型零售客戶的典型日容量從每天不到 100 萬次點擊到每天超過 1300 萬次點擊，交易量從每天 10 萬次到 300 萬次；在交易總數中，1% 到 5% 為購買交易。當用戶購買時，安全性要求變得至關重要，包括隱私、認可、完整性、驗證和規則。與發布/預訂站點相比，購物站點與舊有系統（例如履行系統）的連接稍多，但通常比其他站點類型與舊有系統的連接要少。
• 客戶自助式服務可使用戶自我服務。站點范例包括在家進行銀行業務、跟蹤包裹以及安排旅行。數據大量來自舊有應用程序，而且一般有多種來源，因此數據一致性較差。安全性考慮對于在家進行銀行業務和購買旅行服務至關重要，對于其他用途則沒那么重要。搜索流量較��；交易流量處于中等水平，但在不斷增長。
• 交易站點允許用戶進行買賣交易。在所有站點類型中，交易站點的內容變更率最高，交易量最大（擺動幅度大），交易復雜程度也最高。交易站點還對時間極為敏感。交易站點與舊有系統緊密連接，使用 IBM 的 MQSeries 等軟件提供連通性。幾乎所有的交易都與后端服務器交互。安全性要求較高，與在線購物相同，安全網頁數更多。搜索流量較低。
• 企業對企業站點允許企業間開展買賣業務。數據大量來自舊有應用程序，而且一般有多種來源，因此數據一致性較差。 安全性要求與在線購物相同。交易量為中等，但一直在增長；交易通常較為復雜，需要連接多個供應商和分銷商。此模式有兩種類型：
• • 企業對企業的集成：這種類型包括公平交易之間的計劃性連接（可能需要業務伙伴簽訂協議）。供應鏈管理就是一個例子。
  • 電子市場或 B2M2B：M 代表電子市場，支持多個買方和供方。購買功能可在線或有計劃地進行。

我們對多種工作負荷模式下電子商務基礎結構性能的分析說明了以下這一點：工作負荷模式的復雜性（例如突增抵達模式）可極大地影響資源需求、吞吐量和用戶請 求的延遲時間，具體表現在更高的平均響應時間和更大的響應時間差異。如果沒有最佳的適應性資源管理和控制，基于響應時間的服務級協議 (SLA) 就無法實現。站點的容量要求不斷提高，而其提供可接受的性能和可用性的能力卻在降低。

文章來源于領測軟件測試網 http://www.kjueaiud.com/