级别： 中级 Kyle Brown, 高级技术人员, IBM Software Services for WebSphere
Keys Botzum, 高级技术人员 , IBM
Bill Hines, 高级认证 IT 咨询专家, IBM
2005 年 10 月 24 日 自主运算和各种前所未有的操作功能，造就了 IBM® WebSphere® Extended Deployment 这一革命性产品。令人记忆深刻的 WebSphere XD 及其最新的智能路由引擎 On Demand Router，为网络设计人员提供了前所未有的拓扑选择。本文探讨了 WebSphere XD 如何满足人们当前对高可用性环境的期望。
来自 IBM WebSphere 开发者技术期刊。
引言
上一篇文章讨论了管理员和开发人员为何应该关注 IBM WebSphere Extended Deployment (XD)，并且预告了它在监视、可用性、系统可视化和分区方面的重大意义。然而，WebSphere XD 的真正的革命性是它为网络管理员提供了一组新的选项。网络管理员通过这些选项，可以设计出能够满足不同用户需求的拓扑。这些用户包括：
-
应用程序开发人员和公司用户，他们不仅希望应用程序能够始终以最佳的状态运行，而且还希望应用程序可以使用一致可靠的服务等级协定 (SLA)。
-
公司会计，他们希望确保公司只在绝对必要的时候才购买硬件，并且公司可以从支出（不管是日元、欧元还是人民币）中得到最大化的利益。
-
网络管理员，他们需要成功地管理指定的拓扑和应用程序。
为了理解 WebSphere XD 帮助拓扑设计人员完成这些目标的原理，在了解 WebSphere XD 中新功能的实现方式，以及这些功能为何能够有效地实现目标之前，我们必须首先回顾一下 WebSphere Application Server Network Deployment（以下称为 Network Deployment）拓扑的一些功能。
回顾 Network Deployment 拓扑
让我们先从检查大多数 WebSphere 开发人员和拓扑设计人员所熟悉的拓扑开始：一个利用了 Network Deployment 功能的高可用性的拓扑。
图 1. Network Deployment 拓扑
在图 1 中，您可以看到请求最初指向一个 IP sprayer（WebSphere Network Dispatcher 或其他 IP sprayer）。该请求随后转发到 Web 服务器层，在该层 WebSphere 插件评估每一个请求，然后确定是否应将其转发到应用程序服务器层。
自从引入 WebSphere Application Server V3.5 Advanced Edition 以来，该拓扑一直很好地保持到现在，并且已经形成了 WebSphere 可伸缩性和高可用性的基础。但该拓扑中插件的工作方式有许多局限性。我们需要尽可能地了解这些局限性，从而搞清为什么 WebSphere XD 会使用另一种方式来处理。
-
插件用来确定如何将请求路由到应用程序服务器的信息是静态的。也就是说，请求 URL 和应用程序服务器（处理 URL 请求）的设置间的映射，是通过 XML 文件提供。在 WebSphere Application Server V5.x 和以后的版本中，该文件称为 plugin-cfg.xml。它通过部署管理器生成，并且需要管理员手动复制到 Web 服务器中。当 URL 改变时（或者添加新服务器时），该插件文件 (plugin-cfg.xml) 必须重新生成和替换。（在 WebSphere Application Server V6 中，plugin-cfg.xml 文件可以导入到 Web 服务器中，但这种方法还存有许多不足之处，经常使得该方法不合时宜。）
-
该拓扑中没有一条从应用程序服务器返回到 Web 服务器插件的通信路径。因此，插件无法知道服务器到底有多忙；而且常常在插件刚开始指示服务器超载时，服务器就早已经停止响应请求了。
-
Web 服务器插件必须是一小块可移植的代码。这是因为该插件必须在所有 Network Deployment 支持的 Web 服务器中保持一致，并且该插件是运行在 DMZ 中（一个未设置安全机制的区域），所以该插件必须小巧且功能相对较弱，从而满足实际环境的需要。
正如您所看到的，当前这种安排还存有许多问题。改变此拓扑的安排是一项人工操作。因为插件文件必须重新生成和替换，而且插件所能收集的应用程序服务器状态信息在数量上也有所限制。尽管这些问题相对那些重大问题来说还不算显眼，但借此我们也可以想想到底希望智能负载均衡器为我们提供哪些强大的功能。WebSphere XD 的重要创新就是智能负载均衡器，On Demand Router 中就包括了它。
介绍 On Demand Router
On Demand Router (ODR) 是一个智能的、基于 Java™ 的路由引擎，该引擎构成了 WebSphere XD 拓扑的核心。ODR 包括了许多 Network Deployment Web 服务器插件和网络边缘路由器的功能，例如 WebSphere Edge Server Network Dispatcher。然而，ODR 明显超越了这些功能，为 WebSphere XD 随需应变的功能提供了强大的后盾。
ODR 能够：
-
侦听它所代理的请求。目前只限于 HTTP。其他协议，例如 RMI-IIOP 和 JFAP（WebSphere 嵌入式消息传递协议），将在未来得到支持。
-
根据 WebSphere（或其他）应用程序服务器的配置，对去往这些应用程序服务器的请求进行分类。
-
按优先级排列请求，并使用它 (ODR) 所掌握的应用程序服务器状态信息来决定请求应路由到哪个应用程序服务器中。
-
将请求排队并发布到应用程序服务器（根据分配给请求的权重为请求提供服务）。
-
与 XD 系统其他部分通信，以使用其他组件和驱动器功能（例如，动态布置）配合它的工作。
一个经修改的拓扑（包括 ODR），类似图 2。
图 2. 修改的 WebSphere XD 拓扑
图 2 中的拓扑在多处改进了标准 Network Deployment 拓扑：
这些优点还仅是一小部分：动态路由以及创建应用程序服务器（部署管理器）和 ODR 间的通信路径已经展现了许多令人兴奋的可能性，这些我们将在接下来的部分介绍。
当您查看图 2 时，可能想知道为什么要将一个代理服务器放置于 ODR 服务器的前面。答案是“为了维护 DMZ 安全性的完整”。我们在这里应用的三条 DMZ 基本原则是：
-
来自外面的入站网络流量必须终止在 DMZ 区域。网络透明的负载均衡器（例如 Network Dispatcher）不能单独满足该需求（想想图 1 中 DMZ 区域放置的 Web 服务器）。
-
从 DMZ 到 Intranet 的流量类型和开放端口数量，都必须加以限制。
-
运行在 DMZ 区域中的组件必须加强，并遵循功能最少和低复杂性的原则。
ODR 本质是一个附有某些特殊功能的 Java 应用程序服务器。因此，它包括大量复杂（和有用）的代码。遗憾的是，这些复杂的代码同时打开了许多端口，使它并不适宜用于 DMZ。而且，为了最大限度地发挥优势，ODR 必须能够同应用程序服务器通信并参与该单元的管理基础设施。这导致了大量的通信。如果 ODR 在 DMZ 中，将会导致内部防火墙出现大量打开的端口。有关加强 WebSphere Application Server 基础设施的步骤的详细信息，请参阅 WebSphere Application Server V5 高级安全性和系统加固。
基于上述原因，我们必须在 DMZ 中放置一个比较简单的、终止网络连接的组件。在图 2 中，我们选择了一个代理服务器，但其他组件也可以，例如终止入站 SSL 的 SSL 加速器、身份验证服务器（如 Tivoli® Access Manager WebSEAL），甚至是使用更简单的 plugin-cfg.xml 文件来将请求转发到 ODR“应用程序服务器”的简单 Web 服务器。
该拓扑另一处败笔是，我们必须为每个用户请求增加一跳。也就是说，目前请求在到达应用程序服务器之前，必须通过两个组件（代理和 ODR），因而增加了延迟。但这对于那些要求很高的环境来说是非常值得的，因为 ODR 改善了负载均衡，而且还附带了许多其他有用的功能。在接下来的部分，我们将讨论其中的某些功能。
引入服务策略和路由规则
支撑着 WebSphere XD 许多高级功能的一个基本概念就是服务策略。服务策略是一个命名实体，它定义了性能目标和优先级别，并且涉及一套事务类 (transaction classes)。通过创建路由规则并将事务类连接到一个工作类（它映射到一组 URL），从而将性能目标应用到应用程序的 URL 上。
这看起来有点复杂。实际上就是创建一种灵活的安排，以确定哪些 URL 应在哪些情况下持有哪些性能目标。
这些概念对于理解 WebSphere XD ODR 的操作原理非常重要。一旦管理员对应用程序的 URL 分类完，并将它们连接到服务策略，那么 ODR 将开始检查传入的 URL，并将这些 URL 的表现特征与定义在相应服务策略中的性能目标相比较。ODR 可以通过以下几种机制完成这个过程：
-
ODR 可以使用它所掌握的不同服务策略的相关优先级，来确定请求在内部队列中将等待多久；在资源受限时，高优先级请求在低优先级请求之前接受服务。
-
ODR 可以使用它所掌握的响应时间目标和不同集群成员中相对可用的资源（CPU 和 内存），动态管理工作负载。
-
ODR 能够与该系统的其他部分协同工作，在一个动态集群内完成动态布置。动态布置是一种功能，XD 自主管理器使用该功能决定一个集群内放置多少应用程序服务器副本比较合适。例如，如果一个应用程序的执行情况非常好，并且已经超过了自身的性能目标，但同时另一个优先级较高或相同的应用程序执行情况却不尽人意（因为运行应用程序集群副本的集群不堪负荷），那么自主管理器可以决定调整运行每个应用程序的应用程序服务器数量，减少前者的服务器数量，增加后者的服务器数量，从而改善后者不尽人意的表现。
其中某些功能（例如分类和工作队列）完全是 ODR 的功能，并且这些功能很好地处理了许多不同类型的工作负载。另一些功能（例如动态布置）比较专用且同 XD 系统的其他部分协同工作。以上所有功能都需要使用 ODR，ODR 是 XD 基础架构的重要组成部分并且拥有更多的功能。
缓存和其他高级功能
在我们查看 XD 中的缓存前，我们先结合典型的 WebSphere Application Server Network Deployment V6 架构，主要查看一下缓存的时机。图 3 就展示了这样一个拓扑的主要组件，以及每层的缓存区域（我们认为它是一个拥有相似属性和执行相似功能的服务器的逻辑集合）。当然，Network Deployment 应用程序服务器的缓存要比图 3 显示的复杂得多，例如缓存可能分布在集群中的多个应用程序服务器上。
图 3. 缓存选项
Network Deployment 环境中的缓存，由以下部分组成：
-
在边缘设备（例如代理服务器）和 Web 服务器插件上的 Servlet/JSP 页面的 ESI 边缘缓存。
-
静态应用程序（例如边缘服务器和 Web 服务器上的 HTML、图形文件和 JavaScript）的部件缓存。（也包括 Web 服务器插件中的 WebSphere Application Server Web 容器所处理的静态页面的缓存）。
-
位于 WebSphere Application Server Web 容器的 Servlet/JSP 片断缓存。
-
Web 服务 SOAP 请求/响应缓存。
-
应用程序服务器中名为 Object/DistributedMap 的基于 API 的缓存，它缓存对象并通过引用返回它们。该命令缓存能够缓存命令模式执行的结果，并返回它们的副本。
WebSphere XD V6 中的 ODR 派生于 WebSphere Application Server Network Deployment V6.02 的代理服务器，同时也继承了 V6.02 的缓存功能，因此让我们首先查看一下这个新的代理服务器引入的某些新功能。
Network Deployment V6.02 代理服务器（和 ODR）根据 RFC 2616 （第 13 节）规则缓存响应，能够缓存静态和（某些情况下）动态内容，这依赖 HTTP 1.1 缓存头的存在性（和适用性）。WebSphere Application Server V6 默认情况下，自动为静态内容的缓存设置正确的 HTTP 1.1 头。对包含静态内容的每个响应，WebSphere Application Server 将设置正确的 Cache-Control 和 Expires 头，然后使用当前日期时间减去 WAR 文件中该静态内容的的最后修改日期，来计算内容将会过时的日期时间（该时间还将乘以一个称为“最后修改”的系数，该系数默认设置为 0.1）。在下次对特殊 URL 的请求时，内容缓存将使用计算出来的日期时间确定是否可以返回响应的缓存值，或是否为了刷新的响应将请求返回到应用程序服务器。
在许多情况下，这种假设很适用，因为近期应用程序服务器上没有改变的内容可以被假设为在缓慢改变。在一个特殊情况中，这种做法会引发问题。这种特殊情况是，如果在一个服务器上重新构建并部署一个 WAR 文件，WAR 文件中所有静态内容的“最后修改”日期将变为该 WAR 文件重新构建的日期。缓存在应用程序部署或重新部署后，要比应用程序已经部署的某些时期中，更频繁地刷新自己。为了修正这种情况，您可以在任何时候创建一条静态缓存规则（匹配某种特殊的 URL 模式，以及较大的“最后修改”系数）。您也可以使用一条静态缓存规则来禁用那些匹配特殊 URL 模式的静态内容的缓存，例如该内容是敏感或专用的。
该代理缓存功能是建立在 WebSphere Application Server V6 对象缓存基础设施之上的。它提供的功能之一就是使用一个分布式缓存，在 ODR 间共享信息。默认情况下，每个代理服务器（或 ODR）使用独立的对象缓存实例设置。为了将这些实例连接到一起，必须首先为对象缓存创建一个复制域，然后在每个 ODR （将被复制到新的复制域）中设置该对象缓存实例引用新的复制域。此举确保了缓存中的信息一旦更新，就能够将变化传播到新复制域中的其他成员。
WebSphere Application Server V6 代理缓存服务器还有一些 Edge Side Includes (ESI) 功能。ESI 支持组合页面的页面缓存, 以及通过处理 ESI 规则来确定如何缓存页面的变种（依据不同的 ESI 内容）。我们稍后再讨论这个主题，如果您想利用 ESI 缓存，它可能会影响到您网络的拓扑结构。
最后，Network Deployment V6 为需要在应用程序服务器内缓存信息的应用程序，增添了新的功能强大的、有用的、基于 API 的 Object/DistributedMap 缓存功能。该功能以前只在 WebSphere Application Server V5 企业版中可用，但现在被包含在所有 V6 版本中。
在 WebSphere XD V6 中所有这些缓存技术都可用，甚至还包括更多附件选项，例如 ObjectGrid 和 WebSphere Partitioning Framework 技术。
WebSphere XD ObjectGrid
ObjectGrid 是一个可扩展的事务对象缓存框架，用于快速简便地共享数据，已提高应用程序可伸缩性和性能。Java 2 Platform, Standard Edition (J2SE) 1.4.2 和更高版本，以及 J2EE 1.4 应用程序均可以与 ObjectGrid 一起工作，然后使用应用程序 API 或基于 XML 的功能来检索、存储、删除和废除对象缓存网格中的对象。这类似上面说到的 Network Deployment V6 中的 DistributedMap 缓存功能。DistributedMap 建立在 Java Map 接口之上，但功能要比以前使用了复杂功能（可配置的缓存逐出策略和预加载——它们对于 DistributedMap 接口不可用）的技术更为强大。因为 ObjectGrid 是基于 API 的缓存功能，所以使用它需要程序改变为使用 ObjectGrid 的缓存 API，但如果程序已经使用了基于 Java Map 的 API，这种改变的程度就可将到最低。
WebSphere Partitioning Framework
ObjectGrid 使用事务缓存键/值对，而 WebSphere Partitioning Framework (WPF) 能够根据对象特性提供基于上下文的路由。WPF 支持应用程序和数据的分区，改善了数据库、in-memory 缓存和工作负载管理，显著减少了对共享数据源的争用情况。
WPF 使您能够跨多个 JVM 逻辑划分缓存，这样您就不会受限于单一 JVM 堆的规模。缓存从此具有高可用性——信息在丢失的情况下，可以迅速恢复。而且缓存也自然显现出“分组”的功能，从而可以使用户以最佳方式组织缓存中的条目，并保持相关的东西能够聚在一起。
为维护 ObjectGrid 的一致性和完整性，您可以使用分区功能将大型 ObjectGrid 向外扩展到许多分区的 ObjectGrid。该分区功能的基于上下文的路由根据 ObjectGrid 键引导请求。例如，如果您需要 ObjectGrid 处理大量对象（单一 JVM 堆已不能满足），那么您可以使用分区功能将数据加载到不同的服务器中，并且分区功能的基于上下文的路由会为每个请求找到正确的 ObjectGrid。
网络设计人员面对的衍生问题
就如您所看到的，ODR 为拓扑设计人员提供了大量的选项。事实上，由于 ODR 提供了太多新的选择，所以我们最好还是考虑一下 ODR 是如何通过将路由问题分割为更小的问题来影响我们的拓扑。接下来，我们将了解一下这些区域的大致概念（稍后再做介绍），然后考虑进一步细分该信任区域。一个详细的 WebSphere XD 网络的信任区域可能包含四种子区域类型。这四种类型是：
-
旧版 WebSphere ND 区域：Network Deployment 应用程序像往常一样部署。对于运行在该区域的应用程序，没必要改变应用程序服务器或应用程序部署过程。
-
动态操作区域：WebSphere XD 自动部署在应用程序服务器上。该安装启用了 WebSphere 的大多数新功能（运行状况监视和动态布置）。
-
非 WebSphere 区域：该区域的功能也许是最令人兴奋的新功能。ODR 不仅可以智能地路由到 HTTP 服务器（如图 2 所示），也可以路由到其他类型的应用程序服务器，包括其他 J2EE 服务器，甚至是 .NET 服务器。
-
请求定向区域：该区域包含一个或多个 ODR 和许多安全代理。这些代理对于请求的预处理（在请求定向到最终目标之前）是必要的。
图 4. 区域类型
让我们思考一下，将信任区域分割为这些不同的子区域，会衍生出哪些问题、哪些优点和哪些需要注意的地方。
请求路由区域
暂且假设我们已经看到了在拓扑中添加 ODR 的价值所在。那么，需要首先决定该区域需要多少个 ODR。在任何一个生产系统中，我们推荐至少使用两个 ODR，因为这样就不会存在单一故障点。进一步说，ODR 的数量将根据期望网络承载的负载总量来确定。根据经验，ODR 的数量可以先设置为与当前路由到应用程序服务器的 HTTP 服务器相同的数量。目前，ODR 的性能还不如 WebSphere Application Server V6 中 Web 服务器插件的路由性能，所以这种经验是一个不错的方法。但此时还需要考虑运行性能测试，在测试中通过改变 ODR 的数量可以确定最合适的 ODR 数量。
第 2 个重要决策是，决定启用 ODR 的哪些缓存选项。例如，必须决定是否在 ODR 中缓存所有内容。大多数客户应该启用静态内容缓存，尤其对于内容包含在应用程序服务器的 WAR 文件中的情况更该如此。在本例中，我们先前检查的 ODR 的缓存功能，将通过单独使用文件服务 Servlet（无需上游内容缓存），为用户提供性能的提升。
接下来，需要决定是否复制该缓存。如果内容是由少量特别大的页面（偶尔更新）组成，那么复制缓存并不划算，因为在缓存间传输这类页面会浪费很多时间。但如果内容是由大量稍小的页面（经常访问）组成，那么缓存复制将是快速填充缓存的更佳方法，并且这也能整体提高所有静态内容的响应时间。
旧版 WebSphere 区域
将该区域引入到网络设计中的考虑之一是，可以使用户在将 WebSphere XD 的所有不同功能安装到位之前，有时间考虑这些功能的优点。将 ODR 放置于现有 Network Deployment 网络之前，能够逐步迁移应用程序服务器到 WebSphere XD。首先可以将应用程序服务器迁移到 WebSphere XD，并同时保留 Network Deployment 的静态集群，最终随着服务器移到该区域外而过渡到完整的 XD 功能。但即使使用静态集群的后服务器（技术落后），也仍可以通过服务策略和路由规则进行分类和排队，这就像通过在现有 Network Deployment 前面布置一个 ODR 来处理非 WebSphere Application Server 的 URI 一样。
动态操作区域
该区域的服务器可以利用 WebSphere XD 提供的所有优势。在此需要着重考虑的是，所有应用程序服务器不仅必须是 Netowrk Deployment (V6.02) 的必备版本，而且也必须安装了 WebSphere XD。因为此处存在一个许可证发放所衍生的问题。由于 WebSphere XD 必须为每个应用程序服务器购买许可证，所以在将应用程序移到该区域前，请确保拥有足够的许可证。假定只有 WebSphere XD V6 应用程序服务器可以加入到该区域，那么将应用程序移动到该区域前，最好先将这些应用程序迁移到 Network Deployment V6.02 中。按此步骤操作会带来切实的收益。在该区域不仅可以定义节点组（共享的节点池——动态布置 在其中运行），而且还可以增强该区域的健康策略和版本管理。
非 WebSphere 区域
也许 ODR 提供的最重要的 WebSphere XD 功能（与 Network Deployment 相比）就是能够将请求路由到各种目标（甚至是非 WebSphere 应用程序服务器）。这些目标可能是简单的 HTTP 服务器（如图 2 所示），其他 J2EE 服务器（例如，Apache Geronimo 服务器），甚至是运行 Microsoft® .NET® 的应用程序服务器。用户可以通过定义一个通用的服务器集群来定义这些目标。该集群是一套不受 WebSphere 管理的 HTTP 目标，而且该集群可以从 ODR 路由到达。
实际上，ODR 允许我们使用服务策略，并获得非 WebSphere 目标的分类和排队，就像使用宿主在 WebSphere 上的应用程序一样。但这还不是全部：如果您在每个非 WebSphere 的机器上安装一个称为 XD Remote Agent 的软件，那么您还可以获得节点组成员的加权路由功能（基于服务器 CPU 和内存资源的性能及可用性）。反馈到该层的附件信息，使 ODR 超越了其他商用路由器，实现路由流量的最佳处理。
最后需要考虑的是，在新的拓扑中添加 HTTP 服务器。如果使用 ESI，并且页面组合由边缘服务器（例如 Akamai 服务器）完成，那么 HTTP 可以放入非 WebSphere 区域，如 图 2 所示。但如果您需要使用 ESI，并且不使用边缘服务器组合页面，那么 WebSphere Web 服务器插件的页面组合功能会指导您将 HTTP 服务器放置在 ODR 前面。在这种情况下，拓扑看起来可能有点像图 1。图 1 中的插件被 ODR 取代，使用 ODR 路由到应用程序服务器，如图 5 所示。
图 5. 使用插件路由的 XD 拓扑
如果拓扑中不考虑边缘页面组合，那么页面组合将由应用程序服务器完成（如果使用 <jesi> 标记或 cachespec.xml 的启用 ESI 选项），不再需要使用 ESI 标签。但这不是选择使用图 5 中拓扑的唯一原因。还有其他考虑，例如当在 Web 服务器中使用第三方安全插件时，该插件必须先于 WebSphere 的插件处理请求前执行，这也是我们选择图 5 中拓扑的原因之一。在这种情况下，您将失去在 ODR 中缓存来自 Web 服务器静态内容的能力，但在这种布置下，您仍然可以缓存应用程序服务器处理完的静态内容。
结束语
在本文，我们开始了探索 WebSphere XD 新功能所造成的网络拓扑的衍生问题。但探索还没有完成，仍存有许多问题（例如 ObjectGrid 和 WebSphere Partitioning Framework 的应用程序设计）。这些问题我们将在下一篇文章中讨论。
参考资料
作者简介
 | | |
Bill Hines 是 IBM Software Services for WebSphere 的一名高级认证 IT 咨询专家。他擅长的领域包括企业 J2EE WebSphere 应用程序的安装、配置、优化、dynacache、安全性、故障诊断和设计。 |
对本文的评价
| 
