步骤 4. 确定基础结构替代模型
    您现在可以确定构建网站基础结构所需的组件了。现在您已经根据工作负荷模式的特定需求和目标确定了组件（也许在您的顾问或友好全球供应商的解决方案工程师的协助之下）。

    IBM 正在为 HVWS 容量规划开发的技术依赖于图 8 中描绘的三种模型。

    图 8. HVWS 容量规划模型

    业务模型或业务使用模型定义了电子商务模式和工作负荷模式。每种工作负荷模式都有一个用户行为模型。每种工作负荷模式包含几类用户请求。每一类的抵达模式和路由（转换矩阵）站点访问者都包含用户行为模型。满足每类用户请求的软硬件资源和数量包含 基础结构模型。

    基础结构模型处理浏览、搜索和购买交易。该模型假定：

    网站有多层机器，每一层处理特定的一组功能，如图9所示的站点。
    负载均衡器（如网络调度程序）采用一种算法将请求发送给多个前端 Web 服务器，以在这些服务器之间平均分配请求。
    前端 Web 服务器处理对静态或动态网页的请求。
    Web 应用程序服务器处理请求所启动的交易的业务逻辑。在图9中，帐户和报价服务器是应用程序服务器。
    后端数据库服务器处理对动态网页的请求，这些网页涉及获取和更新信息；这类请求不通过负载均衡器返回。

    图 9. 多层网站（不包括防火墙层）

    
    我们设计了一个排队网络的类，用以确定多层体系结构的模型，以便分析不同级别的性能。我们还进一步得出了这些模型在不同输入流量模式和不同时间范围内的多 种解决方案。这一系列数学模型和解决方案非常通用，足以抽象当前软硬件的详细信息，但它同时又非常详细，足以生成有意义的性能结果。我们考虑一下排队系 统，其中每层的资源由多服务器队列模拟，这些多服务器队列之间存在特定的关系。这些关系通过评测或评估的工作负荷指数确定。我们然后根据一组用户需求解决 性能/容量问题，例如并发用户数、响应时间或吞吐率。我们还制定了一个独特的公式，使我们能够评估系统处于以下状态时的行为：峰值需求明显高于平均需求， 而且不可忽略用户访问大量数据的概率。

    我们的方法具有极大的灵活性，可根据用户的需求和工作负荷指数确定水平和垂直方向的伸缩，或二者的组合。例如，我们可以通过添加另一台服务器，或者在指定服务器上添加另一个处理器来增加 Web 服务器的数量。有了适当的网站和工作负荷数据，我们就能够根据我们的性能模型和分析得到性能评估。

    我们已为多家 IBM 托管的网站制定了容量规划。图 10 就说明了这样一个网站，并反映了采用当前的网站数据，然后根据当前的数据、趋势和目标制定规划来校正我们的模型的过程。在图 10 中，前三个响应时间曲线反映了用于按步骤 2 中的方法校正模型的当前数据。通过分析当前的设计和组件信息，我们就可以对第四条曲线进行规划。