今天的 web 应用程序处在极为两难的状态之中 ― 它们必须足够强大以处理高峰负载，还要足够灵活以便可以容易地修改和伸缩。关键的商务事务现在通过浏览器来进行处理，并且这些关键事务要求每周 7 天每天 24 小时的正常运行时间。停机时间只是带来失望和造成收入损失，而拖延可能意味着客户将点击转向实力最为接近的竞争对手。
过去，构建高性能、高可用性的 web 应用程序意味着要付出高价，要为大型硬件和昂贵的软件支付大笔费用。今天，部分得益于像 Linux 集群这样的操作系统改进，以及得益于紧缩的 IT 预算，更多商用级价格水平的硬件正被大家所使用。但商用硬件也意味着更多的管理问题；更多的负载均衡问题，特别是对于动态内容；当部署或升级应用程序时更多的要处理的机器；一旦服务器节点出现故障而引起的潜在故障或可能导致的瓶颈，等等。
下面我们分两部分来分析新的 Oracle Application Server 10g (OracleAS 10g)，以及该软件如何处理可用性、性能和管理问题，以使在商用硬件上运行应用程序变得简单且非常可靠 ― 并且在这个过程中，使集群和企业网格计算更易于控制。第一部分将研究用来确保高可用性的 OracleAS 10g 特性。第二部分将研究该软件确保高性能和使应用程序管理变得更容易的特性。
永远告别了堪萨斯的日子
记得堪萨斯吗？回顾我们购买那些大型、昂贵、单一的服务器来保持我们的应用程序持续运行的时候。我们在前面扔掉了一些 web 服务器，然后让大型计算机来处理所有繁重的负载。然而，经历了一场风暴，那些堪萨斯的日子一去不返了。IT 预算被削减，在发展的关键转折阶段，为了进一步提高生产效率并降低成本，对 Web 应用程序的要求也更高了。
为了控制 IT 成本，公司（包括 Oracle）将运行关键商务应用程序的任务分派给了更便宜的商用服务器。但在商用服务器中，每个机器的负载容量更少了，而且更便宜的服务器更可能出现故障。存储器和操作系统方面的改进提供了一些帮助，但实际情况仍然是运行商用硬件意味着使用多得多的服务器，这反过来导致更多的故障节点和瓶颈。
集群技巧和技术被设计用来在出现故障的情况下提供冗余，有助于跨一个服务器群均衡负载，以使单个机器不会因为超载而变得滞塞。现在获得的推动力是网格技术；使用了能够处理极高工作负载的鳞次栉比的互操作服务器的硬件和软件体系结构 ― 实质上是一个庞大的集群的集群。
问题是：是否能够把低成本商用服务器的集群和网格真正转变成高容错的系统 ― 今天的 web 应用程序需要的这种高可用的系统?您将看到，答案是肯定的。
高级的端到端集群
传统上，集群意味着重点是负载均衡 ― 在服务器之间划分任务和用户来避免单个机器超载。如果一个节点出现故障，用户连接常常被终止或该服务器完全不可用。其它服务器还在运行，但被断开的用户不得不重新与它们连接，也就是说，如果剩余的服务器还没有因其它的用户而超载。甚至在剩余的服务器能够处理更多的负载时，它们也可能不会这么做 ― 它们被限制在最初配置时设定的用户数之内了。
随着时间的推移，硬件和软件解决方案得到了发展，它们超越了负载均衡的范围来更好地管理出现故障的意外情况。但这些点解决方案常常成为瓶颈或它们自己成为单个故障节点。
OracleAS 10g 使用了 Advanced Clustering 来实现更多的功能。这个软件不仅使均衡负载在一个集群中的服务器上变得容易，而且还能够检测故障并在剩余的服务器上重新分配任务来无缝地承担额外的工作负载。例如，在一个三节点的集群中，节点 A、B 和 C 承担了相等的工作负载。如果在一个 10g 集群中£节点 C 出现了故障，则将自动对节点 A 和 B 重新分配任务来继续处理节点 C 的工作负载，就像什么也没有发生过一样。
但今天的多层次应用程序甚至比上面的例子更复杂。它们可能有专门分配给应用程序层的节点和分配给 web 服务器层的单独的节点。如果应用程序使用了高速缓存（我们一会将讨论这个主题），则可能存在专门为 web 高速缓存层分配的节点。在一个多层次应用程序内部的任何节点上出现的节点故障都可能引起层叠的效应。（参见图 1。）
OracleAS 10g 的 Advanced Clustering 的前提是它能够自动适应任何层次上的故障。如果一个 HTTP 集群中的一个节点出现了故障，则客户请求将被透明地路由到集群中的另一个节点上，终端用户永远不会知道曾经出现了故障。如果 J2EE 集群层上的一个节点中止了，OracleAS 10g 确保另一个节点承担它的工作。这避免了单个故障节点。因而，甚至在不同层上的节点同时出现故障的时候，部署在 OracleAS 10g 上的任何商务应用程序也将保持无中断地运行。
故障切换和恢复特性
当出现故障时，应用程序继续运行，并迅速解决问题以确保快速恢复是至关重要的。为了加快端到端应用程序故障切换的时间，OracleAS 10g 提供了多层次的故障切换通告。利用这个特性，OracleAS 10g 用户能够将与跨层次的应用程序故障切换相关的 TCP/IP 超时延迟从 15 分钟减少为 5 秒。
为了保护集群系统不受故障的影响，OracleAS 10g 采用了冷故障切换集群 (Cold Failover Clusters CFC)，从而实现了从出现故障的主集群到一个从属集群的切换。为了获得更高的可用性，OracleAS 10g 甚至提供了活动故障切换 (Active Failover Clusters AFC)。如果一个节点出现了故障，接下来进入的请求将立即在剩余的节点之间重新分配，从而消除了任何停机时间。
OracleAS 10g 为何能够变得这么智能化和敏捷？一个原因是一个称为 Web Cache 的特殊的软件元素。由于 Oracle 10g 的出现，Web Cache 成为多层次应用程序中的第一层。
利用 Web Cache
OracleAS 10g Web Cache 是独一无二的，它确保了高性能和高可用性。Web Cache 还可以无缝地与来自 BEA、IBM、ATG、Sun、Apache 和 Microsoft 等的第三方应用程序和 web 服务器一起工作，因此它可以为您的整个 Web 体系结构提供帮助 ― 无论它是否建立在 Oracle 之上。
下面我们将研究 OracleAS 10g Web Cache 的高可用性功能，高性能特性留待我们的第 2 部分再讨论。
Web Cache 面向服务器节点，并像常规的高速缓存一样，响应所有的入站 HTTP 请求，并根据每台 Web 服务器的容量分配这些请求。回到我们假定的由节点 A、B 和 C 组成的集群中，我们可以配置 Web Cache 来将 30% 的负载分配给 Web 服务器 A，另外的 30% 给 Web 服务器 B，40% 给 Web 服务器 C。
OracleAS 10g Web Cache 有一个关键的优点：如果三台服务器中的一台出现了故障，Web Cache 自己可以自动将该负载的 50% 重新分配到剩余的两台 Web 服务器上。当出现故障的服务器回到在线状态时，Web Cache 将负载重新分配回所有的三台服务器，而所有这些对用户都是透明的。
OracleAS 10g 还自带了许多有助于改善应用程序内部的数据可用性的特性 ― 甚至当应用程序扩展和使用率增加时。这些特性包括智能化的路由和管理工具，这些工具使 OracleAS 10g 能够执行容量驱动的路由，其实质是预先关注集群中服务器的容量，然后相应地均衡进入的负载。这种路由智能化与 Web Cache 一起创建了一个对内容敏感的负载均衡系统，以分配所有的 HTTP 请求。
与 OracleAS 10g 其它的可用性特性协作，Web Cache 解决了使用商用服务器的一个关键问题：当出现故障时，如何自动调整服务器负载，而无需重新配置服务器或引入单个故障节点。
但如果在这个 Web Cache 层出现了故障，情况会怎样？这不会成为单个故障节点吗？回答当然是“不会”。在 OracleAS 10g 中能够让一个 Web Cache 与集群中其它的 Web Caches 通信，从而将它们连接在一起来提高总体的缓存容量。这种通信还可以在一个高速缓存集群成员出现故障时检测出来。例如，如果一个节点上的高速缓存出现故障，则集群中其它的成员可以承担额外的高速缓存负载 ― Web Cache 可以无缝地处理它自身的故障。
Web Cache 仅是 OracleAS 10g 中所带的各种各样性能和可用性元素中的一个。在其表面之下，您将发现一个轻型且非常强大的 J2EE 引擎，它具有一个令人吃惊的微小内核。在第 2 部分中，我们将讨论许多用来部署和管理您的 Web 应用程序的命令和控制工具。以及具有记录回放功能的监控和分析工具，以根据实际用户的经验确保一切都优化地运行。而在性能方面，OracleAS 10g 提供了几个加速您的应用程序的选项 ― 单独使用 Web Cache 就可以加速您的应用程序达 20 倍。但这是第 2 部分要讨论的内容……
